In September 2013, I found myself unable to log into this site.

I would be presented the Login screen, enter my User Name and Password and be brought right back to the same screen.

Logging in with an incorrect user name or password would result in the familiar “No” shake of the login screen.

While this solution worked for me, there may be other reasons why you are not able to log in.

These instructions are for WordPress 3.7.1, but should be the same or similar for other versions, but no guarantee is made.

Logging In Solution #1

http://<your site url>/wp-admin

1) Enter <your site address>/wp-login.php into the URL bar and press Enter. This should bring you to the WordPress login page:

2) Try to log in.

3) If this fails, add (or remove) the www. prefix to your website URL.

If this worked and you are logged in, then go to the step Setting the WordPress and Site Addresses to be the Same

Logging In Solution #2

1) Login to you web hosting account.

2) Start phpMyAdmin.

3) Expand your WordPress database by clicking on the icon:

4) Click on wp_options:

5) Change the URL entries in siteurl and home so that they are both identical (either with a preceding www. or without). Edit the fields by clicking on the Edit label:

Setting the WordPress and Site Addresses to be the Same

:

2) Click on General:

3) Edit the fields WordPress Address (URL) and Site Address (URL) to be the same (either with or without a preceding www.):

The post WordPress – Can't Log into your Website appeared first on Complete, Concrete, Concise.

Between 30-August-2013 and 01-September-2013, Complete, Concrete, Concise had its web hosting suspended with a demand that the WordPress installation be deleted.

Not wanting to delete my installation and then reinstall (and hopefully restore all data correctly), I investigated.

Symptoms

Most likely, your web hosting provider will inform you that your account has been suspended because your WordPress (or other PHP based application) is generating a lot of core dumps and playing havoc with their server. In my case, I was asked to delete my WordPress installation.

Alternately, you may notice there are a lot of core.xxxx (xxxx being a four digit number) files in your WordPress directory.

The Cause

When your error_log file gets to be 2,147,483,647 bytes long, PHP will start crashing and generating core dumps. This is because PHP cannot handle files larger than 2GB.

error_log is where PHP stores messages about any errors it encounters.

The most common cause of errors is a corrupt MySQL database file.

The Fix

1. Delete the file error_log.
2. rename index.php to something else (xxx_index.php is good)
3. inform your hosting provider that:
   1. you suspect the problem was PHP’s inability to handle and error_log larger than 2GB and you have deleted it
   2. you have deactivated your WordPress account by renaming index.php
   3. you would like access to your account restored so you can run MySQL applications to check and repair your database if necessary
4. Fix the database (if it is corrupted). Instructions for checking and repairing a database can be found here.
5. restore the name of the file in step (2) back to index.php
6. go to your website and browse a few pages.
7. verify that core.xxxx files are not being generated. If they are being generated, than you probably have some other problem.
8. verify that the file error_log is not being generated. If it is being generated, it is a good idea to look at it and see what errors are occurring. Depending on how quickly error_log is growing, it might be a good idea to suspend your site again by renaming index.php

The post WordPress Generating Core Dumps appeared first on Complete, Concrete, Concise.

Photon works by using wordpress.com to cache and serve up images from your site.

Since I am always looking for ways to reduce my bandwidth (and speed up performance), I enabled it.

I have observed a reduction in the bandwidth:

The 20^th, 21^st, and 22^nd averaged about 3% fewer page hits than on the 25^th – but it is obvious that (with Photon enabled) I used less bandwidth on the 25^th .

The 23^rd and 24^th are the weekend, so there is always a drop in traffic. I suspect the spike seen on the 24^th is related to enabling Photon.

Based on very limited data, Photon appears to be working well and is saving me some bandwidth. It does not require me to change anything about my site (always a serious bonus).

The post WordPress – Preliminary Impressions of Photon in JetPack appeared first on Complete, Concrete, Concise.

These instructions are for WordPress 3.X that is being hosted on a web server that provides access via cPanel version 11.34.1.

The instructions may be the same or similar for other version combinations or interfaces other than cPanel, but no guarantees are made.

Possible Symptoms

You may encounter one or more of the following symptoms:

• All content and comments on your WordPress site have vanished:
  
• All content and comments show as having vanished in the dashboard:
  

• Trying to go to a particular page (that you know exists) results in an Http 404 Not Found message:

  

• You get a database connection error message:
  

Possible Cause – Corrupted Database

While it is possible that you have been hacked, it is far more likely that your WordPress database has become corrupted and is no longer able to serve up content.

I am not sure why this happens, but between November-2012 and March-2013 this has happened four times to me.

Fixing the Problem

There are two ways to fix this problem: (1) restore the database from a backup copy (preferred), (2) fix the database (only if you don’t have a backup).

