Images not showing because relative asset path in WYSIWYG content

Support
1

I have my cockpit cms on : cms.mywebsite.com
I have my static website on : mywebsite.com

I have a field with WYSIWIG content in it.
All images inserted inside this content do not show because they are stored as:
<p><img src="/storage/uploads/2019/10/03/5d95f399dcbc8bootcamp.jpg" alt="" /></p>

So when the query to the image is done from mywebsite.com, obviously it doesn’t work.

How can I fix that ?

To be explicit, the browser tries to query :
https://mywebsite.com//storage/uploads/2019/10/03/5d95f399dcbc8bootcamp.jpg

2

Yeah,
I’ve also posted about this as well as opened a ticket on github.
Even if you put a full path, Cockpit will rewrite the path.

I think the best/easiest course of action would be to have a config item for assets that allows for defining the path/url. I haven’t gotten a response in regards to this issue (3 months, maybe?), so I don’t have any great news.

I think I ended up having to use a different field type to get this to work.

3

In my case I can’t even use a different field because it’s an image in a wysiwyg and I have multiple images between multiple texts…

4

It’s not a good practice to store the full image path in the field (what happens if you need to change the domain?)

Is your static website served by you (e.g. using nginx or apache)?
If so, you can setup some rewrite rules that will serve the static images, something similar to:

location /storage/ {
  root /var/www/cockpit/storage;
}
1 Like
5

Nope it’s on netlify.

And to answer your question, if you changed domain then you do a migration, just like all big cms do.

WordPress stores absolute paths most of the time because you need it for rss or things like that. Besides I never said they should store the path, cockpit could send dynamically the fullpath only in the API response.

Because my issue is not a special issue.

Cockpit is a headless CMS so it’s obvious most people will use it on a subdomain or other domain, that’s the whole goal of having an API on a headless CMS.

So that being said, for images in an image field I could understand to not send the absolute path, but fr images in a wysiwyg what should I do ?

Do a string search and find / replace ? That’s pretty dirty.

6

That’s one of the reasons that wordpress sucks, because it’s dirty in the way that deals with contents.

Since you are talking in “headless” CMS, the contents on an headless system are agnostic of the system that will consume them (it can be a browser, it can be a mobile app, if can be anything…), honestly don’t see what is the issue, on my FE implementations (e.g. React) I just have a env variable for the domain and replace the url using a html component like https://github.com/pveyes/htmr, where I can have a transformed for the node of type img and just prefix with the configured domain…easy and clean, you can do something like:

import convert from "htmr";

const transformMarkup = {
  img: node => <img src={`${process.env.ASSETS_URL}/${node.src}`} {...node} />,
};

const Text = props => {
  return (
    <div className={"text-block"}>
      {convert(props.markup, { transform: transformMarkup })}
    </div>
  )
}

