I have a website with two contexts. Images are not shown in the second context. They both use the same images/files/media source. In the website code I see the base_url inserted in the image URL’s, which should not: www.domainname.com/en/image.jpg. Which should be www.domainname.com/image.jpg.
The issue is caused the base href tag. You have to add a slash before the image scr attribute (absolute url) or rewrite i.e. the en/assets url in the .htaccess to an url without en/ like
# redirect all en/assets requests to assets
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^en/assets(.*)$ assets$2 [L,QSA]
My 50 cents:
You have to edit the mediasource (seems to be mediasource with ID 2) and add a preffix slash on the baseUrl (just a slash if you don’t set a path).
Then, on the baseUrlRelative, set it to “No”.
This will avoid to change the URL of the image when you switch contexts having base_url different than / set on your context. Also don’t forget to I Clyde base href tag on your html head.
I prepared very recently a multi conext site for different languages with Fred, pdoTools and pThumb and it works just great like I described. There was no need to change htaccess. Please ensure that you install a context Router (xRouting is great) for proper context switch handling.
Note that it’s a modx convention that all path and URL settings end in a slash. So the standard approach is to have all baseURL settings end in a slash and never use a slash at the beginning of anything that will be added to them.
And shame on MODX that these kind of simple things take hours and days to tweak. I’m not a programmer. I find it hard enough to set up a context Router, and would expect things to work after that. The ‘WP’ word is coming closer and closer.
We’re trying. Each of these threads will help people in the future, and many in the community are writing guides as we speak.
Modx was made for developers rather than basic users. It does have quite a few advantages over WP, security and more control, that’s why I choose Modx.
One difficulty is that there are so many things you can do with Modx, its hard to write guides for every instance.
MODX presents itself as a platform for front end, not solely/exclusively for developers, in the way it works. I’m a front ender. I’m not doing anything with PHP. You don’t need any development/PHP skills in MODX to be able to work on great websites. I love the flexibility and control to work on lean websites.
The only thing is that settings could me way more easy to understand. The lack of proper documentation does not help.
If MODX wants to grow, it should focus on usability for front enders.
While MODX is a great platform for back-end developers (it’s both a framework and a CMS in one), I agree it’s also excellent for designers and front-end developers.
I know a number of people who love using it but don’t know a lick of PHP or SQL.
It’s true the documentation needs improvement and that’s been recognised by the community. As such, a new versioned documentation system has been created where anyone can make edits to existing pages or create whole new sections themselves.
All that’s needed is a Github account to take part. There’s no coding needed, all is done through a simple user interface.
Well, my point is that its not really geared for non-developers, like WP which is made for people with very limited skills. They give up control for access and ease of use, but there is a price to be paid for that. When I made my first site I played with WP but I found it to be lacking, although easy to get started with. Also had the same experience with Vanilla forum software.
You are right that php is not needed to develop in Modx, although it is really useful to do a bunch of different things on a site.
What I like is the complete control I have with Modx, or nearly so
BTW I would consider ‘developers’ to include front-end people.
If MODX wants to grow, it should focus on usability for front enders.
One difficulty is that there are so many things you can do with Modx, its hard to write guides for every instance.
The thing is, when a Addon is created, like a context routing addon, only half solutions are offered. You need many obscure (for designers…) settings to go through, without any documentation. It almost never works at once in a rudimental way.
I also know plenty of front-enders that work with a full git flow for their work, too. Just because you haven’t had to use it (which is not demeaning - you’ve just focused on other things), does not mean Github (or git in general, e.g. gitlab/bitbucket) is not a very common tool that developers and designers alike use for all sorts of collaboration.
As for editing the documentation, there’s a 9-minute screencast explaining the process from start to finish. It’s literally clicking buttons in a web interface and editing a text file. That it requires a github account instead of a separate signup that can only be used to edit documentation is a plus.
If you’re not comfortable making changes yourself, another option is to at the very least report specific issues you have with the documentation so others can fix it.