Checking if the Database is Corrupted

Before doing anything rash, it is always best to check that a corrupt database is the problem.

1) Log into your web hosting account (this is not your WordPress powered website). If you web host provides a cPanel interface, it might look something like this:

2) Click on MySQL® Databases:

3) Locate the section titled Modify Databases. Select your database in the Check DB listbox and click on the Check DB button:

4) Verify whether the database has errors or not. If the database comes up without warnings or errors then you have a different problem that will not be fixed by this tutorial. If it does have warnings or errors, then the steps in this tutorial may help:

Fixing the Database

1) Click on MySQL® Databases:

2) Locate the section titled Modify Databases. Select your database in the Repair DB listbox and click on the Repair DB button:

As the database is being repaired, confirm that there are no errors. If there are errors, then run the Repair DB again (I have had to run it up to two times to repair a database):

Restoring the Database from a Backup

1) Click on Backups:

2) Locate the section called Restore a MySQL Database and click on Browse… and select the backup database from your computer. Click to upload the database.

During this process, not much may seem to be happening.

The backup database has to be uploaded from your system to your service provider.

Once it is uploaded to the service provider, the existing database is rebuilt from the uploaded one.

The whole process looks something like this:

The post WordPress – All Your Content has Vanished / Error 404 on All Pages appeared first on Complete, Concrete, Concise.

UPDATE 14-March-2013

It has been over one year since I have disabled W3 Total Cache and the problem has not reoccurred, thus leading me to suspect the problem was caused by W3 Total Cache since the problem only occurred when I was using W3 Total Cache.

In December 2011, I had trouble logging into my site. I kept getting an Error 404: Not Found message. I documented what I did to resolve that here.

In February 2012, it happened again. After waiting 48 hours for the problem to resolve itself – and it didn’t – I began troubleshooting again. Fortunately, I had a few more facts this time around and a lot less panic or worry about having my site having been hacked.
What I knew: (1) my site was still accessible, (2) other people did not have problems leaving comments (during that time I received 1 legitimate comment, 3 SPAM comments, and 1 pingback) – even though I wasn’t able to leave a comment. (I tried a different computer, I tried a different browser, I tried a different OS, I tried a different IP address (depending on what type of Internet connection you have, turning your modem on and off may get you a new IP address) but none of them worked. The only thing I didn’t try for logging in from someone else’s Internet connection.)
I was able, though not consistently, to login by clicking on an action link in the e-mail WordPress sends me to tell me I have a new comment (since I have comment moderation turned on, WordPress e-mails me every time there is a new comment). Even if I was able to login, I was not able to do a lot in the Admin panel (replying to or deleting comments wouldn’t work).
I checked the WordPress error logs, there was nothing in them to suggest a problem.
I searched the web for solutions. Again, nothing useful came of it – lots of people have experienced this problem, but no useful solutions were offered (and those that were offered were more of the “do something – anything – and the problem will miraculously go away” type.
Checking my server logs, I could see 404 pages being delivered when I tried to log in. Nevertheless, the pages in question should exist (and I double checked that they did), so it didn’t make sense that they couldn’t be found.
Finally, while studying the WordPress login help page, and double checking everything on the page (even those I didn’t think made sense), I decided to try manually resetting my site’s URL as described in the section Site URL Redirecting. This worked! And it was reproducible – if I changed my URL I was able to login, if I set it back to the original URL I couldn’t login. This was good because a reproducible problem means the solution works – I think.
My original site URL was http://complete-concrete-concise.com – notice the lack of the www.prefix. While my site was and continues to be accessible without using www. before the name, when I changed it to http://www.complete-concrete-concise.com my login problem went away. And when I removed the www. the login problem came back.
What causes this? To be honest, I don’t know. My suspicion is it is a problem with the name server (the name server is a Internet server that looks up the site name and returns its Internet address).
For the first 8 months this site used WordPress (previously, I used Joomla!), this site used the name servers of my web host – without this problem occurring. Since switching to CloudFlare’s name servers (because I use them to relieve some of the bandwidth pressure on my web host) in December 2011, I have encountered this problem twice in 3 months. I don’t have enough evidence to conclusively claim this but others have had this problem with their web hosts
From what I can see, my DNS records with CloudFlare are fine, yet, changing my WordPress URL to use the www. prefix solves the issue – at least for now).

1) Login to your web hosting control panel. This is not your WordPress admin panel. For many users this will be cPanel, but your webhost my provide you with a different website administration panel.
2) Click on the phpMyAdmin icon:

3) Click on your WordPress database in the left-hand side panel. If, like me, you run several websites from one account, you will have to find the appropriate database (in my case, it is not too hard, since I have one Joomla! site and one WordPress site and the database names are pretty obvious):

