Tag Archives: WordPress

WordPress: Troubleshooting Contact Forms

Down the rabbit holeI’m trying to get a contact form working on our WordPress site, and it is a little more complicated than I thought it might be.

The contact form plugin itself in WordPress. We’re using Contact Form 7. Documentation for Contact Form 7 says something to the effect “we’re sending upteen zillion eMails a day, and CF form “just works” for everybody.  Well, kinda, sorta. There are several other issues involved:

  • an MTA (mail transfer agent) which maybe (?)  has to be on the WordPress server
  • the php_mail() function which is part of PHP (the programming language for WordPress)
  • the wp_mail() function which may or may not call the php_mail() function
  • Restrictions on to and from addresses.

I wanted to just run everything through our Google Mail SMTP account, but that seems to add an additional layer.  So first I started with our blog site which is on another server, and tested whether the contact form worked there. It actually doesn’t,  that is, it appears to send mail correctly from the users’s perspective, but no email was received anywhere.


Per this note I checked to see if anything was listening on port 25, the usual SMTP port.

$ netstat -tanpl | grep :25
tcp 0 0* LISTEN 3030/master
tcp6 0 0 ::1:25 :::* LISTEN 3030/master

$ lsof -i :25
master 3030 root 12u IPv4 9667 0t0 TCP localhost:smtp (LISTEN)
master 3030 root 13u IPv6 9668 0t0 TCP ip6-localhost:smtp (LISTEN)

Looks promising.  it appears that both IP4 and IP6 are listening.

So, I created a basic PHP script to test at the server command line, and saved this as testphpmail.php. There are three parameters, the receiver’s address, the subject and the body of the message.

//This is a test of the basic PHP eMail function.

mail('joeblow@blow.com', "Test PHP Mail", "Test mail from PHP Mail");

Run this script from the command line with the following command:

php -f testmail.php

This worked; I received the eMail. It shows that it comes from root.  At least  I knew that at least the fundamentals are in place on the server.

Checking the mail log,  at /var/log/mail.log I see the following:

$ cat/var/log/mail.log
May 20 14:28:17 li239-124 postfix/pickup[28709]: 11864F123: uid=0 from=<root>
May 20 14:28:17 li239-124 postfix/cleanup[28806]: 11864F123: message-id=<20160520142817.11864F123@localhost>
May 20 14:28:17 li239-124 postfix/qmgr[3039]: 11864F123: from=<root@localhost>, size=351, nrcpt=1 (queue active)
May 20 14:28:17 li239-124 postfix/smtp[28808]: 11864F123: to=<lkkg@myserver.org>,
relay=aspmx.l.google.com[]:25, delay=0.21, delays=0.01/0.01/0.1/0.09, 
dsn=2.0.0, status=sent (250 2.0.0 OK 1463754497 e92si18328547qga.115 - gsmtp)

So this shows that the message was sent, using root@localhost as the sender’s address and my work eMail as the target.  And indeed, I received this email at work.

I checked the log file at /var/log/mail.log which presented various points of interest…including the fact that we are running the Postfix sendmail email server.  But there is also a status=bounced message for IP6.

