Plugin Error Code 500 During Update

While I was updating a WordPress plugin locally, something happened on my local server to trigger a 500 error code as the plugin was updating. On the frontend, I refreshed the page and was greeted with “Briefly Unavailable for Scheduled Maintenance. Check back in a minute”

This message is typical during the one or two seconds it takes to update a plugin or a theme, but this was taking a while. After refreshing my admin screen, I received the same scheduled maintenance error. The admin dashboard was no longer accessible. The following error was in my local server log:

[ERROR] mysqld.exe: Table '.\\local\\wp_options' is marked as crashed and should be repaired.

After a quick search, I found this awesome article by Chris Jean (Thanks, Chris!) explaining how to resolve errors in database tables. I just wanted to do a quick write up just because I don’t find myself in the sql shell all too often, and it’s mostly for my own notes. In my scenario, I was running LocalWP, so the database was named local and the user/pass is root which is fine for local development, not for production.

To connect click the open site shell button:

Since this is a local environment with default login credentials you can open the mysql shell simply by running mysql with no params or creds.

It should be noted, at the time of writing, ZSH and Local running PHP 8 or higher, will not allow for users to open the site shell as documented in this support forum

Also, as Chris’s article covers, you can correct the issue by running it in the shell or via PHPMyAdmin, which is Adminer in LocalWP:

From there you can repair the offending table. Just make sure you know exactly what your database name is and what your prefix is. That thew me off for a second when chris calls prefix_post in his code, but that prefix depends on whatever the prefix is on your wordpress table, whatever that is. The default is typcially _wp but that isn’t always the case. Hope this helps. And I was hoping to have screenshots of WPCLI running locally, but I ran into some issues. Perhaps that’ll be in the next blog post!

I’ve done a write-up on hosting local WordPress sites before, but I definitely prefer this method over the previous one. If you’ve never tried hosting multiple sites using LocalWP, then I’d encourage you to check it out. I’ve had really bad issues with it in the past, and it may have been a combination of lack of Linux support and my incompetence, but I decided to give it another shot and this time it was an absolute homerun.

What is LocalWP?

For the uninitiated, LocalWP is a software program designed for developers to get local copies of WordPress up and running quickly and push to production with ease. Just a full disclaimer before we go any farther, I am not being paid by LocalWP, they are not sponsoring me, and this is just a reflection of my own experience and my own opinions.

Let’s Talk About Setup and Updates

This is mainly a concern for Linux users, because build-it-yourself software can definitely have its ups and downs. However, I really like how Local distributes for Linux systems. While they don’t distribute via the official Linux repositories like Ubutnu and Arch, they do offer a simple .deb that you can either drop into your default software manager or something like Gdebi. Updates are as easy as uninstalling the existing .deb ad downloading and installing the latest .deb. Gdebi handles all of this for you.

Setting Up Your First Local Dev Environment

This really couldn’t be easier. It’s a simple as clicking the “add site” button, choosing where you want to save everything, choosing your config options (PHP versions, MYSQL version, and either Apache or NGINX). The fact that all of these settings are a simple dropdown is amazing. When configuring your local dev environment with XAMPP (as far as I know) you make those decisions one time and it’s a pain to change them later.

And what’s more, these settings are independent of each other. So I can have 2 or 3 copies of a site all running different versions of PHP and one on Apache and one on NGINX. To me, that alone is worth the price of admission.

Cool Features

In addition to the fact that you can manually set up different environments with different versions of your LAMP or LNMP stack, there are other features inside LocalWP that make it a real standout.

Easy To Find Your Config Files

When you’re running multiple sites on your local machine, especially when each of them has different setups, it can be easy to lose track of all your config files. LocalWP does all of this for you. Inside each local environment install, above the root directory of your WP install, is one folder that contains all the config files for that particular environment. From that one folder, you can control your php.ini and other vital config settings that could make or break your site.

WPEngine Integration

LocalWP has built-in integration with WPEngine, so once you connect your WPEngine and LocalWP accounts, you can drop in the WPEngine API key and gain access to all of your WPEngine environments right from within LocalWP. If you don’t use WPEngine for your hosting, then this feature doesn’t matter, but for those who do host with WPEngine, this is a huge bonus as opposed to figuring out how to migrate or push changes from a LocalWP instance manually via Git or SSH or FTP or whatever.

Automatic SSL Certs