4) Click on wp_options in the left-hand side panel:

5) Locate the option name siteurl and click on Edit:

6) Change the URL name to your alternate one. My original URL was http://complete-concrete-concise.com. I changed it to include the www. prefix. If your original URL contains the www. prefix, and you have set up your name server to serve both versions, then remove the www. prefix. Click on Go to save the settings:

7) Check that you are able to login in to your website.

The post WordPress – Error 404 When Trying to Login – Take 2 appeared first on Complete, Concrete, Concise.

This post was my original attempt at solving the Error 404: Not Found error when trying to login to my website.

It happened again and after waiting 48 hours for the problem to clear – it didn’t – I started searching for another solution.

My second solution (which was reproducible) can be found here

I think a reproducible problem / solution is better than a problem that mysteriously goes away after a while.

However, I am not 100% certain this problem is fully resolved. I will have to wait and see if it happens again.

Yesterday, I got a Error 404: Not Found error when trying to login to my site:

My first thought (well, after trying to login in a few times) was that my site had been hacked, then I focussed to resolve the problem.

How I Wasted My Day

The first thing I did was shut down my browser (IE 9), clear the cache and temporary files using CCleaner, and restart the computer. I thought it might be some sort of connection problem. That didn’t work.

Next I shut down my computer, turned off my modem and did some other things. I thought it might be a connection problem based on my IP address. My web host will automatically block IP addresses for an hour if it perceives a threat from that IP address. Turning off the modem means I will be assigned a new IP address when I turn it on a little later. That didn’t work.

I thought it might be my webhost acting up, so I logged into the CPanel backend, but everything seemed to be working fine.

To ease my concerns that I might have been hacked, I checked the date stamps on the WordPress files. They were all at least two weeks old (the last time I did an update) – no files had been changed in the past day – so I wasn’t worried about having been hacked.

I tried accessing my site through w.bloggar (a blogging client, similar to, but older, than Windows Live Writer – you can read why I use w.bloggar instead of WLW here), but that didn’t work, It told me that the response it received back was invalid.

Then I thought it might be CloudFlare acting up. This was harder to troubleshoot. I could always change the name servers back to the original name servers, thus bypassing CloudFlare’s name servers – but it would take up to 48 hours for the change to percolate through and, by that time, if it was a temporary issue, it might be resolved. I decided to (1) set CloudFlare to development mode – this means that for the next 3 hours, they pass all requests directly to my webhost. That didn’t work, then (2) I tried bypassing CloudFlare by accessing my site directly using my site’s IP address. That didn’t work either.

At this point, I decided to search the web for help – turns out, I am not the only one to ever experience this problem.

This site recommended changing the permission attributes on all the files and directories. Personally, I didn’t see the point. I checked my file permissions and they all seemed fine. I did not run the recommended fix because while some claimed it worked, others claimed it didn’t. I also had no desire to play with the core install (well, at least not yet).

WordPress has its own help page for login problems. None of the solutions worked. Some of them actually render your site unusable. For example, the codex states: Rename the active theme folder… Once renamed, WordPress will revert to using the WordPress TwentyEleven theme., doing that results in a site that just doesn’t work.

After a lot more research, some sites (a little past halfway down the page, comment by dremeda) suggest replacing the core WordPress files with ones from a clean install. Ugh! That sounds positively dangerous.

Instead, I created a new WordPress site with my webhost – this one allowed me to login. Then I zipped up the working and not working sites and downloaded them. Then I unzipped them and compared the files using emacs. There was no difference between the files. Hmm.

I then decided it would be safe to replace the core files of the “not working” WordPress site with the core files of the “working” WordPress site. This did not work either.

Being tired and out of ideas, I went to bed. This morning, everything worked fine.

The post WordPress – Error 404 When Trying to Login – Take 1 appeared first on Complete, Concrete, Concise.

Here’s Site Stats as seen in IE 8 (click for larger image):

Problems are:

1. it looks ugly, nice tables and formatting are all missing
2. the bar graph at the top doesn’t display
3. the Yesterday tabs do not work – clicking them does nothing
4. while the weekly tab does work, again the formatting is ugly and broken
5. IE 8 reports Errors on Page

It renders and functions fine in FireFox. The formatting is nice, the graphs show up, and the Yesterday tabs work. This is Site Stats as seen in FF (click for larger image):

The post WordPress – Jetpack 1.2 Broken on IE 8 and IE 9 appeared first on Complete, Concrete, Concise.

It gives the following notice:

Keep in mind we don’t count your own visits.

Unfortunately, this is not completely true – if you are not logged in, it will count your visits to your site.