$ cat /var/log/mail.log 
May 20 13:50:15 li239-124 postfix/pickup[13030]: 2973DF23B: uid=33 from=<www-data>
May 20 13:50:15 li239-124 postfix/cleanup[14078]: 2973DF23B: message-id=<49922f80371c574883b8b8d699f47d9b@blog.kidsgardening.org>
May 20 13:50:15 li239-124 postfix/qmgr[3039]: 2973DF23B: from=<www-data@localhost>, size=869, nrcpt=1 (queue active)
May 20 13:50:15 li239-124 postfix/smtp[14080]: 2973DF23B: to=<lkkg@myserver.org>, relay=aspmx.l.google.com[2607:f8b0:400d:c08::1a]:25, delay=0.41, delays=0.01/0.01/0.09/0.3, dsn=5.7.1, 
status=bounced (host aspmx.l.google.com[2607:f8b0:400d:c08::1a] said: 550-5.7.1 [2600:3c03::f03c:91ff:fe6e:916c] Our system has detected that this 550-5.7.1 message does not meet IPv6 sending guidelines regarding PTR records 550-5.7.1 and authentication. 
Please review 550-5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error for more 550 5.7.1 information. a139si18154032qkc.140 - gsmtp (in reply to end of DATA command))
May 20 13:50:15 li239-124 postfix/cleanup[14078]: 8DAAAF23C: message-id=<20160520135015.8DAAAF23C@localhost>
May 20 13:50:15 li239-124 postfix/bounce[14081]: 2973DF23B: sender non-delivery notification: 8DAAAF23C
May 20 13:50:15 li239-124 postfix/qmgr[3039]: 8DAAAF23C: from=<>, size=3381, nrcpt=1 (queue active)
May 20 13:50:15 li239-124 postfix/qmgr[3039]: 2973DF23B: removed
May 20 13:50:15 li239-124 postfix/local[14082]: 8DAAAF23C: to=<www-data@localhost>, relay=local, delay=0.01, delays=0/0.01/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
May 20 13:50:15 li239-124 postfix/qmgr[3039]: 8DAAAF23C: removed
root@li239-124:~# dpkg -S 'which sendmail'
dpkg-query: no path found matching pattern *which sendmail*.
root@li239-124:~# netstat -tanpl | grep:25
grep:25: command not found
root@li239-124:~# netstat -tanpl | grep :25
tcp 0 0* LISTEN 3030/master
tcp6 0 0 ::1:25 :::* LISTEN 3030/master

Just to be sure, I ran the PHP script again having it send to my home email address which is outside my work domain.  This bounced and I didn’t receive it at the home address.  Now,  in theory, this might not be a bad thing, since all of the Contact Form 7  messages from the blog page should be sent to an address within the same domain, like customerservice@myserver.com.

So far, then we’ve established:

  • PostFix is installed on the blog’s server.
  • Contact Form 7 shows that it is sending message, but the messages are bouncing.  (Hmm…I wonder what I’ve been missing all those times? )

This is so typical of IT. You think you’re troubleshooting an issue on one server, and upon investigating the same issue on another server that you think is working…you find that it isn’t and down the rabbit hole you go!


WordPress Woes and .htaccess

After spending months working on our new WordPress site hosted at Linode, we were ready to flip the DNS from xxx.xxx.xxx.xxx to a realdomainname.org.

Not so fast!” said the SEO expert… “you need to have your 301s in place.” So, we went through the drill and identified the top 100 pages on the old site. These were pages that had been visited in the previous month or so, and also ones that we knew were especially popular. We then created an .htaccess file, which is a file containing instructions for any visitor who arrives at the new site via a search on an old URL from the old site.   Here’s a snippet of what it looks like to start.

# LK 5/2/2016 
Options +FollowSymLinks
RewriteEngine on
Redirect 301 /node/96821 http://www.realdomainname.org/toolbox/
Redirect 301 /node/120 http://www.realdomainname.org/designing/
Redirect 301 /node/2 http://www.realdomainname.org/
Redirect 301 /node/11522 http://www.realdomainname.org/basics/
Redirect 301 /node/13152 http://www.realdomainname.org/toolbox/
Redirect 301 /node/12931 http://www.realdomainname.org/activities/

So far so good. Except this is ass-backwards. We should have worked out the WordPress URLs before creating the .htaccess file because WordPress itself has something to say about the contents of the .htaccess file, viz:

# 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]

# END WordPress

These entries in the WordPress file are created based on a WordPress setting under Settings->Permalinks which allow you to change what shows as a URL for access. You can choose among a number of options including having the blog post title in the URL as well as the post’s category. (another reason for assigning a post to only one category).

One you have saved the permalinks setting, WordPress will write to your .htaccess file. If this is the first time, you will see that the .htaccess file contains lines similar to those in the # BEGIN WordPress block above.  Otherwise, my guess is that WordPress rewrites the block to accommodate how you want the permalinks to appear.

Other issues:

Note the lines

<IfModule mod_rewrite.c>
RewriteEngine On

refer to an Apache web site module called mod_rewrite. This is a piece of code in the the Apache web server which accomodates the rewriting of URLS.  So, for example, maybe you have a post that is physically located at:


A default URL for a blog post might look something like:


However, after implementing your pretty permalinks it will automatically reset itself to


or even


if you choose to include a category.in the URL formula. This “virtual” URL is the one that gets indexed by the search engines, and so is worth giving some serious thought so that you get it right the first time.

Note that this whole exercise is possible only on self-hosted WordPress sites, not on sites hosted at WordPress.com. So, at this writing, the techfornoprofits.com  site is hosted at WordPress.com, and so URLs are fixed using the formula of http://site+year+month+day+blog_post_title.


So, having gotten the permalinks thing squared away, I then added the 301 redirects to the .htaccess file.  These are in the  format of:

Redirect 301 /node/96821 http://www.realdomainname.org/toolbox/

Statement = Redirect 301
Old site page name
New site address.

The /node/96821 address for the old site page is a convention from Drupal. (Drupal is another content management system. Our new WordPress site is  a conversion from a Drupal 6.7 site).

Two notes regarding the .htaccess file:

  1. The .htaccess file is normally a hidden file, so it isn’t visible within a normal directory listing. There is a setting in FileZilla which permanently “show hidden files”  If the file name is prefixed with a period, it is considered a “hidden” file.
  2. Once the .htaccess file has been created the best practice is to turn off the ability for it to be written to by changing the file permissions. Conversely, if you either don’t see any changes or get an error message when attempting to adjust the Settings-Permalinks in WordPress….the .htaccess may either be non-existent, or flagged as read-only. WordPress has to be able to write changes to the .htaccess file.

At this point the permalinks are squared away, and the 301 redirects are in place. But our woes are just beginning!

Wordpress: Fix the File Upload Size Limit

On our WordPress site we want to allow the site manager the ability to upload PDF files which can then be downloaded by our blog viewers. While working out this process we ran into a problem with the file size; any file larger than 2 megabytes was not allowed to be uploaded to the site.

Rather than having this setting located somewhere within WordPress, it turns out that the setting is set by the PHP installation.  (PHP is the language that WordPress is written in, and WordPress the application is written as a series of PHP files).

As I was working through this issue, the first embarrassment was that I couldn’t even find the WordPress installation on my Linux server. Usually WordPress is supposed to be installed somewhere relatively transparent, like the /var/html/wordpress folder. Instead mine was buried under  /srv/www/li999-999.members.linode.com/public_html; somehow related to my virtual host from Linode

As my plumber says, when looking at the latest plumbing problem in our basement, “I wonder why they did that?”  Whatever. The way I finally found this out was to search for the one file that is in every WordPress site; wp-config.php.  I did this by firing up the FileZilla FTP program, and doing a search for remote files.


Having found the root directory of my WP installation,  I now needed to find the location of the PHP configuration file. I used a similar search in FileZilla and came up with two php.ini files.  Which was the “real” one?

Actually, I didn’t need to do that. Instead, I needed to get to have a script that calls the phpinfo() function which displays a nice list of all the php configuration parameters. Placed in the root directory of my web server, and then called from a web browser, this script displays all of the inner workings of the php configuration of my site.  Here’s the script:

// Show all information, defaults to INFO_ALL


This script is saved as GetPHPInfo.php and copied back to the root directory of the web server.


Call this script in the web browser and it produces  the following:


The above is just the tip of the iceberg. Scrolling waaaay down, I find the following parameter in the “core” section of the page:


That is the size restriction, and it is this parameter that I need to change.  I’m thinking that 12 megs should be plenty.  Looking back up top in the 6th line, I see the “Loaded Configuration File” is located at:  /etc/php5/apache2/php.ini  This is the file I’m going to change. So, its back to FileZilla to find it, download it and edit it in Notepad++


I downloaded the wp-config.php file to my local machine using FileZilla.  Then I edited the file using Notepad++. to change the  2M to 12M.  Then I uploaded the file via FileZilla back to the web server.

At this point I needed to reboot the web server, Apache2. Depending on the your installation, there are a couple ways to do this at the command line:

$ sudo /etc/init.d/apache2 restart

Or,  in the case of the lazy systems administrator, I just rebooted the whole server. This takes less than two minutes.

