Been having Hostnet.nl MainWP Issues lately. The MainWP Dashboard cannot connect to the child theme. Never been happy with hostnet really as they throttle RAM all the time. This causes issues doing BackupBuddy backups and even issues with Wordfence.
MainWP – Hostnet Connection Severed
But now for two months I have not been able to connect the dashboard to the child theme. I tried:
deactivating and activating the MainWP Child theme,
reconnecting multiple times, no joy
I keep on getting
ERROR: HTTP error - Connection timed out after 10001 milliseconds
errors. Funnily the error nor access logs in the hostnet.nl control panel showed me little:
[Wed Feb 21 03:50:08 2018] [error] [client 188.8.131.52] cgid daemon is gone; is Apache terminating?: /usr/bin/php-cgi
[Wed Feb 21 05:20:37 2018] [error] [client 184.108.40.206] ap_pass_brigade failed with error 103: Software caused connection abort
The app_pass_bridge can be fixed by raising the PHP_FCGI_MAX_REQUESTS limit or limiting the FcgidMaxRequestsPerProcess to 500 – SO url. And frankly I am not sure if that is related to MainWP knocking on the server’s door.
Then we checked the SSL error logs and found:
[Wed Feb 21 17:33:15 2018] [error] [client 220.127.116.11] ap_pass_brigade failed with error 103: Software caused connection abort, referer: https://domain.nl/en/author/author/
[Wed Feb 21 17:33:17 2018] [error] [client 18.104.22.168] ap_pass_brigade failed with error 103: Software caused connection abort, referer: https://domain.nl/en/author/domain/
[Wed Feb 21 17:33:18 2018] [error] [client 22.214.171.124] ap_pass_brigade failed with error 103: Software caused connection abort, referer: https://domain.nl/en/author/author/
[Wed Feb 21 17:33:19 2018] [error] [client 126.96.36.199] ap_pass_brigade failed with error 103: Software caused connection abort, referer: https://domain.nl/en/author/author/
[Wed Feb 21 18:28:13 2018] [error] [client 188.8.131.52] Premature end of script headers: php-cgi, referer: https://domain.nl/kamers/
[Wed Feb 21 19:08:42 2018] [error] [client 184.108.40.206] cgid daemon is gone; is Apache terminating?: /usr/bin/php-cgi
[Wed Feb 21 22:41:30 2018] [error] [client 220.127.116.11] cgid daemon is gone; is Apache terminating?: /usr/bin/php-cgi
[Thu Feb 22 01:07:16 2018] [error] [client 18.104.22.168] ap_pass_brigade failed with error 103: Software caused connection abort, referer: https://domain.nl/wp-content/themes/cosily-child/style.css?ver=a35f4bf8ee43d6c4ef1d7ba1ab5faaa4
More errors there, but nothing again on the immediate connectivity issues, but a strong indicator on server errors as ap_pass_brigade errors popup a lot.
PHP_FCGI_MAX_REQUESTS or RAM
What I mainly read upon it is that it is either an issue I can solve by raising RAM or by increasing PHP FCGI MAX REQUESTS. I opened a ticket with Hostnet.nl on it.
Mailchimp Comment Optin is a plugin we still use for some of our clients. Fixing Outdated Constructor Errors is needed to work with it properly. The error you get will be:
( ! ) Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; MCAPI has a deprecated constructor in /srv/www/domain.com/current/web/app/plugins/mailchimp-comment-optin/lib/classes/MCAPI.class.php on line 3
This refers to an issue with a class name being the same as a function name. This is an old way to add a constructor from back in the days. To deal with that issue on line 39 change:
If you want to set up a Valet Bedrock based WordPress website and you run into this Valet Can’t connect to local MySQL server error. It will block you from generating a Bedrock WordPress website. It is however easy to remedy.
Valet Can’t connect to local MySQL server Error
The error you get will pop up this way on creating a Bedrock WordPress site:
wp valet new woo-guteberg --project=bedrockDon't go anywhere, this should only take a second...Error: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
MariaDB not running
This Valet Can’t connect to local MySQL server Error happens to us all every now and then. Either because we shut down MariaDB or because it did not start properly when we started our Mac.
You probably need to restart MariaDB:
brew services start mariadb
Afterwards you will be able to set up the site without issues:
wp valet new woo-guteberg --project=bedrockDon't go anywhere, this should only take a second...Success: woo-guteberg ready! https://woo-guteberg.dev
It is so easy with Laravel Valet. Love it very much!
The Jupiter Page Background Image Position can be a challenge with certain images. Sometimes the background image added behind your page winds up looking horribly cut off. So how can we improve the Jupiter Theme background images?
Background Color & Texture
Jupiter only allows for general background-position directions. This can be done per page using the Background Color & Texture settings’ Background position buttons.
There you can choose for 9 positions:
bottom center and
And this is a nice feature and is enough most of the time. But sometimes you simply need more control. And for that you need to add some nice CSS.
CSS Background Position
With CSS you can position the background image more fine grained with percentages or using a fixed amount of pixels. This allows you to position these images the way you want. Especially useful when you add portrait size images and need to make them fit and display well. You could make all these title background images taller to make things fit. But then at about 700px height they will take up too much space really. Visitors like images, but also need to be able to read text right away.
to the Visual Composer’s CSS for that page. This piece of CSS with your own choice of percentages for the background-position allows for you to tweak the background image position to your heart’s desire. I do hope we will be able to do this without CSS in the future with Jupiter but for now this seems to be the way to go.
We bumped into an PHP Strict standards: Declaration of A should be compatible with B issues.We had a theme made by us quite some time stop working recently. One we we were using as a demo mainly. So we decided to work things out. As many of you might bump into this I decided to jot this down.
Strict Coding Standards Warning
The warning we got was:
Declaration of THeaderContainer::OnEnableEvent($Sender, $Input) should be compatible with TControl::OnEnableEvent($Sender)
This is a strict coding standards warning. See comment searching this PHP.net page for declaration. The first argument does have two arguments, but the second does not. This could be fixed using:
with the extra argument $input added. This had to be done across like 35 files so I had to do a search and replace.
Additional Similar Declaration warning
The same had to be done with:
occurrences. This to deal with warnings like:
Warning: Declaration of THeaderContainer::OnEnableEvent($Sender, $Input) should be compatible with TControl::OnEnableEvent($Sender) in /../../../../../THeaderContainer.php on line 32
So just like with the previous warning we added the extra argument $input to make PHP in Strict Mode happy.
The main question remains though why this pops up now though. We had been running PHP 7.0 for quite some time already so been using a post PHP 5.4 version for quite some time to say the least. And we did see some errors from time to time, but now we could no longer login. What had changed is that we moved from a VPS to Dreamhost shared hosting so perhaps lack of memory spoiled the party.
Strict Mode needed?
You do of course not need to work with PHP Strict Mode and you can turn it off. This by changing php.ini, or a user.ini. or removing or adjusting mode declarations in other files. But as we had this project up and running with it since way back I decided to stick to this. And this way you do learn a lot about PHP and how to write it properly.
Just installed Digital Ocean monitoring beta on one of my Digital Ocean droplets where I have Trellis running for a WordPress client of mine. It is a new way to monitor bandwidth, memory usage and I/O. And also a way to get alerts when your droplet gets hit hard on one of those metrics.
Installation Digital Ocean Monitoring Beta
Setting it up on an existing droplet was quite straightforward. Did have to reboot once. Probably as I did an upgrade running a:
sudo unattended-upgrades -d
just before I got to setting up the monitoring with this easy curl command:
curl -sSL https://agent.digitalocean.com/install.sh | sh
NB Needs to be run as root or using sudo
That ran an ssh script downloading and installing the agent. And it started working pretty quickly afterwards. Just give it like 10-15 minutes.
I also set up a monitoring alert warning me when CPU reached 70% as well as one when memory exceeded 40%.
Here is an example of an alert policy setup screen:
And here is the list of alerts I set up for one of these droplets:
As you can see setting up an alert is really straight forward. And warnings can be emailed or sent to your Slack account. Really awesome. Though an app that sends push notifications would even be better. There is an API though. Will have to look into that some other time.
Graphs beta will start working as soon as you have set up your monitoring on your droplet. As you can see below it is still pretty empty. But that is as I just started using it. I like the layout. Easy to see things from a bird’s eye view so to speak.
Graphs will be good to check out the history when you do get an alert. This to see if there was just a spike or whether the usage has gone and your droplet may need an upgrade.
Moving on the graph of one of the monitors will show you details:
Had a client ask me the other day if the existing name of the Custom Post Type in question could be changed as the url or taxonomy. So how do you Change Custom Post type Name and Taxonomy of existing Custom Post Type? Well there are a few steps you need to take to do this without blowing up your website.
Custom Post Type Setup
As with most if not all custom post type setups you have the option to create posts under that custom post type. The name of that post and slug can be adjusted, but the name for the group it is under cannot be changed. So in our case the name module or plural modules cannot be changed in the backend. To do that you have to change things in the database and in the code to load things properly.
Backup your site’s database and theme files before you get started. You will be making theme file changes as well as do a database update. So make sure you can revert when shit hits the fence. Always better to the safe than sorry, right?
Change Custom Post Type Name in Database
To update the Custom Post Type name we would have to run the following in the database:
# Update the post_type column
`post_type` = REPLACE(`post_type`,'name_of_old_post_type','name_of_new_post_type'),
# Update the urls
`guid` = REPLACE(`guid`,'name_of_old_post_type','name_of_new_post_type')
WHERE `post_type` = 'name_of_old_post_type'
UPDATE `wp_posts` SET `post_type` = '' WHERE `post_type` = '';
without replacing the GUID might suffice as well. Then you just need to update the permalinks after that has been changed as well as the taxonomy here below. With this query you basically update the name of the custom post type without changed the GUID. It is simple and quick.
Change Taxonomy Name in Database
To update the url or taxonomy used by the Custom Post Type you will have to to do the following
UPDATE `wp_term_taxonomy` SET `taxonomy` = '' WHERE `taxonomy` = '';
If you have stored any references to this post type within wp_postmeta within serialized arrays you cannot simply do a search and replace as they replaced strings need to be of the same length or things won’t work anymore. There are scripts and plugins out there that can help with this though. Here is a Better Search and Replace plugin and there is of course wp-cli search and replace that does all this taking care of serialized data as well.
Do not forget to update the permalinks after these changes under settings > permalinks. Otherwise your existing custom post type posts won’t load anymore and neither will the taxonomy they are under. But hey, this is not hard to take care of now is it?
You’ll need to update any references to this post type in your code. So references to the old custom post type and taxonomy in template files, functions.php and so on. And this could take some time. Especially if it wasn’t you who created the theme in the first place. And that was the case in our case. In the end we postponed this big change as a new theme change was coming up. Once that is done we will get back to this possible upgrade.
We have a client with Antagonist in Holland and it has had multiple brief downtimes over the last couple of weeks. We are already no longer using Slimstat as it seemed to be rather demanding memory wise. But the downtimes still continued. “PHP Fatal error: Allowed memory size of x bytes exhausted” was the key error we found out. Here is how we dealt with it.
Allowed Memory Size Exhausted
As stated we soon saw in the logs that there was an issue with the PHP memory limit set. We got too many well known general errors like:
PHP Fatal error: Allowed memory size of x bytes exhausted
We found this specific error using WP Debug in the debug.log file:
[02-Dec-2016 03:38:22 UTC] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /home/account/domains/domain.com/public_html/wp-includes/wp-db.php on line 1832
and another one an hour later:
[02-Dec-2016 04:08:50 UTC] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /home/account/domains/domain.com/public_html/wp-includes/wp-db.php on line 1832
The file wp-db.php the error refers to is the file used to interact with the database. It is based on the ezSQL class by Justin Vincent. It contains the useful global $wpdb There is a Codex article on it as well. There on the line 1832 of wp-db.php you will find:
That does mean that during a database fetch query more memory than allowed was asked for. This is still rather vague though and does not help much. More on a better analysis option a little later.
When we checked the general error log we only found:
Fri Dec 02 00:11:18.364110 2016] [ssl:warn] [pid 689240] AH01909: www.domain.com:443:0 server certificate does NOT include an ID which matches the server name
[Fri Dec 02 04:49:58.434566 2016] [include:error] [pid 683238] [client 22.214.171.124:8886] unable to include "/403.shtml" in parsed file /opt/error_pages/403_antagonist.shtml, subrequest setup returned 403, referer: http://domain.com/?cat=44&paged=2
This error is not related to the issue though. And as the Antagonist cycles the logs rather quickly we will have to wait for more useful logs to show up.
Raising PHP Memory
So clearly we needed to raise the memory. This at least to avoid downtime. First we had to find out the amount of RAM used in DirectAdmin*. When you convert the bytes to megabytes you will see it passes 256MB:
Location to check the PHP RAM limit varies from hoster to hoster. So is the place where you can raise memory usage for PHP. Some hosters will allow you to raise PHP memory in .htaccess or a custom php.ini file, others give you full root access to change the core php.ini.
When we checked the PHP settings in DirectAdmin – where Antagonist allow you to change it – we found out the limit was set at a puny 128MB so we raised it to 512MB:
We do prefer max 256MB for most non e-commerce sites though so we will start monitoring things more to figure out why this is happening.
WordPress Memory Limit
If this did not help you probably have to add one or two lines of code to wp-config.php to tell WordPress to really use the extra RAM given (Codex Article). In our case we may add the following if need be:
define( 'WP_MEMORY_LIMIT', '512M' );
With most of our WooCommerce setups this is needed. In the case of memory allocation issues like ours we probably can just stick to change in PHP config itself.
Analysing Higher RAM Demand
To figure out what plugin or queries are the most demanding I normally use two plugins:
P3 Profiler has unfortunately not been updated in over 2 years so is no 100% very reliable. But still a great plugin that shows what your plugins and theme is using as a percentage of the whole.
The Query Monitor is more detailed as it will really show what particular queries are very demanding. Is a better option if you are the theme or plugin developer and want to improve the overall performance of your baby. For end users it is however more difficult to put to good use.
NB We are focussing here on backend stuff as the issue is related to database queries. For frontend stuff and site performance you can use tools like GMetrix, Chrome Inspector. Also See this article for more .
Causes of Higher RAM Demand
Normally a plugin like Wordfence doing security scans, a statistics plugin like Slimstat or a backup plugin like BackupBuddy are the culprit as they all demand more than the average plugin. Site scans and backups as well as dealing with site traffic statistics tend to demand a lot. Lot’s of queries being fired, lots of I/O. That does not mean that these aren’t great plugins though. Some hosters just limit you quite a bit on memory or I/O (Especially GoDaddy!). Especially shared hosters.
In our case it was Wordfence demanding a bit more of the site every now and then. That and some heavy brute force password attacks that come and go. We are limiting the failed login attempts more now and we are considering stopping the use of Wordfence though we really love it.
If you want to keep on working with these or other demanding plugins you often need to upgrade your hosting package. Dropping the use of certain plugins tends to go only so far as some you simply cannot live without. So upgrade when need be. Unless there is space for the hoster to give you more RAM and they are willing too. You should at least be able to get 256MB. Even 512MB for running WooCommerce.
If you are on shared hosting, well, that often means you will need to upgrade to a better package. That has been my and my clients’ experience. In the end a better package, especially on a VPS or managed WordPress hosting service, will be best for most of you.
If you quickly need to change the WordPress site url on a VPS or dedicated server with WP CLI installed or installable WP-CLI is your friend. It is a great command line based option dealing with url changes during site migration. There are of course great plugins to help out too, but believe me with full server access or VPS access a command line tool like wp-cli can deal with the url issues in no time!
Development to Production
If you just need to move the database from development to production as you will go live with the content you can do this. You replace the database on the production server with the one on the development box. Then you use WP-CLI and then change the urls in a jiffy. Just ssh into your production server and run the search-replace command like this:
Afterwards all will work well. All content will be loaded properly with the right urls. Images should be loaded too as long as you moved those to the server as well. I do this often for all new Trellis LEMP box setups at Digital Ocean and I can tell you it works really well. A lot better than the WordPress Importer tool from the Dashboard. Though the importer does work quite well from the command line you still need to deal with images.
Dry Run – Better Safe than Sorry
You can also do a dry run first with –dry-run added. This to see what urls will be changed and to make sure you are running the correct command. So the command will then be
Actually pretty smart to use. Especially if you are talking a lot data and or complicated url. Better safe than sorry. Will safe you restoring it all with or without backup.
Do remember it is always good to backup the database before you do this. Just in case you do not fill in the urls properly once you run things live. Sequel Pro is a great OSX database management tool for backups, changes and replacements of databases.
There is more..
You can do way more with wp-cli than just searching and replacing urls. You can set up full WordPress installations, install themes, plugins, add fields, backup setups and more. I will be sure to write some other applications again as soon as I have the time. Stay tuned!