To avoid counting your own visits to your site, you (1) must be logged into the administrator panel before browsing your own site, (2) must have Jetpack set to ignore logged in visitors (of course, this means it will not track any other logged in visitors too):

1) Click on Site Stats from the Jetpack menu. Then click on Configure on the WordPress.com stats module:

2) Ensure the Count the page views of registered users who are logged in. is NOT checked:

This is rather disappointing – I imagined they would be using a cookie to track my visits and, thus, ignore them. At least it explains the sudden “surges” I sometimes saw – it wasn’t other visitors, it was me.

The post Jetpack Site Stats can be Misleading appeared first on Complete, Concrete, Concise.

These instructions are for WordPress version 3.1, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.2.0, and 3.2.1 into a folder other than \wordpress under XAMPP 1.7.3 running on Windows XP with Service Pack 3 installed.

You may want to install into a different folder for various reasons, the two most common being: (1) you want to have multiple WordPress installations, or (2) you want control over where the files are installed.

These instructions should be the same for other versions, but no guarantee is made.

Assumes you have XAMPP installed.

To install WordPress to something other than the default wordpress directory, you need to (1) install WordPress into that directory and then (2) move all the files found in the wordpress directory up into that directory and, (3) delete the wordpress directory.

(1) Extract WordPress into the desired directory under htdocs:

(2) Ensure the Show extracted files checkbox is ticked and click on Finish:

(3) Open the wordpress folder by double-clicking on it:

(4) Select Select All from the Edit menu (or press Ctrl+A):

(5) Select Copy from the Edit menu (or press Ctrl+C):

(6) Click on the back button to return to the previous folder:

(7) Select Paste from the Edit menu (or press Ctrl+V):

(8) Right-click on the wordpress folder and select Delete from the popup menu:

If you want to access the installed site using a “real” web address (like www.wordpress.3) instead of localhost/path-name, you can find instructions to do that here.

The post How to Install WordPress into a Folder Other than \wordpress under XAMPP appeared first on Complete, Concrete, Concise.

This tutorial describes how to install WordPress version 3.1, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.2.0 and 3.2.1 under XAMPP version 1.7.3 on Windows XP.

The procedure should be the same for other version combinations, but no guarantee is made.

Assumes you have already

• installed XAMPP. (Installation instructions can be found here.)
• created a MySQL database. (Creation instructions can be found here.)

I do not recommend using XAMPP 1.7.4 because of configuration and functionality issues with that version.

Some images may be clicked for full size versions (if your cursor changes when you move over an image, there is a larger version available).

Downloading WordPress

1) Download WordPress from here. Click on the Download WordPress button:

2) Click on the save button and remember where you saved the file:.

Extracting WordPress

3) Open the downloaded file by double-clicking on it. From the File menu, select Extract All. NOTE: this step assumes Windows provides archiving functionality for you. If you have installed a different archiving program, the specific steps for extraction will be different.

4) Extract the WordPress files into the htdocs folder in your XAMPP folder. By default, XAMPP would be installed to your C:\ drive, so you would enter C:\xampp\htdocs as the directory to extract to. (In my case, I installed XAMPP to my D:\ drive). WordPress will be extracted into a folder named wordpress. NOTE: if you want to install WordPress into a different directory under htdocs (say my_wordpress or MySite or whatever, then instructions for doing this can be found here.

5) Click Finish when the extraction is complete. You can uncheck the Show extracted files checkbox because we don’t need to see the files.

Setting up WordPress

6) Launch your browser and type http://localhost/wordpress into the address bar. What follows http://localhost/ is the directory you installed WordPress into (unless you changed the directory in Step (4), this will be wordpress

7) Click on Create a Configuration File at the notification screen advising that a wp-config.php file needs to be created.

8) Click on Let’s go! to begin configuring and installing WordPress:

9) Fill in the database configuration information and click on Submit::

• Database Name: this is the name of the database you created. Database creation instructions are here. (The default is wordpress.)
• User Name: if you created a MySql User for the database (not necessary), enter the name here. Otherwise, use root.
• Password: this is the password associated with the user name entered above. If you used root as your username, then leave the password blank (the default XAMPP install does not assign a password to root). Otherwise, enter the password associated with the User Name.
• Database Host: localhost (default setting)

10) Click on Run the install:

11) Fill in some information about your site and site administrator and then click on Install WordPress.

• Site Title: Enter the name of your website.
• Username: Enter the username that will be used for logging into the backend of your WordPress site. The default is admin.
• Password: Enter a password that will be used to login to the backend of your WordPress site. There is also a strength indicator which shows you how secure your password is.
• Your E-mail: Enter an e-mail address that your site will send notifications to.

12) Click on Log In to log into your WordPress site.

The post Installing WordPress Under XAMPP appeared first on Complete, Concrete, Concise.