If you’re developing locally with something like XAMPP, doing SSL certs can be an absolute pain, especially if you have to set them up yourself and generate your own certifications and keys and all that. Plus modern web browsers are getting so restrictive on locally hosted content that it becomes a real chore just to get a simple lock icon in the top corner. To have LocalWP just automagically generate SSL certificates for each environment is not only a huge time saver, but depending on the project you’re working on, some features actually depend on SSL certs being in place, especially in e-commerce situations.

File Tree Diffs on Push

One of the more recent updates is a feature called “Magic Sync” that automatically compares the files in your local file tree with the files in the remote environment that you’re pushing to. This is especially convenient especially if you’re concerned about overwriting important files. Great to have this “look before you leap” feature.

Final Thoughts

All in all, LocalWP has been an excellent upgrade over something like XAMPP, especially if you need to adhere to specific PHP versions and keep multiple sites locally as you work on several projects at once. All of the VirtualHosts and stuff that’s set up inside Apache config becomes a thing of the past as local sites can literally be up in running with 60 seconds with about 5 clicks. I really don’t know how I’d work without LocalWP; it’s become a vital part of my everyday workflow.

Page Template (Best for Single Pages)

If you only need to call a different sidebar on a single page and that page is totally unique, and there’s no need to have a plan for children of those pages, then a simple page template should do the trick. Just go to your parent theme, copy page.php (for classic themes) or page.html (for block themes) and paste it into the root directory of your child theme. You can also create page templates WYSIWYG style with blocks, but that’s for another time.

Rename page.php to include the slug of the one page you’re looking to change. If you want example.com/awesome-page to be different, then rename page.php to be page-awesome-page.php. Open your freshly renamed file and search for the get_sidebar() function that is likely used in your page.php file and pass the name or ID of the sidebar you want into that function.

Conditional Statement (Best for Groups of Pages)

I had a situation in which I needed to manage a handful of different sidebars that all needed to be displayed on different pages, depending on what kind of page it is. For example, it it’s a page about bicycles, it needs to display the bicycle sidebar. If it’s a child page of the bicycle page, it also needs to display the bicycle sidebar. If it’s a page or child page about underwater basket weaving, it needs to display the sidebar for basket weaving. Else, just output a normal generic sidebar. This little function came in great handy to be placed in the child theme’s page.php:

<?php
if (is_page([ID OR SLUG]) || $post->post_parent == [postID] ) {
wp_nav_menu(array('menu' => 'menu_name'));
}
?>

It should also be mentioned: the wp_nav_menu() function, can kinda take just a normal menu name or ID, but if you were like me and needed to stack a few if..elseif..elseif...elseif..else statements, I ended up seeing the same menu being outputted regardless of the ID or name passed into wp_nav_menu(). That was resolved when I passed the menu name into an array, like above. The first element of the array must be 'menu', and the second element is the name of whatever your menu is.

Method 1: Firefox (not recommended)

In the Firefox address bar, type about:config. You’ll be greeted with a warning.

Click “Accept the Risk and Continue”. Next, you’ll see a search bar where you can search for specific preferences. If you made it this far, there’s a good chance you know exactly the setting you’re looking for.

Search for content.cors.disable.

No need to type true or false. To toggle the boolean value, simply click the toggle button on the far right. CORS will then be disabled for Firefox.

Method 2: Apache Settings (recommended)

On your Apache server, head over to /opt/lampp/etc/httpd.conf and locate the lines that declare the directory that you’re looking to allow CORS on. Once you find the <Directory> tags, drop inside and add the following lines:

Header set Access-Control-Allow-Origin: *
Header set Access-Control-Allow-Headers: *

At this point, you can restart your server and you should be good to go. Don’t forget to clear your cache!

Today I ran into a situation where I was getting a new user registration every half hour for the entire afternoon. I came across this solution that will block registrations by email domain.

First, it blocks registrations by email domain. This simple denial of registration does not require WordFence, as it’s just a really useful filter you can just drop into your functions.php.

