I've found a workaround by disabling the Last Modified tag in the SEF patch extended, and this solved the problem, but this is a valuable thing SEO wise, so I hope someone will find a better solution for this problem. And I just can confirm here, thet upgrading from 1.5.0 to 1.5.1 revealed the problem. I have it "successfully" reproduced in 3 different sites, for example on the one wich hurts me most, www.joomla-tips.org/

I have the same issue. Can anyone help here?

Setting the shop to use the nonsecure www.mysite.com as "secure" URL solved the problem... sort of, so the checkout works, but I lost the security of HTTPS...
Hope this will be fixed soon.

Same setup, other problem. If I configure the shop to use www.mysite.com the checkout fails. works normally withouth ArtioSEF, the certificate is in place. Any toughs?
(Yea, I have buyed - yestredays, to be precise - and I'm using your VM plugin, and I'm not a Joomla/VM newbie if this helps ;) )

Yepp, that's the ideea, I'd like to have both options, 1-1 redirects and rule-based ones, for start directory "replacement" should be fine and easy to implement!

Great stuff, and delivers on promise!
Boys, upgrade your installs, worth the effort!
On other note: can I have a feature request?
I recently has redone for someone a site wich, contrary to best SEO practices has some inner addresses changed, and among these are pages with high PR figures (The decision wasn't mine). Struggling with the fact an ideea cam in my mind: what if 404 redirect would have the possibility to redirect specific querries to given addresses? A tool to specify that if someone wants the /dir1/aaa.html, wich is missing, to be redirected to /dir2/aaa.html, (so a replacement directory) or better, to /dir2/bbb.html, and, of course a nice 301 error ;)
Just asking, I'm allready excited by yout useful component!

Yepp, your guessed, what's happened... That's also originated in malfunctioning of the latest Artio. I had originally both section/category stuff turned on. Switching to the latest Artio fucked it up, because the schema is used only for generating section.and/or category based urls, not for the inner pages, to be clear:
www.mysite.com/mysection/mycategory/ is generated correctly
but instead of

www.mysite.com/mysection/mycategory/myinnerpage.html
latest artio generates
www.mysite.com/myinnerpage.html
I tried to play with settings, leaving only category or section to be used in URL's - this works - so URL's as
www.mysite.com/mysection/myinnerpage.html
or
www.mysite.com/mycategory/myinnerpage.html
are generated correctly for respective settings, but as side effects of experimenting I ended up with a lot of URL's as the one above picked up in mean time by users and robots alike.
Now my settings are back to the original ones (sections and categories both turned on) and Artio is downgraded to 1.2.5 to generate as possible the correct URL's.
Hope soon a fixed Artio will be out, then my problems, hopefully will be gone!

That's from ArtioSEF. And because ArtioSEF generates both URL's, the David's solution is not kicking in - acts only when the URL is not found. (Hope, I'm right here, but that's what I understand from my experiments)
On my 7500+ page site David's solution is working great, I still have issues with ArtioSEF.


PS. a problem, tough, here are 2 successive lines from log:

20/12/2006 10:20:49 84.227.3.117 obfuscator/3.html www.java-tips.org/obfuscator/ redirect

That's okay, this is the expected behaviour, but then what happens?

20/12/2006 10:20:50 84.227.3.117 obfuscator/ www.java-tips.org/java-applications/obfu...in-obfuscator-2.html redirect

obfuscator is a category, marvin-obfuscator is an item from that category... So in final, instead to land on the category page, the user is "ported" to an item's page...
Any ideea?<br><br>Post edited by: webgobe, at: 2006/12/20 19:44

I'm excited!
Waiting to beta-test the new one too!!

Hmm, depends on your site's original settings and your history in Google. I have a PR6 site with more, than 7500 individual URL's, where the http://{sitename}/ page has PR6, and http://{sitename}/index.html and http://{sitename}/index.php have PR0 - and these are pointing to the same page, as you know!
So, the original option in ArtioSEF, that you can choose wich one of these to be shown, should be preserved, I think. So if ArtioSEF is set to shown default index file to be shown as index.html, then these 2.html's should be converted to index.html, of course. But if this parameter is set to none, aka to shown these kind of URL's as http://{siteurl}/{section}/{category}/ withouth the trailing index.html, then these 2.html's also need to be converted to such URL's.
The Google PageRank is a hardly earned extra value of a site ;) so worth an effort to keep it!
Unfortunately from Google's point of view these variant's aren't equal :(

As for the second one: Artio generates wrongly for the root page something like xxx-5.html for the root of those multipaged items. Your trick handles the subpages well, but does not touch the wrongly generated root url's, and a &quot;shift&quot; is produced, for example if ArtioSEF has generated a link-5.html for the root of the page, then page 2 created with {mospagebreak} will &quot;coorectly&quot; have the address link-6.html.
I'm not sure if it's a wise try to fix it from your component... I thing will be a far complex resulting code here... this one should be fixed in the ArtioSEF. But I'm not quite sure about the best route ;)
Anyway, your component is allready under heavy testing on that PR6 site, so you will have certainly more feedback, as data accumulates!
Thanks again!

Great component!
Indeed reduced significantly those ugly -2.html's, so please, keep up the development!
Some problems still around:
1. If you opt for the category pages to be displayed as http://{siteurl}/{section}/{category}/
aka withouth the index.html or index.php at the end, ArtioSEF still produces links as
http://{siteurl}/{section}/{category}/2.html
2. The component also has problem with URL's of multipage items, ones with {mospagebreaks} in the content. The main url, wich is supposed to be also withouth -2.html thing is again generated wrongly, at least the derivated ones, the subpage URL's are relatively good ones.
Example here: www.webgobe.ro/internet/netikett-5.html
But, again :WOW, I'm excited!

Great news! I'm interested!
Recently got on Google 1500+ 404 errors wich compared with the 7500+ links is bad... and I'm tired to check and remove them manually.

Hi!
Something new? I have a PR6 site with 7500+ URL's and now all internal URL's are fucked up... Anyone can help? Downgrading does not solve some key problems I have...
I upgraded because of annoyances in 1.2.5.
TIA!