I'm looking for an overview of how Gallery2 will rewrite urls. It seems to be quite a bit different from V1. I previously wrote an implementation of the old .htaccess file for use with IsapiRewrite on IIS. I would very much like to do this again for V2. Does anyone have any recommendations or documentation that they can share with me?
Posts: 8601
short urls in G2 right now only use http path info, as this is more portable.. separate modules to take advantage of more powerful rewriting rules in each webserver is a good idea.. there's another topic here about doing this for apache.
A rewrite module has two parts: manage the .htaccess or equivalent files to enable the redirection, and tell G2 how to generate these short urls. The first one you can do now using existing G2 apis.. perhaps a site admin view to configure anything if needed. The second one may require some small core change.. modules can already register path info prefixes, but this should be expanded so modules can register rewriting rules.
Posts: 5
Only two months late, but this feature won't be possible, or at least, won't be easy and will require tweaking as you add or remove modules. Since ISAPI_Rewrite does not support file or directory testing, it is impossible to replicate the generic redirection employed by the new rewrite system, and so you would have to hand-tune it either per module, or script all of the real files and directories into the condition list by hand.
Posts: 5
*bump* for great justice.
Uggly adaptation, based on default configuration. Assuming G2 is in /gallery2/:
RewriteRule ^/gallery2/v/(?!gallery_remote2\.php)(.+).html(\?(.*)) /gallery2/main.php\?g2_view=core\:ShowItem&g2_path=/$1&$3 [I,L]
RewriteRule ^/gallery2/v/(?!gallery_remote2\.php)(.+).html /gallery2/main.php\?g2_view=core\:ShowItem&g2_path=/$1 [I,L]
RewriteRule ^/gallery2/v/(?!gallery_remote2\.php)(.+)(\?(.*)) /gallery2/main.php\?g2_view=core\:ShowItem&g2_path=/$1&$3 [I,L]
RewriteRule ^/gallery2/v/(?!gallery_remote2\.php)(.+) /gallery2/main.php\?g2_view=core\:ShowItem&g2_path=/$1 [I,L]
RewriteRule ^/gallery2/d/(?!gallery_remote2\.php)([0-9]+).*(\?(.*)) /gallery2/main.php\?g2_view=core\:DownloadItem&g2_itemId=$1&$3 [I,L]
RewriteRule ^/gallery2/d/(?!gallery_remote2\.php)([0-9]+).* /gallery2/main.php\?g2_view=core\:DownloadItem&g2_itemId=$1 [I,L]
Yup, that's right. No file or directory detection, gallery_remote2.php blocker in every rule, and every rule doubled up for query append. This could probably use some optimization... I wonder if it's possible to [I,L] a gallery_remote2.php rule which effectively does nothing, to eliminate the clutter from the rest...
Posts: 389
When using prefixes such as /v/ and /d/ you realy dont need file or direcotry detection, since the chanses any user would have the directory 'v' or 'd' in their Gallery root is pritty slim. If you want to get rid of the gallery_remote2.php blocker you could make it its own rule and point to a php file with <?php header('HTTP/1.0 404 Not Found'); ?>.
I'm currently doing a remake of the rewrite module and woring on a new rule/pattern system. If you want I can post how things will work once I commit it.
Posts: 5
I may be interested in seeing that.
Some adaptations will be necessary for the new detection code to work with ISAPI_Rewrite. Since it doesn't support per-directory settings, and only the commercial version supports per-virtual-site config, it's not really possible for the plug-in to detect by forcing a temporary redirect. Hmm, I don't think there's any way other than checking for HTTP_X_REWRITE_URL environment variable, and even that I'm not too sure about...
Hmm, I'll have to test if forcing do-nothing redirects for gallery_remote2.php will cause recursive redirection, or if the internal redirection will only occur once, then fall to the server's internal parser, which then reports the 404. Gee, maybe I am feeling the slightest bit of regret for having wiped my perfectly good old server XP config, which was my old desktop machine, in favor of testing out Server 2003 evaluation.
For ISAPI_Rewrite configuration, the gallery_remote fall-through rule could be presented, then the query and non-query versions of the redirect rules. (Observing the escaping for colon and question mark characters, which appears to be necessary.) Then user is presented with a template list of filters for their global or virtual site ini file, which probably can't be verified. Maybe user could be asked to paste a particular test filter into the file first (and restart server or application pool(s)) and then verify it works first. Then all this mess would be wrapped up and hidden behind a configuration option either in the page, or maybe even in config.php or something.
Oops, just found out, those two /v/ query variations should have (.*) and not (.+) before the query substring, otherwise /v/?blah fails.