I have a website that requires mod-rewrite to function well, but it seems to not be functional on the Network Solutions shared server we're running on. Network Solutions promises it's installed but won't provide any further support without additional payment.
I placed a simple test at the following folder which contains two files. The first, ".htaccess" contains the following text:
RewriteEngine On
RewriteRule ^link([^/]*).html$ rewrite.php?link=$1 [L]
The second is the PHP script which tests it, available here:
http://www.oceanhousefloridakeys.com/testmr/rewrite.php
All I see is that mod-rewrite is installed (no error messages showing) but the rewriteRule is not working. Can anybody see why this script isn't working... is there anything I can do to get it running, or is Network Solutions not telling the whole truth?
It looks like your script resides inside a sub-directory. In that case it's the best solution to set the RewriteBase to the correct path (before any RewriteRule):
RewriteEngine On
RewriteBase /testmr/
RewriteRule ^link([^/]*).html$ rewrite.php?link=$1 [L]
Related
I am new in creating a website using wordpress. I am using xampp to create a local wordpress website and my website run under: localhost/mysite. I want to import my local website to my live website https://vsaftest.wordpress.com/ by going to the setting of my local website and then changed the wordpress Address and site address from http://localhost/mysite to https://vsaftest.wordpress.com/. After that then I can not access to my local site using http://localhost/mysite anymore, and inside the website https://vsaftest.wordpress.com/ there is nothing there also. I know that I made a mistake here but then anyone can help me how can I change back so that I can access my site from localhost :(
I've never used Wordpress before, but going purely from your desription, you seem to think that changing a setting on and for your local machine will somehow affect the settings on a remote machine.
and inside the website https://vsaftest.wordpress.com/ there is nothing there also
But was there nothing there beforehand either? In other words; Nothing's changed?
I think the reason you cannot view your local site anymore is precisely because you made the change you said you did. Instead of its changing the remote machine (which it probably doesn't do...I don't do WP dev, so I don't know for sure) it changed your local machine.
Can you not just change wordpress Address and site address on your local site back to what it was before?
There are many pitfalls one might encounter when moving a Wordpress website from a local development environment to production. Here are the main things to remember and look out for.
Htaccess
When developing in Xampp it's very common to include the website's directory name in the .htaccess' RewriteBase and RewriteRule. Assuming your production website will be situated in the root directory you'll want to remove the directory references from your .htaccess file.
For example your development .htaccess file might look like this:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /mysite.com/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /mysite.com/index.php [L]
</IfModule>
# END WordPress
But in production you'll need to adjust it to look like this:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
One good development practice you can adopt is creating .live and .dev htaccess files. Create .htaccess.dev and .htaccess.live files and store your development and production htaccess data in them respectively. Your real .htaccess file will then contain the current active data and you can easily copy/paste from the .dev and .live files to it if needed.
Database
When you move a Wordpress website to production you must also create a production database for it. Make sure the database created has the same collation as the development one and that the database credentials in your wp-config.php file are updated to reflect the production database user, password, etc. Remember that if your WP_DEBUG variable is not set to true database errors will not be shown if a database connection error occurred in your production website. Because of that database errors in production more often than not lead to a "white screen of death".
Another thing one must make sure (and you already mentioned in your question) is that the siteurl and homeurl keys in your wp_options table are updated to reflect the production website url. In case multiple domains exist (for example .com and .co) one can enforce the correct url by defining the WP_SITEURL and WP_HOMEURL constants dynamically within the wp-config.php file.
PHP version
Last but not least, make sure the PHP version required for your website is compatible with the production server's PHP version. 2017 is a transitional year in terms of PHP support. Whereas Xampp already supports PHP 7 sadly many servers still do not.
I'm having a hard time figuring out why my rewrite rules work perfectly online (the site is up and running), but fail when I'm trying to run a local copy on my mac. I'm not using MAMP o LAMP and I have installed apache and php manually. Apache is 2.2.26 and php is 5.4.20.
There are more rules in my .htaccess file, but the ones I'm concerned about are these two:
RewriteRule ^category/([a-zA-Z0-9_-]+)/([a-zA-Z0-9_-]+)/?$ category.php?slug=$1&page=$2 [L]
RewriteRule ^category/([a-zA-Z0-9_-]+)/?$ category.php?slug=$1 [L]
Basically the variables are not being passed to the php file. Besides this, the rule below works perfectly fine! Even on my local setup I can't see any difference except the fact that I have two rules beginning with "^category/"
RewriteRule ^project/([a-zA-Z0-9_-]+)/?$ project.php?slug=$1 [L]
Any clue why this works online (ubuntu) but fails locally?
I'm going to guess that you have multiviews turned on. This causes mod_negotiation to fuzzy match requests to file-path resources. So when it sees /category/something and sees the file category.php, it sends the request right to the php file (in this case, ala PATHINFO) thus completely bypassing mod_rewrite.
Try turning multiviews off:
Options -Multiviews
I am trying to run laravel4 on a service that cannot use Apache or nginx.
everything is good till I wanted to use Routes on my project.
I've tried using /index.php/... on the URL but could not make this work.
is there any way to force laravel not to use .htaccess file or any ways to use raw PHP routing?
Try setting the "application.url" option in one of configuration files, probably in app/config/application.php or application/config/application.php:
https://github.com/laravel/laravel/blob/4cb904f44d24f856ec9c1040d2198ed8f009723b/application/config/application.php
Set it to http://127.0.0.1:54007/index.php. Now when laravel creates url it will use this as a root and the final urls should be like http://127.0.0.1:54007/index.php/account/signin.
Also you need to modify PHP Desktop settings so that it uses a fixed port. Edit settings.json file and set it like this:
"web_server": {
"listen_on": ["127.0.0.1", 54007],
In laravel's .htaccess I've found this:
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>
So it should work fine to add "/index.php" to root url, because this is what apache's mod_rewrite does.
If something doesn't work, take a look at some other files named "url.php", "uri.php".
Let us know if that works.
EDIT.
You may also try setting root url to "index.php", without the "http://". This way it wouldn't be required to set a fixed web server port.
UPDATE
There was a bug in Mongoose web server in PHP Desktop, that prevented urls like "index.php/company/5" from working properly. See the __fix_mongoose_env_variables() php function in Issue 137 that fixes it:
https://code.google.com/p/phpdesktop/issues/detail?id=137
I have a basic MVC system that is sending POST data to URLs such as
admin/product/add/
But this is giving me an error
Forbidden
You don't have permission to access
/admin/product/add/ on this server.
Additionally, a 404 Not Found error was encountered while trying to
use an ErrorDocument to handle the request.
The RewriteRule is simply
RewriteRule ^(.*)/$ index.php?uri=$1
Last time I saw this on a server changing file/directory permissions to 755 seemed to fix it but not this time. I have never really understood the reason for the error so was hoping someone may be able to provide some more information?
You have 2 errors:
You don't have permission to access /admin/product/add/ on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
The 2nd one is quite certainly a consequence of the same bug. You may have something in your apache configuration which remove 404 errors from default http server handling and push it to your php application, if this php application was working we would have a nice 404, but...
The first one tells you your php application is not running at all.
So. This first error tell us that apache did try to directly access the directory /path/to/documentroot/admin/product/add/ on your server and to produce a listing of it (well a listing of the directory content would be done only if apache were authorized to do so). But of course this is not a real directory on your server. It is a virtual path in your application. So apache ends up with a 404 (which leads to error 2).
The application handles a virtual path, apache does not manage it. The RewriteRule job is to catch the requested path before apache is trying to serve it and give it to one single php file (index.php) as a query string argument.
So... this rewrite rule was not applied. Things that could prevent this rule to be applied are numerous:
mod_rewrite not activated: is the module present and enabled (RewriteEngine on)?
syntax error: mod rewrite syntax is quite hard to read, sometimes really complex. But here it seems quite simple.
The RewriteRule resulting file is maybe not a valid target for apache. If the index.php file is not present in the DocumentRoot, or not readable by the apache user, then apache will fail. Warning: having a file readable by the apache user means having read rights on the file but also execution rights on all parents directories for the apache user. This is where your classical chmod/chown solutions are fixing the problems.
The rule must be in a valid configuration file. Is this rule in a an apache configuration file, inside a Location or Directory section? Or maybe in the global scope -- this may alter the rewrite Rule syntax--. Or is it in a .htaccess file? If it's a .htacces does apache reads the .htacces files and are mod-rewrite instructions allowed there (AllowOverride None). Isn't there others .htaccess files taking precedence?
So to fix the problem:
If you have an apache version greater than 2.2.16 you can replace the RewriteRule by FallbackRessource /index.php to check that this does not come from a mod-rewrite problem.
try to directly request index.php, so that at least a direct request to this file does work
try to directly access a valid ressource on the documentRoot (a txt file, an image, something that should not be handled by the rewrite but directly served)
check that if any of your virtual paths could map real physical paths Apache is not trying to serve the physical one (like when you write a RewriteCond %{REQUEST_FILENAME}-d) but really push the path to index.php
check apache error logs.
debug mod_rewrite with RewriteLog and RewriteLogLevel
collect facts, settings and tests, and then push that to SO or Servfault.
So the problem is quite simple: the php application is not receiving the request. But there are a very big number of ways to end in this state. The message in itself is not very important. The only way to find the error is to check all parameters (or to have years of bug fixing experience and developing a pre-cognitive intuition organ for lamp bugs -- usually a beard --, like admins). And the only way for us to help you is to find strange facts in a big list of configuration details, this is why good questions contains a lot of informations, even if all theses informations looks simply "classical" for you.
EDIT
To clarify the problem you should edit your answer, track the POSTÂ requests with tools such as Chrome developpers tools or firebug (keep the network tracking in record mode to catch several POSTS) or try to replay the post with Live HTTP headers reply. You should try to isolate the problematic POST and give us details. Debug is not magical.
Now I know one magical random POST failure. It's the empty GET url bug. It could be that (or not). If you have one empty GET url hidden somewhere (<IMG SRC="">, url() in css, or an empty LINK in headers for example. As theses hidden POSTÂ are defined in HTTP as "replay-the-request-which-launched-the-source-page, and some browsers even replay the POST that gives you the page if they found one. This could lead to broken hidden POSTS.
It could be also that the POST is not sent to the right server. Hard to say. So please collect informations from your comments, add some more network analysis and edit the question which is now really containing not enough facts.
Try this:
RewriteCond %{REQUEST_METHOD} =POST
RewriteRule ^(.*)/$ index.php?uri=$1
Use this:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.php?uri=$1 [L]
Also use only www or non-www domain but not both at the same time. Redirect users with htaccess where you would like like to...
NonWWW to WWW:
RewriteCond %{HTTP_HOST} !^www\.(.*)$ [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]
WWW to NonWWW:
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^www\.(.*)$ http://%1/$1 [R=301,L]
When I go to
http://localhost/api/auth/login
I get what I expect.. some data that lets me log in.
However, when I go to
http://myurl.com/api/auth/login
I just get
{
"error": {
"code": 404,
"message": "Not Found"
}
}
Currently we have 2 people working on this project, and both of us, when we run it from our local machines, have no issues. We're to the point where we are putting the app on to a hosted server so that we can start testing it outside of our own machines.
The code is identical, and I know this because we use a git repository in which the server is also pulling from.
My machine is a mac, my buddy's is a windows machine, and our host is a linux box. This shouldn't really matter, since all of them should work with mod_rewrite, a requirement for Restler 3.
The only other details I can think of is that the server is hosted by HostMonster, running PHP 5.4.7
Any help would be GREATLY appreciated. Do you need more information?
=== Edit:
This is my .htaccess file. Also, the server runs CGI/FastCGI not mod_php
Options -MultiViews
DirectoryIndex index.php
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^$ index.php [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php [QSA,L]
</IfModule>
<IfModule mod_php5.c>
php_flag display_errors Off
</IfModule>
I just googled 'fastcgi mod_rewrite' and none of those links helped :P
When ever you come across such issue first try without url rewriting
instead of
http://myurl.com/api/auth/login
try
http://myurl.com/api/index.php/auth/login
If it works you will know that the issue is with url rewriting
Since you are using CGI/FastCGI make sure you have set
cgi.fix_pathinfo=0
in your php.ini it will make sure that path info is passed to Restler properly so that restler can find the route
If it does not work with index.php in the url, you can try generating and verifying routes.php as explained below
routes.php
Restler looks at all api methods and its doc comments to generate routes accordingly every time we run it on debug mode. When we run it on production mode it captures the information in routes.php and uses it instead of generating routes every time thus improving efficiency.
You can check for the generated routes by initializing restler in production mode and refresh on every call
$r = new Restler(true, true);
and then check the generated routes.php
If your routes.php contains no routes it will appear as follows
<?php $o = array();
// ** THIS IS AN AUTO GENERATED FILE. DO NOT EDIT MANUALLY **
return $o;
If this is your case, it means some how autoloader is failing to load the api class, you can confirm it by manually including the API classes
If it starts to work, please file a bug using github issues stating that the autoloader is failing for your server configuration and give us more detils so that we can reproduce it and fix it.
If it still does not work, please file a bug using github issues mentioning your server configuration and give us any detail that could help so that we can reproduce it and fix it.
Thaks to you, we will also write a trouble shooting guide based on above to help the restler community :)