You can’t be expecting that the API will parse html chunks and do replacements on the fly, right? But if you don’t bother with performance you can still do it by yourself, just implement an `collections.find.after’ and do the replacement on the fields you need (but still the wrong approach).

Also its also a bad content modeling to use a text field with images, usually I prefer a component based approach using the layout addon and have a set of smaller components (formatted text, image, video, quote, etc…)

1 Like
7

This is the field I’m using:

image
image778×301 4.04 KB

And this is how to use a wysiwyg:
image
image1086×773 90.5 KB

Therefore, when you say:

and

It shows you don’t care about the end users and about other issues on the forum. I’m not the first asking this, and it’s the case for a reason : the Wysiwig type exsits, so either it should disappear or it should solve this issue.

Now as for your sentence:

Lol… Why was this field invented then? Why is it their then? For a simple reason:
It’s easier to migrate from another blog for exemple and it’s also easier for the end user who may not be a developer and do not want multiple fields to just write a simple blog post.

Pure content websites like: news, online magzines, etc, would be harder to maintain and edit if the journalist or content editor had to enter each piece of content in different kind of components because it’s not a fluid way of writting content.

So before saying things like “Wordpress sucks”, “just use smaller components”, think of the end user.

Many developer are so focused on themselves that they don’t even think of the end user while the end user is precisely who we are creating something for.

CMSs in general are made for end user to easily edit content, not developpers, Headless CMSs are not excluded from this fact.

Now as for:

You just summed up the issue, if behind the mobile app of New Yok Times it was cockpit, do you expect each app (IOS and Android) to do the find a replace on both apps ? Do you expect the journalist to use a layout system with multiple components which can’t allow him to easily edit his content as it would be on a word document ?

PS : Wordpress sucks but powers 33% of the visible web, I doubt many people can say their tool is used as much as that. Wordpress was rewritten 6 years ago and is way more clean than the time it “sucked”, but I guess you didn’t use it enough.

8

@darkylmnx Why don’t just use WP then? :slight_smile:
Cockpit (or any other Headless CMS) tries to solve the same problem but from different angle.
Changing it to be the same as WordPress (or any other coupled CMS for that reason) only so that “end-user” can say “oh yeah, I’m riding the latest trend - I use headless CMS!” makes no sense, right?
So, if WordPress approach to things works for you, there’s nothing that should be stopping you from adding your .00000001% to that 33%; but it absolutely makes no sense to call out other communities simply because they take different approach.

1 Like
9

First of all, I never called out anything, I’m just relating a fact : I’m not the only one having this issue on the forum and even on stackoverflow, that’s a fact.

Secondly, I never said wordpress was good for my usecase, I said, saying wordpress sucks while it powers 33% is a bit silly, there are things that sucks in wordpress like there are things that sucks in any tool. I’m not specifically fan of wordpress and I’m not specifically fan of cockpit either, I use tools that are right for a certain task, and in my current case, a headless CMS was the right tool for me, not Wordpress.

That being said saying

tries to solve the same problem but from different angle

to justify the fact that absolute urls aren’t sent in the REST Api response is not a valid argument because, as I said : I’m not the only one having the issue, and the WYSIWYG type exists for a reason, and one issue with it is, having relative paths inside it while a headless CMS is supposed to be used from any environnement like a mobile app where it would be annoying to have to parse HTML generated by the WYSIWYG content to add the CMS’s domain url.

I don’t need plugins or themes or any kind os stuff like that, that’s why I don’t use Wordpress in the current situation, I used cockpit among many other option like Directus that could have done the trick, I just prefered cockpit’s docs & sqlite approach because I needed a small API, if the API was suppose to be big I would have used Directus or even Contentful for that matter.

You’re actually the one calling me out for the simple fact that I’m stating something obvious : if there’s a WYSIWYG field with image that can be inserted, and the the CMS’s API can be used on a mobile app or a different domain from the CMS, why can’t we have in the API response, the absolute path on image FOR THE WYSIWYG field.

My question is simple, the use-case is simple, I’m not calling out anyone but if that’s how cockpit’s community is (not accepting criticism and feedback), I guess i’ll just not use it next time.

By the way, if I really wanted to call out cockpit I would have called out all the other “absurde” things cockpit does and call REST while it isn’t RESTful at all. Oops, now I did.

Le mar. 8 oct. 2019 à 22:24, Blistok via Cockpit Community getcockpit@discoursemail.com a écrit :

10

Perhaps you didn’t understand me. I’m not even talking about the specific feature request (whether it’s valid or not, or whether the solution has already been provided elsewhere), I’m talking about the attitude.

Now, in potential future cases, where feature doesn’t exist, or where valid critique is raised, instead of spending time writing long replies “proving the point”, it’s gonna be both easier and more valuable to simply open a PR.

1 Like
11

that’s the only thing I was asking for: a solution.

My original post had no attitude and no calling-out whatsoever but the sentence:

Was what started the long replies, his sentence didn’t bring any solution to the described problem while that’s the purpose of replying to an issue: giving a solution to the OP or saying it’s impossible for X or Y reason.

Anyway, thanks for the answer.

12

@darkylmnx, don’t want to start an endless discussion that doesn’t add any value, when I said “That’s one of the reasons that wordpress sucks…” is just a way of saying that’s one of the reasons I don’t like wordpress (in these days people just overreacts and assume any strong statement as an insult or whatever). Honestly, I don’t care if it’s used by 33% of the web, its the same with music and cinema, you can have something that sells massively and is still crap. When you talk in users, you should think in content editors instead, and content editors shall be trained on the tool they will be using, we shouldn’t build interfaces on what end users want, but on what they need (most of the times they don’t know what they want), that’s the reason we have UI/UX experts and that’s the reason Apple got the success they have now.

Now, returning to your problem, I provided you a valid and simple way to deal with that situation that in my opinion is good and I believe it’s a better approach than having a full URL in the field.

As said, I like a component-based approach where I can map directly my content models to react components, so I can reduce complexity and maintain things maintainable in the long term. I’m used to that on Drupal (e.g. using paragraphs module), Contentful (links), DatoCMS (modular contents) and on Cockpit with the Layout field and custom components. I’m not an wordpress expert, but believe same approach is possible, for example if you check https://medium.com/@easternstandard/building-component-based-wordpress-sites-e7223424d4fe the resume quite well the concept by using the flynt framework (https://flyntwp.com)

That permits also to have a better separation between styling and semantic, resuming a shift from page centric web to content centric web, I strongly recommend to read that article - https://alistapart.com/column/wysiwtf/

Comparing in cockpit both approaches:

Traditional
https://take.ms/6PDAi

Component Based
(using LayoutComponents and EditorFormats addons)
https://take.ms/mpAML

If you observe the differences on the resulting JSON object you can see that in the component based approach our JSON is more clean, semantic and robust, that permits a better handling of the information in the FE and we can easily deal with migrations, as there is no need to parse HTML.

The only drawback of the LayoutComponent is the modal interface (instead of an inline where we can expand all components), but probably something for a feature request.

But if still not convinced, and still want absolute URLS, you may take a look on that thread - Full domain path in WYSIWYG?

1 Like
13

Many UX expert will tell you that Wysiwyg is a very convient way to write content, in fact it is so much a good way to write content that more and more tools are based on Wysiwyg (webflow is just a huge example).

Having a wysiwyg and having components is not incompatible, again, just look at webflow.

That being said for pure content based with external links, images and stuff like that in text, wysiwyg is IMO (and apparently I’m not the only one) more convenient.

Now, funny thing that you say the most used isn’t always the best and then say Apple has success because it does what people need and not what people want lol.

Apple has success because it has an ideology and a strong culture like most fashion brands (Chanel, LV, Gucci), Apple’s success is not because “they do what people need”, for a simple reason: everyone doesn’t need the same thing.

Anyway, thread is over, I got the answer to my question.

14

And btw, when I was talking about end user, I was talking of cockpit’s end-user, and cockpit’s end user is the content editor because cockpit is a CMS.

15

My 2 cents, as I also opened this same issue months ago, is that:

  1. There should be a config option for asset url paths so that Cockpit can be MORE flexible for people’s various setups (same domain, different domain, etc.)
    a. This would keep the intent behind Cockpit in being flexible and an alternative to other systems
  2. Cockpit should not be aggressive in it’s asset path rewrites (Cockpit will rewrite absolute path urls in the WYSIWYG). Cockpit SHOULD respect the author’s intent/content.

That said, @pauloamgomes your product is very helpful and the features, coding style/approach, etc. are completely at your discretion, but end users may have a different use case than yours - that doesn’t make their use case less valid.

For example, I use a Cockpit instance to provide content to several different platforms (a website, a CLI tool, a browser plugin and API access to other documentation teams) all on an internal network. Because Cockpit doesn’t allow for full asset paths and actually rewrites the full image paths authors enter several problems are created - I have to do a find and replace on consumption of the content to add and/or correct the asset paths. I have to ensure that every consumer of the API also knows that they have to do the same. This creates a lot of overhead on every API call.

16

Hi @jasonday, first of all that’s not my product, Cockpit was created and is maintained by @artur , so all credits to him. I’m just like others a contributor and also a bit of evangelist as I admire the features and the fact of being opensource.

I understand what was requested, don’t get me wrong on that, but that doesn’t mean that for me it is the best solution, and therefore my comments. They weren’t a denial of having or not the feature, but more around content modeling and the fact that I consider that bad practice and would not do that in any project.

Also since that is a possible configuration, I updated the EditorFormats addon in way it can be easily configured - https://github.com/pauloamgomes/CockpitCms-EditorFormats

1 Like