WordPress won’t update

I’ve had issues with WordPress failing to update.  After searching forever and manually updating myself for months, I found the problem.  Check the /wp-contents/upgrade folder for any files.  A previous failed upgrade to core, themes or plugins will stay there and silently cause WordPress to fail to update without any notices.  Further more WordPress doesn’t make attempts to clean up the folder.

Pastebin rewrote

I have taken my original code I wrote for my SMF powered pastebin and rewrote this script. This was a massive rewrite from the original code and hopefully it works out well for anyone else who is looking into using it.

I wrote it so it should be plugable with different databases, user information and templating engines. The design was mostly to implant it into my mixed environment of SMF and WordPress, but also to make it robust so it could be used in other ways.

The source of the code is up on GitHub at https://github.com/jdarwood007/pastebin

SMF in WordPress

For some reason, while using WordPress and including SMF’s SSI.php, it would not detect my logged in SMF session. Baffled and almost thinking this was a SMF bug of some sorts, I began to debug this process.

Well it turns out it is sorta a SMF old PHP support issue, but the problem lies in WordPress. This is the function in WordPress wp-includes/load.php

The problem here, is that they add magic quotes to the cookie. Not quite sure why they are even doing this. But it broke adding SMF. The part in SMF which failed because of this is in SMFs Sources/Load.php in the loadUserSettings function

Because of old PHP support in SMF, its trying to combat a cookie security issue that existed below PHP 4.3.9. Now I don’t use that version, but I rather not strip out the code. The preg match was failing because it was not finding that valid string in the cookie. Since all the double quotes where escaped with a slash \.

For my code, I called in Settings.php from SMF and then did a stripslashes on the cookie. Then I included SSI.php, with the results I expected of it finding my active SMF session.

I should note because SMF uses a lot of global variables, that I had to globalize all of those before hand. I just borrowed the globals from SSI.php and put them into that scripts function.

WordPress templates on non wordpress pages

I have a couple pages such as my password generate that are non wordpress templates. However I want these to be styled as if they where from my wordpress. So after some google searches, I came up with very little information. I decided to dive into the code and came up with something that works for what I need it to do and requires little code edits to any of my pages to work.

This does also require a template edit to your wordpress templates. Sadly I couldn’t avoid this, I looked around and tried to see if I could modify the_content(), however it doesn’t look very pleasant to do so. I might in the future look into doing this. If somebody has a better solution that requires no wordpress template edits, please let me know. Back on topic, I modified page.php in my template and changed:

To this line:

Next I will just dump a file I named wp-ssi.php and explain how it works at the end.

Now for all my files I add at the very top. Of course, you need to substitute the path to match yours.

As for wp-ssi.php, I will can explain more about how that works.
Continue reading

Disabling php files in wordpress upload when using nginx

This isn’t well documented anywhere for nginx. In fact it is sorta hidden and hard to find. Nginx does support a way for me to disable php from being executed in my uploads directory.
The way I came across actually I am loving, as I am able to control how content is handled actually. This is a plus on the server admins end.

Simply put, I setup a location to only run on my uploads directory. Then I change the types and only defined jpg, gif and png. All other files get sent as a download. Finally since I run php as fastcgi, I setup a nested location to run for php files and tell it to stop evaluating rules.

In fact, this is all actually nested in my primary location /. I did it this way as it worked the easiest. Although I am sure I could remove that nesting.

Continue reading

Nginx with wordpress seo urls

I have been testing running my site with Nginx instead of Apache.  One of the issues I have ran across is getting wordpress to work right since I use the SEO urls.  Not that SEO urls make any difference, its a fun challenge to just work with.

One issue I ran across is getting these urls to work right.  After some reading, I did discover that there is a simple code for the rewrite that is used in apache.  However I couldn’t get this to work as the document examples showed.  I found out after testing, that it must exist in the location attribute.  Which is actually better for the setup.

This makes things work as they should.


If has been suggested by the Nginx team to be avoided.  So here is another solution that avoids if:

Protecting my wordpress folders

WordPress by default doesn’t protect its wp-includes and wp-content folders. While WordPress doesn’t do stupid things in most of these files, they still don’t do a simple defined check to ensure we came from an a privileged file. SMF does this and it prevents direct loading of any of the Source files.

To get around this is not as simple as it should be.  To start with, I added a “.htaccess” to my “wp-includes” folder with the following contents.

Deny From All

However, that broke the built in rich editor in WordPress.  So, now to edit “wp-admin/includes/mainifest.php” and change the following.

echo “<script type=’text/javascript’ src=’$baseurl/wp-tinymce.php?c=$zip&amp;$version’></script>\n”;

All I did was change .php to .js since after reading the directory I came to figure out the .php version is just a compressed version.  I removed the “$zip&amp;” part as well since it didn’t make sense to keep it anymore.  the “c” argument just tells it whether to compress or not.  So this is my resulting change

echo “<script type=’text/javascript’ src=’$baseurl/wp-tinymce.js?$version’></script>\n”;

However, since I was loading some content from my includes folder now, a tweak needed done to my “.htaccess”

<Files *.php>

Order Deny,Allow

Deny from all

Allow from localhost


Simply put, that will deny access to all php files in my “wp-includes” folder.  That worked and a simple duplication of the file to my “wp-content” folder produced the same results.  However, I still wasn’t done.  A simple .htaccess password protected directory for my “wp-admin’ would offer a very basic block to help prevent unauthorized access.  Although it isn’t using a very strong password or username on it, it still prevents the fly-by attacks.

AuthType Basic
AuthName “Restricted Access”
AuthUserFile “/path/outside/webroot/wordpress-admin.access”
Require valid-user

Now I just simply needed to populate that file.  Since I have apache installed on my laptop, I simply opened Terminal and ran “htpasswd -n username” and gave it a password at the prompts.  Then I simply just copied the line from the window to my .access file and saved.  Everything works and my entire wp-admin folder is protected from unauthorized web access.

However, “wp-login.php” contains three calls to css files in the wp-admin folder.  A “login.css”, “colors-fresh.css” and “logo-login.gif”.  Simply copying those three files to my theme is half the problem resolved.  Then just modifying wp-login.php to directly call those files rather than the functions that previously called them.  “login.css” needs to be modified and the path to the logo-login.gif file needed adjusted.

Simple secure login for wordpress

This is a simple way to setup a secure login for WordPress.  Simply editing “wp-login.php” and looking for:

/** Make sure that the WordPress bootstrap has run before continuing. */
require( dirname(__FILE__) . ‘/wp-load.php’ );

Add after that:


Now when accessing login and registration pages, the browser redirects to the secure version.


After looking into “wp-settings.php” some more, I found the following setting:

if ( !defined(‘FORCE_SSL_ADMIN’) )
define(‘FORCE_SSL_ADMIN’, false);

Copying the define line to my “wp-config.php” and changing false to true has ensured this will work even if “wp-login.php” ever gets updated.