The result is now we can upload files that are a maximum of 12 megabytes in size.

I get to do this on another WordPress server too.  Oh joy!

SEO, Oh No!


I’m always amazed at stupid I was yesterday*. We’re creating our brand spanking new web site for our non-profit, and my attitude to SEO (or Search Engine Optimization) was….”we’ll since we haven’t put up the web site we don’t have any statistics, and since we don’t have any statistics, there is no point in doing SEO until the site is up.”


In fact, I should have done this with my own blog site as well,  recently switched from Blogger to WordPress. So that is two strikes.

It began innocently enough… literally with a water-cooler conversation with an SEO expert, who made the following points:

  1. Run Google Analytics on your old site. Identify the top pages that are always accessed. These are the pages that you want to transfer to your new site; as intact as possible, even to using the same folder structure as the old site.
  2. Can’t run Google Analytics on the old site?  Its probably because GA was set up with a personal Google account from someone long gone from your organization. So, next time…do the organization a favor and use a generic account,  like webmaster@myorgname.org so that someone else can access Analytics if you get hit by a bus. And there should be a next time….like right now.
  3. Even if you are unable to see statistics from Google, you can run an Alexa search which searches links in and out of your site. Lots better than nothing. Or if the old site is a Blogger or WordPress site, you can get statistics from those hosts.
  4. Assuming that you can identify popular pages, you want to flag the pages on the old site with a redirect from the old page to the new page. If correctly redirected, the page rank and statistics from the old site will be transferred to the new site. Do this for enough pages and you’ll preserve the old site page rank going forward.

Notes: * from Alan Weiss,  ” I’ve been fond of stating the following truth for years: I’m constantly surprised at how stupid I was two weeks ago.”

10 Ideas for New WordPress Users

Our team implementing a WordPress site, and as experienced web-site developers, but as newish WordPress users, we’re starting to develop a list of best practices that we either should have done earlier or are actually doing.

  1. Know the difference between WordPress.com, the online free WordPress hosting service, WordPress.org, the site hosted by the producers of WordPress, and your own independently hosted WordPress site.
  2. Much of the flexibility in modifying themes and the availability of themes require an independent WordPress site. Third-party plugins are not available on a WordPress.com site.
  3. With a WordPress.com site, your site will be named as a subdomain of WordPress.com.For an additional charge, you can have your own domain name point to your WordPress.com site. As an example, I created a site called powershellnotebook.wordpress.com.  I then purchased the domain name powershellnotebook.com and pointed it to the WordPress.com blog.
  4. Once you have chosen a theme, be sure to create a child theme based on that theme, and then make all modifications in the child theme. The reason for this is that when the main theme is updated by the developer and then updated on your site, the main theme is overwritten and reinstalled. Your child theme will inherit the updates, but your own modifications and changes will remain untouched.
  5. Know the difference between themes, layouts,  widgets and plugins.
  6. Within a post,  some layouts have “formats”.  These are page styles, unique to each post,  i.e.  a post can have only one format. Formats include “aside”, “quote”, “status”  and a few others. Formats are a WordPress thing, a theme can choose to support formats or not.
  7. Use categories to group posts for navigation and searching. Best practice is to assign one category for a post. If your site has three different main types of information, then you might make three categories, and assign one of these to each post. For example, for a bike touring site, you might have categories like “routes”, “gear”, “stories”.
  8. You can also have sub-categories, especially if you have a more complex site.  For our bike site, we might split up “routes” by region; “north-east”, “north-west”, “south”, “central” and under the category of gear, we might include “bikes”, “luggage” and “camping”.  If you assign a sub-category to a post, then it will automatically appear under the main category when the user searches by category. Best practice is to assign only the subcategory the post.
  9. Tags are another way to classify a post, and a post can (and maybe should) have multiple tags assigned to it. Since a tag is similar to a category, (they are both just a snippet of text which describes the content of a post), a tag shouldn’t duplicate the category, You can also use popular tags which will enhance the ability of your post to be found in Google searches.
  10. There is a lot of support for WordPress in the community. WPBeginner and Smashing Magazine are two places to start.