I believe this turned out to be a very minor issue and has been resolved for the next beta. Basically, you can change it as long as you don’t change it to "default". As far as I’m aware all named manager themes work.
One of the important notes in first post says:
* Don’t change the manager theme.
Is resolving this in near sight?
True. Thanks for pointing that out. That does need fixing for the full release.
1. Ajax Search links lead to dynamic urls "index.php?id=9" even though I have static sef urls turned on.
Your 301 idea is good, however I think that should be toggleable. I’ve used ?id=7 for testing purposes previously when porting parts of a site to MODx (if billy.html exists, the htaccess shows that; once I’m happy with ?id=7, I can delete the old billy.html file). So I would consider that it is not a bug/problem but rather a wishlist extra that shouldn’t hold up 0.9.5.
2. (related to above) Dynamic urls are usable creating duplicate content issues with search engines.
The extension has been optional for some time - this facility enables many things such as having an alias called styles.css or feed.xml, which lets you reference an editable file in headers etc without the extension. This facility should not be removed without adding the ability to over-ride the extension.
3. ... Also noticed www.domain.com/quickstart.html and www.domain.com/quickstart are the same thing via the browser no matter what is sellected in settings.
« MODx Parse Error »
MODx encountered the following error while attempting to parse the requested resource:
« Execution of a query to the database failed - Unknown column ’editedon’ in ’field list’ »
SQL: UPDATE modx_site_tmplvar_contentvalues SET editedon=’1158495453’,editedby=’1’ WHERE id = ’2’;
[Copy SQL to ClipBoard]
Parser timing
MySQL: 0.0030 s (5 Requests)
PHP: 1158495453.2988 s
Total: 1158495453.3018 s
I just updated my site, and ran into something rather surprising. Ever since TVs first got added to the core, I’ve used them exactly the same as I do the document content; that is, I often just put plain HTML code in them. With the upgrade, however, this HTML code is being displayed exactly as entered, tags and all.
On investigating, I found that there are more input types than there were, and I needed to change from "textarea" to "raw texarea".
I thought it would be a good thing to mention so it doesn’t come as too much of a shock to others.
You need a base href tag set to the site_url in your template before any CSS paths; assuming you have authored your content in a portable way (i.e. all paths relative to the root of the MODx site), this should work for all your templates. Otherwise, create a custom one for your error_page that does include this.
I tried the fake virtual directory to see if it returns 404 error now. It do, but the 404 page in fake directory is unable to load the sytlesheet from the correct path, so the page cannot be render by the stylesheet. I use firefox webdeveloper toolbar to ’view css’ and confirm that the browser do try to load the stylesheet from the fake-dir. Same for IE.
mysite.com/fake-dir/assets/templates/modxhost/layout.css (and all other css script)
* fake directory means not existing directory/ghost directory.
I’m confused, the behavior on this was just reverted not to use the htmlentities call anymore?? This should not still be an issue, as both the raw and regular forms are now doing the exactl same thing again.
I just updated my site, and ran into something rather surprising. Ever since TVs first got added to the core, I’ve used them exactly the same as I do the document content; that is, I often just put plain HTML code in them. With the upgrade, however, this HTML code is being displayed exactly as entered, tags and all.
On investigating, I found that there are more input types than there were, and I needed to change from "textarea" to "raw texarea".
I thought it would be a good thing to mention so it doesn’t come as too much of a shock to others.
There isn’t one on the rendering side for now. Discussion of this issue started here.
So what’s the difference between "textarea" and "raw textarea" then?
This discussion is closed to further replies. Keep calm and carry on.