add_filter( 'registration_errors', 'disable_user_registration_for_email_domain', 10, 3 );
function disable_user_registration_for_email_domain ( $errors, $sanitized_user_login, $user_email ) {
	// only if it's an email address at all 
	if ( ! is_email( $user_email ) ) {
		return $errors;
	}

	// get domain from email address
	$email_domain = substr( $user_email, strrpos( $user_email, '@' ) + 1 );
	$block_domains = [ // partial domain names allowed (doesn't need to include TLD for example)
		'spammersgalore.com',
	];

	foreach ( $block_domains as $domain_partial ) {
		if ( stripos( $email_domain, $domain_partial ) !== false ) {
			// throw registration error
			$errors->add( 'email_error', '<strong>ERROR</strong>: Registration not allowed.' );
		}
	}

	return $errors;
}

Take it one step farther by adding the IP address to WordFence’s blocked IPs list. This isn’t permanent, the default block duration is 4 hours. However, if the problem persists, you can make the block permanent within the WordFence GUI. If you get WordFence emails from your website, it will include the IP of the blocked user, so you can go back and permanently block IPs whose lockout duration may have already expired.

add_filter( 'registration_errors', 'disable_user_registration_for_email_domain', 10, 3 );
function disable_user_registration_for_email_domain ( $errors, $sanitized_user_login, $user_email ) {
	// only execute when the relevant WordFence functions can be called
	if ( ! is_callable( 'wfUtils', 'getIP' ) || ! is_callable( 'wfBlock', 'isWhitelisted' ) || ! is_callable( 'wordfence', 'lockOutIP' )) {
		return $errors;
	}

	// only if it's an email address at all 
	if ( ! is_email( $user_email ) ) {
		return $errors;
	}

	// get domain from email address
	$email_domain = substr( $user_email, strrpos( $user_email, '@' ) + 1 );
	$block_domains = [ // partial domain names allowed (doesn't need to include TLD for example)
		'baikcm.ru',
	];

	foreach ( $block_domains as $domain_partial ) {
		if ( stripos( $email_domain, $domain_partial ) !== false ) {
			$IP = \wfUtils::getIP();
			if ( \wfBlock::isWhitelisted( $IP ) ) {
				return $errors; // don't block whitelisted IPs
			}
			// lockout IP
			\wordfence::lockOutIP( $IP, "Registration attempt from blocked email domain {$domain_partial}" );
			// throw registration error
			$errors->add( 'email_error', '<strong>ERROR</strong>: Registration not allowed.' );
		}
	}

	return $errors;
}

If, by the time you find this, you’ve got tons of bot registrations that you need to get rid of, check out this article on how to search and replace using PHPmyadmin.

Thanks for reading and hopefully this will help someone to block registrations by email domain in the future!

Select Your Database

To search and replace using phpmyadmin, first you’ll need to select and open the database you want to run the search and replace query on. Once you’ve selected it, you’ll see the tabs across the top of the screen change.

Execute Query

Click on the SQL tab at the top, and you’ll be greeted by a large textbox. This is where you can run your SQL queries like such:

 UPDATE `table_name`
 SET `field_name` = replace(same_field_name, 'unwanted_text', 'wanted_text')

Keep In Mind When Using Search and Replace

You can only target one table at a time when running queries like this. It’s a good thing and a bad thing. Good because it prevents huge data loss across multiple tables with one wrong SQL query (there is no undo). Bad because it makes it kinda difficult to make large scale changes with a few keystrokes. Depends on your situation and what you’re trying to accomplish.

My Use Case

I was recently transitioning a WordPress site away from Divi and moving into a custom Gutenberg block theme. When I made the transition, there was lots of code embedded in all my posts that was left over from the Divi builder.

Various shortcodes left over indicated what kind of Divi module it used to be, what the layout was, what version of the builder I was using at the time, etc.

So rather than go in and manually clean up well over a hundred posts, I thought it was better to just run a search and replace query against the database to get rid of that extra code, making the transition a lot easier, and WordPress would have better luck converting existing posts over to Gutenberg blocks.

Using Search and Replace to Delete Stuff

With regard to the query outlined above, you can modify it to replace your target string with an empty one, which basically deletes it.

 UPDATE `table_name`
 SET `field_name` = replace(same_field_name, 'unwanted_text', '')

Using Search and Replace Across Multiple Tables

Since you’re not allowed to do this with a single SQL query, the best way to do something like this is to dump the database and run a search and replace using your text editor of choice locally. Once completed, then you can just import that database into phpmyadmin, overwriting your existing database. (best to do all this locally before trying anything live)

position: sticky vs position: fixed

In CSS, you can use both position: sticky and position: fixed to make any WordPress block sticky, but there are some important differences that should be noted.

