I received a comment on one of the QD posts earlier today that noted the Facebook link-share button posted an incorrect link on Facebook. These social media buttons exist on the bottom of each article on the Question Defense site. Initially when looking into the issue I was confused because he actual URL that was posted was correct meaning it posted the proper Pretty Link via the WordPress Pretty Link plugin however when I tested the actual link I was redirected to the proper domain but the page display was blank. Below is information on the troubleshooting process I used, what the problem ended up being, and how the problem was resolved.
Pretty Link URL’s Open Blank Page On WordPress Web Site:
Again the issue was that links generated by the WordPress Pretty Link Pro plugin were opening blank pages. I use a third party URL (link.as) which was redirecting to question-defense.com however it was not redirecting to the article itself. Instead of redirecting a blank page would open in the browser thus appearing as if the link was completely broken.
Analyze Web Logs To Hopefully Obtain HTTP Error Code:
The first place I looked was the Apache web logs to see if the details there could shed more light on the problem. Below is what the logs displayed when attempting to open a Pretty Link generated URL.
- 192.168.100.26 - - [25/Oct/2010:14:30:05 -0500] "GET /xwz HTTP/1.1" 301 315 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.41 Safari/534.7"
- 192.168.100.26 - - [25/Oct/2010:14:30:05 -0500] "GET /xwz HTTP/1.1" 500 0 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.41 Safari/534.7"
Notice that the first line is the proper 301 Permanent Redirect that occurs from the link.as domain to the question-defense.com domain. The second link provides a 500 error but no further details.
View MySQL Slow Query Logs:
Next I looked into the details of the MySQL Slow Query logs to see if I could locate the problem there however nothing related to this issue displayed in those logs.
Modify Pretty Link URL Settings:
After this I modified a single Pretty Link URL’s settings to see if I could get one of the Pretty Link’s working and sure enough after some messing around I was able to get one of the Pretty Link URL’s working by disabling the Pretty Link Tracking as shown in the below image.
I still wasn’t quite sure what the issue was though I knew at this point that I could at least get the Pretty Link’s working even in the worst case scenario.
Investigate Server PHP Errors Log:
Next I decided to look at the phperrors.log file to see if any PHP errors popped out. Sure enough there were memory errors related to PHP as shown in the below output from the phperrors.log file.
- [25-Oct-2010 19:31:10] PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 524288 bytes) in /var/www/somesite/wp-includes/wp-db.php on line 884
- [25-Oct-2010 19:31:36] PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 524288 bytes) in /var/www/somesite/wp-includes/wp-db.php on line 884
As seen above PHP was running out of memory during the Pretty Link redirect process. To resolve this issue you can simply raise the maximum allowed memory in php.ini as shown in the below example.
Modify memory_limit In /etc/php.ini:
- memory_limit = 64M ; Maximum amount of memory a script may consume
The previous memory_limit setting was 32M for this server so I modified it to allow 64M instead. After restarting Apache the Pretty Link redirects worked without issue. The php.ini file is typically located in the /etc/ directory however use locate to verify that is the only php.ini file on your server. Make sure to backup your php.ini file before making any changes.
In the end the problem was not technically with Pretty Link at all however this is what brought the issue to my attention.