Open GoogleCodeExporter opened 9 years ago
i think the only thing I am concerned with is what happens to existing
installations if they upgrade to 3.2 when this is the new .htaccess file? Will
it break anything?
Original comment by ccagle8
on 24 Mar 2012 at 12:38
You can drop this new RewriteRule in your current 3.1 right now without
breaking anything. At least, I haven’t found any problems. That’s why I
kept the $_GET['id'] in there, this means we don’t actually have to change
any of the code.
If you want to reuse slugs per parent we will have to use a new filename
pattern for the XML files. Maybe something like parent.slug.xml. This would
break old XML files, yes. I think we might need something like an upgrade.php
file as seen in many other CMS systems. This PHP file would run when upgrading
between versions to fix database differences between the 2, in our case
filename differences.
Also, the last one that includes the full path might be good for plugins like
I18N. Instead of having to ask the user to change their HTACCESS file (which
leads to problems: http://get-simple.info/forum/post/24803/#p24803) the plugin
can just look for the first part of the $_GET['path'] and match it against the
languages that are in use.
/de/whatever/parent/page would turn into
• $_GET['id'] == "page", so current GetSimple code still works.
• $_GET['path'] == "whatever/parent/".
I18N could then just match "whatever" against a list.
Original comment by martijn.personal@gmail.com
on 24 Mar 2012 at 12:49
That last part should be:
/de/whatever/parent/page would turn into
• $_GET['id'] == "page", so current GetSimple code still works.
• $_GET['path'] == "de/whatever/parent/".
I18N could then just take the first part of the path as language ("de") and
build the XML file name from there: "page"."_"."de".".xml".
Original comment by martijn.personal@gmail.com
on 24 Mar 2012 at 1:01
I put this up for discussion and testing on the forum:
http://get-simple.info/forum/topic/3684/help-test-a-possible-future-change/. It
needs a better topic title, so change it if you have a better idea.
Updated rewrite rule:
RewriteRule ^((([^/]+/)*[^/]+)/)?([^/]+)/?$ index.php?path=$2&id=$4 [QSA,L]
Why so complex? This will allow for a simple explode() on the PHP side, no more
PHP parsing needed. Keeping it simple and easy to adept for plugin developers.
I made a note about that on the forum as well.
Original comment by martijn.personal@gmail.com
on 24 Mar 2012 at 4:05
Been away for a few days so only looking at this now.
Looks good but have some reservations about all these changes to .htaccess
files which have a knock on effect on us users who don't use apache and have to
rewrite these changes for our systems, have you seen Zeus rewrite scripts?? 8)
So why don't we pass the whole URI to PHP and do our parsing there?
Surely better to have GS working out of the box on as many host system as
possible.
As for slug name what if there is a duplicate we name it as above.
parent.slug.xml
so if we looked for
/de/blogs/blogentry1
which corresponds to blogs.blogentry1_de.xml
/blogs/blogentry1
corresponds to the default language version of the file blogs/blogentry1.xml
If the page is moved up a level or between parent we will need to code in
changing the slug name.
So we can check the first param against an array of ISO 639 language codes and
traverse backwards through the rest
checking the parent each time.
If the parent does not corresponds we divert to a 404 page.
Original comment by MichaelS...@gmail.com
on 26 Mar 2012 at 10:47
> So why don't we pass the whole URI to PHP and do our parsing there?
> Surely better to have GS working out of the box on as many host system as
possible.
I agree, as I said at the end of the original issue:
> Something to think about [is] w[h]ether we might want to opt for a more
WordPress like system and just pass everything along to the PHP.
I just tried to support the ‘old way’ in the .htaccess as well, this way
we’ll be catering for plugin authors already, even before we would have had a
need to rewrite the whole URL parsing. It will also keep old plugins working
that might depend on the $_GET['id'] variable.
RewriteRule ^((.+/)*(.+)/?)$ index.php?path=$1&id=$3 [QSA,L]
Would put the complete path, including the possible trailing slash and the
value of $_GET['id'] into $_GET['path'] while still supporting putting the last
part of the request in $_GET['id'] as well. (Untested, I’m at school.) Would
that be better?
Original comment by martijn.personal@gmail.com
on 26 Mar 2012 at 12:14
New Regex, again, the previous untested one included the trailing slash in
$_GET['id']:
RewriteRule ^((.+/)?(.+?)/?)$ index.php?path=$1&id=$3 [QSA,L]
Original comment by martijn.personal@gmail.com
on 26 Mar 2012 at 4:53
Original issue reported on code.google.com by
martijn.personal@gmail.com
on 24 Mar 2012 at 12:02