Forums / Cotonti / Support / url mod_rewrite page_add bug

123>>>

question about page_add bug solving with mod_rewrite enabled

donP
#1 2010-01-19 19:13
In Kilandor detailed Guide many users comments remark the bug with page_add...

Kilandor answer like this:

Kilandor:
Modify .htaccess rules so that it looks for /add at the end of the URL, for example:
docs/([a-z-]+)/([a-z-]+)/add$ page.php?m=add&c=docs-$1-$2

But I ask:
But... have I to write such a similiar line for every category and subcatecory of my site?!?! :O

Any explainations? :(
Thank you
in [color=#729FCF][b]BLUES[/b][/color] I trust
Trustmaster
#2 2010-01-19 21:36
docs/ here is a root-level category we provide our "wonderful urls" for. The above rule provides "add" rule for 2 levels of categories nested in docs. So, normally you should provide such a rule for every level of nesting. E.g. for 2 levels of nesting in category "foo" and 3 levels of nesting in "bar" it would be:
foo/([a-z-]+)/([a-z-]+)/add$ page.php?m=add&c=foo-$1-$2
foo/([a-z-]+)/add$ page.php?m=add&c=foo-$1
bar/([a-z-]+)/([a-z-]+)/([a-z-]+/add$ page.php?m=add&c=bar-$1-$2-$3
bar/([a-z-]+)/([a-z-]+)/add$ page.php?m=add&c=bar-$1-$2
bar/([a-z-]+)/add$ page.php?m=add&c=bar-$1
May the Source be with you!
donP
#3 2010-01-20 02:23
So, if I have 100 among categories and sublevel of category (I think so), must I have to make 100 RewriteConditions?! :O
Isn't there a way to modify {page_url_structure()} function so it can to handle the m=add parameter outputting a right url?
in [color=#729FCF][b]BLUES[/b][/color] I trust
Gökhan YILDIZ
#4 2010-01-20 05:51
RewriteRule ^(articles|news|videos|bla|bla2|bla3)/([a-z-]+)/add$ page.php?m=add
Gökhan YILDIZ
donP
#5 2010-01-20 09:40
# Gökhan YILDIZ :
RewriteRule ^(articles|news|videos|bla|bla2|bla3)/([a-z-]+)/add$ page.php?m=add

Nothing to do with this and nothing also with Trustmaster one...

The only way I find was putting
page	id=*	{page_url_structure()}
page	al=*	{page_url_structure()}    /*because page	al=*|id=*	{page_url_structure()} doesn't work  :/ */

in datas/ultrans.dat instead of
page	*	{page_url_structure()}

so the page.php?m=add&c=... hasn't rewritten anymore, BUT... there still a problem: in this way the page has successfully added to the database, but a user with category-related admin rights receives a 930 redirect error message saying the operation isn't allowed... this error doesn't happen when a level 1 users inserts a new page (and that page goes to validation queue)...

what's the matter? :/

Added 8 days later:

Noone here to answer this? :(
in [color=#729FCF][b]BLUES[/b][/color] I trust

Dit bericht is bewerkt door donP (2010-01-28 16:45, 15 jaren ago)
Trustmaster
#6 2010-01-28 21:24
Is {HEADER_BASEHREF} present in your header.tpl?
May the Source be with you!
donP
#7 2010-01-28 21:44
Yes :(
in [color=#729FCF][b]BLUES[/b][/color] I trust
Trustmaster
#8 2010-01-28 22:11
Can you somehow notice the url which are you redirected from?
May the Source be with you!
donP
#9 2010-01-28 23:47
The form button in page_add module points to page.php?m=add&a=add...
The problem is that, nomral users pages go to validation queue and redirection points to index.php; Admins pages - instead - go to database directly and redirection points immediatly to page.php?id=#(the new inserted page ID). This is bad interpreted by url_rewrite engine I think, so a "930 bad url message" has returned.
in [color=#729FCF][b]BLUES[/b][/color] I trust
Trustmaster
#10 2010-01-29 00:43
Could you check your webserver logs please? We need to know if it redirects to /page.php?id=123 or /category/that/is/not/real/page.php?id=123
May the Source be with you!
donP
#11 2010-02-08 22:14
I have to investigate if I have the ability to check my webserver logs (I have Analog Stats in cPanel: is this the right tool? And is it a real time tool? Or I have to wait till next day, cause it would be too difficult to analize)... but that is not only a problem of mine... Many users have got it...
in [color=#729FCF][b]BLUES[/b][/color] I trust
Trustmaster
#12 2010-02-09 01:54
I have uploaded an example of current files used on this site. Add problem is fixed there, except for problems with Wiki plugin.
May the Source be with you!
donP
#13 2010-02-09 16:29
Thanks for the example but...

1) functions.custom.php uses eregi() that is deprecated from PHP 5.3.0

2) I don't understand why docs have different rewriting rules :/

3) I had to change RewriteRuleBase at the beginning of .htaccess cause it generated a 500 internal Server Error

4) url_rewrite doesn't rewrite links in menu slots and links in pages (parsed text)

5) users rewriting causes me many problems

6) list.php?c= rewriting is transparent to my headerchanger plugin, instead page.php?id= and page.php?al= not at all...
in [color=#729FCF][b]BLUES[/b][/color] I trust
Trustmaster
#14 2010-02-09 17:13
1) I have reuploaded a fixed version

2) Because in docs here category code is split by dashes: docs-en-user becomes docs/en/user. In other categories (e.g. downloads) subcategories have simple codes like plugins.

3) Sorry. How did you change it?

4) You're right, it does not rewrite static text. Static text should use new links.

5) Yes, it has bugs so it is not recommended to use.

6) Can I test your plugin to see the reason?
May the Source be with you!
donP
#15 2010-02-10 01:46
1) Thank you (althought I didn't need that part cause we don't use docs rewrite part)

2) Now it's clear

3) I changed with RewrtiteBase

4) This is a real problem, cause webBots are ravenous with links in pages, and we would think about a parsing solution to use url_rewriting method also in pages and menu slots

5) So, we wouldn't use user part of the script, for now...

6) I really can't understand, but, unfortunately I can't test in local cause (I don't know the reason) my wampserver goes crazy if I try to use url_rewriting...

So, if you had time to look at the code, this is my plugin:
in [color=#729FCF][b]BLUES[/b][/color] I trust

123>>>