WebLogin status in CVS

Before I start posting bug reports, since we don't really have a release yet, I was wondering about a couple of issues with the WebLogin module I'm experiencing in MODx2:

1. When logged in as a manager user, the loginhomeid and logouthomeid seem to be ignored, which produces inconsistent behavior for content editors when previewing their sites.

2. The redirection on both the login home and logout home is not respecting the friendly aliases.

Have these already been addressed in the current CVS image?

I think those are fixed in the current CVS that's at victorland.com.

update: I think there's a lot of work to be done on friendly aliases in general. I'd REALLY like to see friendly alias paths working for installs both in the root of a webserver and in a subfolder.

I think those are fixed in the current CVS that's at victorland.com.

update: I think there's a lot of work to be done on friendly aliases in general. I'd REALLY like to see friendly alias paths working for installs both in the root of a webserver and in a subfolder.

Great, I'll port that to my site for a quick fix. And I'm not using the multi-level paths on this project yet, but I'll need them soon; and I agree that it needs some work.

I'd REALLY like to see friendly alias paths working for installs both in the root of a webserver and in a subfolder.

Why, in particular, don't they?

I've got alias URLs working just fine in a couple of working installations on my home site; I just put the properly configured .htaccess files in the root folder of each installation. I don't use them in my main home installation. If I did, I would still need the .htaccess files in each separate installation in subdirectories, to override the instructions of the main root .htaccess fiile.

Ok, I just turned them on for my main site, and they work just fine for my main site and all of my other installations as well. Maybe I've misunderstood the problem?

I've got alias URLs working just fine in a couple of working installations on my home site; I just put the properly configured .htaccess files in the root folder of each installation. I don't use them in my main home installation. If I did, I would still need the .htaccess files in each separate installation in subdirectories, to override the instructions of the main root .htaccess fiile.

RewriteRule ^(.*)$ /installation_folder/index.php?q=$1 [L,QSA]

Ok, I just turned them on for my main site, and they work just fine for my main site and all of my other installations as well. Maybe I've misunderstood the problem?

This was specifically regarding the WebLogin modules redirection for the parameters loginhomeid and logouthomeid (not respecting the alias, and sending me to the 128.html instead), and then the conversation was extended to discuss the hierarchical alias capabilties MODx introduced, in which documents in subfolders would build a URL with full ancestry (e.g. /rootFolderAlias/subFolderAlias/docAlias.html).

I've had trouble getting this to work properly, with absolute or relative URLs.

Alias' in general work fine.

Ah, I see. Sorry, I did misunderstand the problem. ops:

This was specifically regarding the WebLogin modules redirection for the parameters loginhomeid and logouthomeid (not respecting the alias, and sending me to the 128.html instead), and then the conversation was extended to discuss the hierarchical alias capabilties MODx introduced, in which documents in subfolders would build a URL with full ancestry (e.g. /rootFolderAlias/subFolderAlias/docAlias.html).

Is this due to the way the URLs are/aren't being built by the system or in the translation of the URLs by the mod_rewrite/htaccess?

...the hierarchical alias capabilties MODx introduced, in which documents in subfolders would build a URL with full ancestry (e.g. /rootFolderAlias/subFolderAlias/docAlias.html).

Is this due to the way the URLs are/aren't being built by the system or in the translation of the URLs by the mod_rewrite/htaccess?

My initial guess is the way the URLs are being constructed, as the rewrite rules are specified in one location, and the issue I have is with regards to absolute/relative pathing when enabling the hierarchical feature. Basically, I write everything using relative pathing so it is portable, and it works great with a single level of aliases, but add the subdirectories in there and all of a sudden no style sheets, images, or anything can be located properly, and I get unstyled, pure XHTML output. I tried changing everything to absolute paths (relative to the server root) and had no better luck. Adding a <base href="... tag to the templates with a dynamic value representing the current location was one idea I had to solve it, and I think I could get it to work eventually, but I'd rather not do that if I don't have to. I'd like to switch the feature on and get the full paths without changing my templates. Another approach might be to use mod_rewrite to handle the ancestry, though that would require .htaccess manipulation, which I don't care for.

Basically, I write everything using relative pathing so it is portable, and it works great with a single level of aliases, but add the subdirectories in there and all of a sudden no style sheets, images, or anything can be located properly, and I get unstyled, pure XHTML output.

That sounds like it is working just like it should-- you cannot use subdirectories in your path and relative URLs at the same time.

The reason is that if you go to /subdirectoryalias/index.html and then use relative paths in your template to "css/style.css", the browser on the client side correctly assumes that the actual path is /subdirectoryalias/css/style.css", which, of course, doesn't exist.

I don't see a way around that because according to the RFCs, this is exactly the behaviour that the browser should be doing.

I tried changing everything to absolute paths (relative to the server root) and had no better luck.

This I don't get because it works for me: /assets/sites/style.css always works, even with aliased paths like /work/projects/thissite/changes.html

Or am I misunderstanding something?