I am getting an error on installing habari:
The installer couldn't verify your
settings, possibly because your server
is not correctly configured. See the
manual for information on how to
correct this problem, or continue
without database verification
Any idea on what the problem could be? I am quite sure that the database information I am putting is correct.
My crystal ball is a little hazy.
Please provide the following information:
Platform: Linux, Windows, MacOS, OpenSolaris ?
Hosting provider ?
Database: MySQL, SQLite or Postgres (include version number) ?
Web Server: Apache, Lighttp, Nginx ?
PHP version and configured extensions - a link to the output of phpinfo() is always very useful.
Habari version - latest stable version or trunk ? If the latter, specify the exact SVN version number.
Also consider cross posting to the Habari mailing list where you are likely to get prompt assistance from other Habari users.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteBase /
RewriteRule . index.php [PT]
Habari doesn't write the htaccess. I manually added this and everything was fine.
You might want to write manually the HTACCESS.
here:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteBase /
RewriteRule . index.php [PT]
Related
I am using GoDaddy Windows Shared Hosting Server to host my WordPress Website. I am NOT using GoDaddy Managed WordPress service (I just copied my files on server, created DB and site works). However, I am facing some issues as follows :
Permalinks do not seem to work - Despite of the fix in .htaccess file for mod_rewrite module OR resetting the Permalink option via Admin Dashboard.
Cannot upload media : I get an error "Cannot upload media to wp-content/uploads" - If I set the upload_path in DB from BLANK to the above path, still the error continues.
To check if I have DB Connection issues: I tried to create a POST and I could do it well. Just that I could not upload MEDIA.
GoDaddy tech support is NOT able to resolve these issues.Meaning their solutions do not seem to work for me. Can anyone help me with my issues ?
1- For the first issue I suggest to use the default wordpress htaccess file which is as following :
# 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
after this go to Wordpress setting and save permalinks again.
2- for second is a privilege issue, download FTP software , ex: "filezilla", connect to your host and browse to uploads folder, right click to 'permissions' and put the privilege as 777
Please try to fix your issue with
# BEGIN WordPress
RewriteEngine On
RewriteBase /stage/
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /stage/index.php [L]
# END WordPress
It seems this is permission issue. Please kindly ask your hosting provider to give full permission for you
I am having a CRAZY error with Wordpress. When I create a new article or edit an old one, I cannot insert hotfile links that go after the first trailing slash.
I'm explaining it better. If in a post I do:
TEST
I can correctly create the article. If I do:
TEST
Or longer link, like:
TEST
I get an instant 403 error when updating the post from administration. This is crazy, and happens only with Hotfile links. Everything else works like a charm.
What could the error be? If it helps, i'm posting my .htaccess, that I never changed from my WP installation:
# 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
Already done repairing and optimization of MySQL DB. Kind thanks in advance to everyone.
I'm a regular WP developer, and I see little bugs like this all the time. Unfortunately, it usually means it's time to go through the tedious work of testing. The problem likely lies either with Apache/htaccess, or in a WP plugin or Theme.
To attempt to eliminate WP as the cause of this specific issue, I'd try creating a php file with the following in it:
<?
if (isset($_POST["field"]))
echo $_POST["field"];
?>
<form method='post'>
<input type='hidden' name='field' value='TEST'>
<input type='submit' value='Test'>
</form>
If clicking "Test" does not result in the same 403 error, then it's something happening with WP specifically. If it does result in a 403, then it's a much more annoying problem that you are going to want to take up with your hosting provider.
If it is a WP problem, the first thing I would do is to start deactivating plugins 1 by 1, starting with the plugins I think are the most likely culprits. If I have no reason to suspect one over another, I just disabled them all, 1 at a time. Once a plugin is disabled, I try to recreate the original issue. If the problem still happens, it's obvious that plugin wasn't at fault, and I reactivate it and test the next one. 9 times out of 10, my issue is found this way. Be careful when trying this, as some plugins will clear their settings when they're deactivated.
If that doesn't solve the issue, I'll try a different theme and see if that fixes it. Obviously if the problem is gone when you try a new theme, you know where your problem is. Again, some themes can have setting associated with them, and changing the theme can lose those settings.
Finally, check your wp-content/mu-plugins folder for plugins that are always active and don't always show up in your list of plugins.
I realize this post is as ancient as time itself but I've run into a similar problem took me forever to figure out what was going on until i realized all I had to do is add:
Options +FollowSymLinks
At the top of the .htaccess file and presto! It worked.
Options +FollowSymLinks
# 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
Credit goes to this good man: http://www.coolestguyplanettech.com/403-forbidden-error-wordpress-htaccess/
I also had a similar issue, apparently wordpress has some problems with some bits of code I tried to add in my post. I managed to bypass the issue by surrounding the code in <pre> tags.
Mostly, 403 forbidden error is because of four reasons 1. File permission. 2. Issue with plugins. 3. Hotlink protection 4. issue with .htaccess file 5. Your CDN(Content Delivery Network). For solving this error you need to check all these aspects to remove the error.
check the file permission as you know
the file has permission for 644 and the directory 755
Deactivate the plugins. Sometimes you might get errors because of plugins
next you need to delete .htaccess file and create a new file with the below code
# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
Next you need to check hotlink protection for your site. As it proved your website to link media or files from other sites.
lastly, you need to check for CDN you can disable it to know if it causing error or not.
I know my answer is late in coming but just wanted to add my 2 cents.
I would recommend checking the .htaccess file to make sure it is similar to below.
# 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
You could try adding Options +FollowSymLinks as adamj stated in his answer so the .htaccess would look similar to below.
Options +FollowSymLinks
# 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
Check to ensure that no plugin are causing the issue. Disable all plugins to see if the issue persist. If it doesnt, it would be a process of elimination to figure out which one is the cause.
Finally, I have removed the .htaccess file and that also worked for me but no .htaccess file would means no URL rewrite unless your web server is otherwise configured.
I hope this helps someone.
what have you done since Wordpress v3.0, all direct PHP files are not working in WP, all are returning 404 page not found, I have created one plugin, it's loading /wp-content/plugins/myplugin/direct.php file and what am I seeing now, it shows me my WP site with title PAGE NOT FOUND 404, help me please I can't work with WP any more, all direct PHP files are not accessible and tracked as 404.
What should I do to turn off that terrible 404 or get my php files loaded.
Check your .htaccess file, maybe all URLs now are mapped to the index.php file of Wordpress.
Based on the provided rewrite rules, I would suggest to use this instead:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.*shop/images/(\d+)/?\??(.*)$ /wp-content/plugins/shopp/core/image.php?siid=$1&$2 [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
I'm not understanding the question. You're saying that you've created a plugin, and it's not calling in the files properly? (I'm assuming by "direct PHP file access" you mean you can't load a particular file that's within your plugin directory?)
Sounds like you're not using the correct paths. You should be using things like WP_PLUGIN_URL constants that are set up for you via WordPress (http://codex.wordpress.org/Determining_Plugin_and_Content_Directories) - i.e it doesn't sound like an .htaccess issue, it sounds like improper coding in the plugin.
Of course, without knowing what code you are using, it's difficult to say what the issue could be.
I'm hoping non-IIS people can help me on this though the issue I'm having is based around an IIS6 server running ISAPI_Rewriter.
The situation is that I'm running Wordpress on IIS6, ISAPI_Rewriter is being used to act as a replacement for mod_rewrite and is functioning properly. My problem is that when I get it to rewrite my URLs for Wordpress (so I don't need the index.php filename in it) it shows a 404. After much searching I found the problem was because part of the ASP.net (or something similar) was adding eurl.axd/[random string] to the end of the URLs and so this was being fed into the Wordpress request and breaking it. I set the Wordpress template to output the requested URL and it looks something like this:
http://www.example.com/index.php/about/eurl.axd/b552863f2d5e9841b5d8b79b44ac02e8/
I believe this is because of the pecking order of various things in the IIS system and the culprit is required to run another part of the project. I'd prefer to keep using ISAPI_Rewriter to pretty up the URLs so I'd like to know this:
Is there any way of getting mod_rewrite to remove eurl.axd/[string] before feeding it on to the system?
My .htaccess file currently appears as such:
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# The following line excludes folders from rewriting
RewriteCond %{REQUEST_URI} !^/folder-name/
RewriteRule ^/(.*)$ /$1 [NC,L]
Thanks for all the help, it is always greatly appreciated.
EDIT: Have adjusted my htaccess based on suggestions and it seems to work well from the brief tests I have carried out. Have posted it below.
RewriteEngine on
RewriteBase /
# This is used to strip ASP.net eurl.axd bits
# from the URL so wordpress can use permalinks
# For the root
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/wp-admin/
RewriteRule ^eurl\.axd/[0-9a-f]+/$ index.php [NC,L]
# For internal permalinks
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/wp-admin/
RewriteRule ^(.*)/eurl\.axd/[0-9a-f]+/$ index.php/$1 [NC,L]
Something like this near the top of your list of rewrites should work:
RewriteRule ^(.*)/eurl\.axd/[0-9a-f]+/$ /$1
I use the following regex as first rule with Ionics Isapi Rewriter for web sites running on ASP.NET 4 on IIS 6 to remedy the problems caused by the breaking change introduced with ASP.NET 4 :
RewriteRule ^(.*)/eurl.axd/[a-f0-9]{32}(.*)$ $1$2
This let me again use extensionless urls.
Note that the second group captures the querystring if present and restitutes it to the rewritten url.
And yes, it's a feature, not a bug.
I ran into a similar issue with v4.0 ASP.Net extension less URL feature on II6 and found a solution through ISAPI Rewrite Module provider, the does not require turning it off. Theissue and the solution as we experienced it is documented here http://www.vanadiumtech.com/OurBlog/post/2011/08/12/Cause-of-eurlaxd.aspx
I have some php scripts in my Wordpress directory and I'm unable to use them. Why? Because Wordpress treat them as posts.
For example:
http://kaptinlin.com/themes/striking/wp-content/themes/striking/includes/sendmail.php
Points to a file and it works.
But on my site when i try to open /wp-content/themes/myTheme/anyDictionary/anyfile.php
it loads:
Not Found
Apologies, but no results were found for the requested archive. Perhaps searching will help find a related post.
Page.
How to fix that?
Thanks
The default WordPress mod_rewrite rules look something like this:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
In essence, this says "pass all requests through WordPress, unless the request corresponds to a real file or directory." So, if you're seeing a WordPress delivered page when you expect the output of a non-WordPress script:
Your rewrite rules differ from the default; paste them for help debugging. Or,
The file may not exist where you think it does.