MODx 0.9.1 rev 609 (internal testing)

Quote from: rthrash at Dec 23, 2005, 02:05 PM

And the final final test build with Friendly Alias paths even working flawlessly now!

Indeed, I patched makeUrl and the weblogin snippet so they now work with Friendly Alias paths. Please note one change that we will need to communicate to those performing upgrades: there is no longer a <base href="[(site_url)]" /> inserted or required in the template header to support using friendly alias paths! You can use [(base_url)] in front of any paths (e.g. CSS, images, javascript) in your template if you want to it work in any virtual sub-directory.

Quote from: OpenGeek at Dec 23, 2005, 02:33 PM

Please note one change that we will need to communicate to those performing upgrades: there is no longer a <base href="[(site_url)]" /> inserted or required in the template header to support using friendly alias paths!  You can use [(base_url)] in front of any paths (e.g. CSS, images, javascript) in your template if you want to it work in any virtual sub-directory.

Just looked at the code. Nice work Jason my only question is what’s the reason for removing the <base /> tag? Was it causing problems?

Also note that those users who add [(base_url)] before the url inside their image tags will not be able to preview those images inside the RTE

IMO the <base /> makes all of this transparent to the user there’s no need to add [(base_url)] to your css, script or image files if the <base /> tag is used.

What do you think?

I’d like to add the base href back as an option actually, until then I can post information on the changes to alias path’s and make it clear that such image issues will require users to add the base tag to their template (easy enough), and investigate how the ancient rewrite image paths could be refactored (or maybe the parser itself) to solve this issue moving forward.

In final version, it shows (rev 646) instead of 0.9.1

My MODx Site - MODx 0.9.1 (rev 646)

I think it should be

My MODx Site - MODx 0.9.1 (x9)

Hey Zi -- we changed the meaningless x9 to reflect the current SVN revision of the release.

Means it was planned ....

OK, what about MODx 0.9.1 (Build 646)

Quote from: rthrash at Dec 23, 2005, 10:16 AM

Quote from: R.S. at Dec 22, 2005, 04:21 PM

Oh well, it’s a copy paste

See attached files

What do the attached files fix?

The lang folder detection code was used in 3 places, or more correctly 3 files.
The applied fix was only made in one file, so I did a copy paste of the lang folder detection code in the remaining 2 files..

Remon

P.S.
Congrats with the new release!

rev = revision = the commit number in subversion

Quote from: zi at Dec 24, 2005, 02:47 AM

Means it was planned  ....

OK, what about MODx 0.9.1 (Build 646) 

I’m in agreement with Zi. It we’re going to change the code name from "x9" to somthing else then I think we should be "Build ---" rather than "rev ---", where --- is the number of the svn revision inside that is used to build the install.

Quote from: OpenGeek at Dec 23, 2005, 05:25 PM

I’d like to add the base href back as an option actually, until then I can post information on the changes to alias path’s and make it clear that such image issues will require users to add the base tag to their template (easy enough), and investigate how the ancient rewrite image paths could be refactored (or maybe the parser itself) to solve this issue moving forward.

In 0.9.0 base url was only inserted into the page when FAP were turned on.

I don’t think the <base /> should have been removed in 0.9.1 with the hopes of using [(base_url)] before css and image tags.

http://modxcms.com/forums/index.php/topic,1942.msg13616.html#msg13616

IMO the <base /> makes it easier to use relative paths for images, etc when FAP is witched on.