Wedge
Public area => Bug reports => The Pub => Archived fixes => Topic started by: eolith on February 12th, 2014, 03:08 PM
-
I see Pretty URLs are working here, but when I enable Pretty URLs of any sort on my site, I get 404s for the prettified URLs. Nothing in the error log. Brand new install, discovered as I was going through the admin settings to match an SMF forum I run.
For others that may encounter this, here are the URLs to paste into the address bar to undo the pretty URLs:
Load this URL:
http://YOURWEDGE.COM/index.php?action=admin;area=featuresettings;sa=pretty
Deselect the Pretty URL (actions)
Paste this URL and hit enter:
http://YOURWEDGE.COM/do/admin/?area=featuresettings;sa=pretty;save
-
AFAIK, admin pages don't use pretty URLs at all, mostly to help against PURL issues, so if you just navigate to ?action=admin, it should be enough...
Did you enable action rerouting with /action, rather than /do/action, by any chance..?
Also, don't forget that Wedge needs the install/.htaccess file to be moved to the root, if you're going to use PURLs. Was this done..?
-
the admin pages do switch to .../do/admin... and break.
I hadn't moved the .htaccess before (what did I miss that gives the instruction?), but I did this time, and it makes no difference.
I did not try the /action instead of /do/action because that option is not available until after you turn on pretty URLs, and then the Save button no longer works because it leads to 404s (all admin pages are now 404s), and I don't know what URL would work to make that change.
If it matters, I'm hosted on GoDaddy, deluxe linux package as a subfolder to my main forums (which run SMF).
-
the admin pages do switch to .../do/admin... and break.
I hadn't moved the .htaccess before (what did I miss that gives the instruction?),
I guess it should be mentioned in the Pretty URLs page itself, but it isn't the case.
That's mostly because /install used to be a folder where one was supposed to move all files to the root. Since this is no longer necessary, I tend to dismiss the fact that you still need to move some of the files to the root, if you want all features.but I did this time, and it makes no difference.
I did not try the /action instead of /do/action because that option is not available until after you turn on pretty URLs, and then the Save button no longer works because it leads to 404s (all admin pages are now 404s), and I don't know what URL would work to make that change.
If it matters, I'm hosted on GoDaddy, deluxe linux package as a subfolder to my main forums (which run SMF).
-
Well, I don't know, but I've repeatedly said it.
I guess it should be mentioned in the Pretty URLs page itself, but it isn't the case.
That's mostly because /install used to be a folder where one was supposed to move all files to the root. Since this is no longer necessary, I tend to dismiss the fact that you still need to move some of the files to the root, if you want all features.
For the record, other than the .htaccess file, I have not moved anything from /install into the root folder.What URL is being shown in your address bar when it shows a 404..?
http://www.exile-guild.com/wedge/index.php?action=admin
After turning it on, it's this:
http://www.exile-guild.com/wedge/do/admin/[/url]Hmm, can't find anything at fault here. What Apache version..? (Admin > Server > phpinfo)
-
If you are running fcgi, please change the following to 1 in php.ini:
cgi.fix_pathinfo
-
how do I know if I'm running fcgi? (GoDaddy hosting)
-
Search PHP set_ini on google. This fonction might help you force that setting.
It's a good idea to explore forcing it in wedge.
In the meantime, add it at the start of index.php in your root. Not the very start of course. After the define calls for instance. Keep us posted.
-
There's a hint in your phpinfo:
_SERVER["GATEWAY_INTERFACE"] CGI/1.1
-
I'm not sure how this directive would have any influence over Wedge's PURLs, though...
I'm still curious, but...
Also, the instruction is ini_set('cgi.fix_pathinfo', 1);
I said set_ini, it wasn't. Sorry, I wasn't on my computer.
-
Wedge expects the URL to be passed along as a PATH_INFO variable. CGI and FastCGI implementations of PHP do not have PATH_INFO available, so when trying to pass the URI along, PHP fails.
-
Isn't there another variable that's available, then..?
-
Hmm..
Disabling fastcgi in .htaccess?
Options +ExecCGI
addhandler x-httpd-php5-cgi .php
But GoDaddy says:You cannot disable FastCGI with our cPanel shared hosting accounts.
-
I added the ini_set function as described above at the location indicated below. I still get 404s
define('WEDGE_VERSION', '0.1');
define('WEDGE', 1); // We are go.
// attempt to disable fCGI
ini_set('cgi.fix_pathinfo', 1);
// Get everything started up...
if (function_exists('set_magic_quotes_runtime') && version_compare('5.4.0', PHP_VERSION) > 0)
@set_magic_quotes_runtime(0);
-
I have no idea how to work with .htaccess, but I gave this a try right at the top:
<Directory "/">
Options +ExecCGI
addhandler x-httpd-php5-cgi .php
</Directory>
that just stopped my server from working, got an Internal server error until I adjusted it.
-
But GoDaddy says:You cannot disable FastCGI with our cPanel shared hosting accounts.
-
doesn't hurt to try ;) Also, I've never seen the term "cPanel" applied to my account.
-
Only way I can fix this (or at least try to find out what caused this) would be, at this point, to have FTP + forum admin accounts to your forum.
Sorry about that, but... Dunno what it's doing for you, really.
-
I've created an account for you and sent you a PM with the details. Please let me know what you find.
-
I mostly need ftp access to play with htaccess ;)
Don't worry I'm not going to abuse it. If anything you can just give me a custom account limited to your wedge folder.
-
oh yeah... that's what I get for posting after having a few drinks with a buddy... :P check your PMs
-
Ah yes, thanks..!
I'll look into it tomorrow. I'll have to juggle with House of Cards too, it's quite tempting, but I think I'll focus on Wedge first, because I have yet to commit all of my big changes from the last couple of days... (The 'hey' bit in the members table; changes to the settings file; modular main htaccess; and most importantly, the upgrade script!)
Remind me if I haven't been there by tomorrow night!
-
No problem. Thank you, sir, for your personal attention. I know you must be busy.
-
Hello all ;D
I have the same problem with the clean or pretty url, but I know that with rewrite mod over apache get better. So make that wordpress and another software too. But I am no a dev ...
Here a link to a wikipedia artice ;D
http://en.wikipedia.org/wiki/Clean_URL
Greetings
Gerriet
-
Okay, so here's what happened...
*If your Wedge forum is installed in a sub-folder*
And
*If your server is Apache 2.2.16 or better*
Wedge is falling back to the FallbackResource /index.php line in the htaccess file.
However, /index.php is an absolute URI, and thus it redirects to your www root's index.php, rather than your Wedge root's.
I used to do index.php without the slash, but it actually uses the current requested path as relative path, instead of the htaccess file's path. What does it mean..? Well, doing /wedge/profile/me/ will attempt to load wedge/profile/me/index.php, instead of wedge/index.php...
The solution (which I applied to eolith's forum):
Well, err... As stupid as it sounds, just get rid of the FallbackResource lines. And the version testing lines. Basically, below the "# Pretty URLs" line, just keep this:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php [L]
</IfModule>
It obviously takes more time than just FallbackResource... :-(
Now it all comes down to the fact that I've been working on making Wedge create the htaccess file automatically.
If I can't get the Apache version number (eolith's server doesn't disclose it >_<), I'd have to print the above code instead of the easier FallbackResource. But what if you then upgrade your Apache server..? You could then use the faster FallbackResource, but Wedge wouldn't know. Well, I guess you could 'simply' remove your htaccess file from time to time, and Wedge would recreate it with the latest available code, but... Anyway.
Sometimes, a compromise has to be found between ease of use and ease of development... Hmm.
-
I think I understand about 83% of that... :P
Thank you very much for that modification and the work to make it happen.
-
I took the easy way out (i.e. the coward's way), by removing all traces of FallbackResource, but it really hurts... :lol:
Still, first impressions are more important than later optimizations.