position: sticky keeps that element within the document flow. Great for things like columns and sidebars that have content above them. When the user scrolls to a certain position, the element will become sticky or return to the normal document flow, based on user input.

position: fixed removes the element from the normal document flow, FIXING it to a specific position (top, bottom, left right). It’s position remains fixed, regardless of user input.

For more info on how position works, check out this MDN article on CSS Position.

Target Your Element

Making elements sticky has a variety of useful applications such as sidebars, and calls to action, but in my case I want to make the main header element of my page (a navigation menu) stick to the top of the page as the user scrolls.

Since the main navigation menu will remain at the top of the page at all times, I’m going to use position: sticky because I want it to remain in the normal document flow. If I were to use position: fixed, yes, the menu would stick to the top of the page, but the rest of my webpage will float up underneath my menu, and you won’t be able to see it.

If you’re targeting a specific block, you may want to give it a class or ID and target that way, but in my case, I’m fine just grabbing the entire <header> element:

header {
	position: sticky;
	top: 0;
	width: 100%;
	margin: 0 auto;
}

Possible Reasons position: sticky Isn’t Working:

1.) Check if a threshold has been specified

position: sticky requires a threshold to be specified. Make sure that you’ve set something other than auto for any of the following properties:

• top
• right
• bottom
• left

2.) Check your vendor prefixes

If you’re on Safari, you may need to add a webkit prefix to your position: sticky call:

.sticky {
    position: -webkit-sticky;
    position: sticky;
    top: 0;
}

3.) Check for overflow rules

If you have the overflow property set on any parent or ancestor of the sticky element, the position: sticky rule won’t work.

However, if you specify a height on the overflowing container, then sticky will work.

As a web developer, it’s always a good idea to have a good working local environment for testing. Let’s dive into how to host multiple local sites using XAMPP and VirtualHosts.

XAMPP Install

You can download and instlal XAMPP over at https://www.apachefriends.org/download.html. XAMPP includes Apache and all the necessary setup to get your environment off the ground.

Using Virtual Hosts to Set Up Multiple Installs

If you’re only hosting one local site at a time, just doing a simple file protocol should be just fine to do your development. But once you have a need to work on more than one site at a time (locally), then you’ll need to set up a virtual host to separate your site installs.

Why Virtualhosts?

This is born out of the fact that your Apache install can only host a single directory (usually like /srv/www/, /var/www/, or with XAMPP, it’s typically something like /opt/lampp/htdocs/). Because of this, your site install is going to be localhost/wordpress/ in the browser.

This starts to become a problem when you install a new site at /opt/lampp/htdocs/newsite/ and wordpress has to be at the root of its hosted folder. The minute you try to make subfolders, it messes with all your links and suddenly you start getting repeated parts of your links and they end up breaking the site.

The solution? Virtualhosts. Basically special domains that are specifically defined to work on your local machine, to help you manage all your locally hosted sites.

Associate Local IP Address with Apache-Hosted Subfolders

Hop into a terminal and open the file /opt/lampp/etc/extra/httpd-vhosts.conf.

Inside that file, around line 23, you’ll see some commented-out examples of how to set up Virtualhosts. Following that example, type out your own Virtualhosts configuration below the example:

<VirtualHost 127.0.0.[0-99]:80> 
    DocumentRoot "/opt/lampp/htdocs/somesite"
    DirectoryIndex index.php

    <Directory "/opt/lampp/htdocs/somesite">
      Options All
      AllowOverride All
      Require all granted
    </Directory>
</VirtualHost>

Define Site Directory

Next, around line 217 of /opt/lampp/etc/httpd.conf you’ll need to define your site directory

<Directory /opt/lamp/htdocs/somesite>
    Options Indexes FollowSymLinks
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

Define Local Domain Name

This is the fun part! Make up whatever name you want (preferably something memorable that also makes sense) and assign it to the same IP address you defined earlier in httpd-vhosts.conf

So inside your /etc/hosts file, define your local domain like so:

127.0.0.1       localhost
127.0.0.2       somesite.local

Test It Out

If all went well, you should be able to open your browser, and somesite.local will point to the IP address you defined in /etc/hosts, and that IP would be configured to use a Virtualhost by /opt/lampp/etc/extra/httpd-vhosts.conf and that Virtualhost would be pointing to a local directory defined by /opt/lampp/etc/httpd.conf that contains your website files!