How to require only Cyrillic input

A case from the practice:

You have an e-commerce website integrated with the local delivery company. The thing is that all the address’ fields should be filled in Cyrillic as this is the expected input. Any Latin input will break the delivery service. So you need to make sure that only Cyrillic characters are used.

Here is the example JavaScript code using a regular expression that is “protecting” the input field form non-Cyrillic input.



You can check it how it works on this jsfiddle.

What actually it does:

  • each typed character that is not included in the regex above is deleted form the input.

That’s all, but don’t forget that there should be also server side validation.

Settings API Step by Step

Creating custom settings/options page in wordpress admin panel is an easy task if you know what you’re doing. Here is a step by step tutorial on that.

 Create settings page

First of all we need to create our page. We have two choices:

– Create separate page

To create a separate settings page we will use this code

add_menu_page creates our settings page. We have given it the following parameters:

page_title – The text to be displayed in the title tags of the page when the menu is selected. We have named our settings page “REWP Settings”
menu_title -The text to be used for the menu. We have named our settings menu element “REWP Settings”

capability – The capability required for this menu to be displayed to the user. We chose to let only administrators access and change our settings by choosing manage_options capability. Other capabilities can be found here

menu_slug – The slug name to refer to this menu by (should be unique for this menu). We made our slug “re-wp-settings”

function – The function to be called to output the content for this page. We created the rewp() function which echoes some html (for now). Everything we put in it will be displayed on our settings page

The function that creates our settings page must be hooked to amin_menu.

Resources on WordPress Settings API Step by Step settings

– Create submenu page

Sometimes we need to add our settings page as a submenu to Settings, Tools etc. There is a different function that adds pages to the main menus. They all have the same syntax so will see only how to add submenu to Settings. To do this we need to use add_options_page

There are minor differences between add_menu_page and add_optons_page (add_menu_page accepts a few more parameters), but in our case the parameters are the same.

Resources on WordPress Settings API Step by Step settings

Create the options and output them on our page

Now it’s time to create our options and fill our settings page with them. We will be using a few functions which will take care of the whole process.
We will start by adding capabilities check and a form to our rewp function. The method must be post and the action – options.php.

Now the only change is a button “Save Changes”. This is because we don’t have any options yet. To create options we will use register_setting, add_settings_section and add_settings_field. To begin we create a function called rewp_options and hook it to admin_init.

Register settings, add_settings_section and add_settings_field
register_setting adds a setting to a group (the first parameter. We use it in add_settings_fields), creates a row in wp_options (second parameter) and can take a third parameter generally used for data validation.

add_settings_section takes id, title, callback (which may be used for description, instructions etc), page (this parameter is used later)

add_settings_field is the option. We need to give it id, title, section and callback.

Create the callback functions

Now we can start with the options. First we create sections callback. This is optional but useful when we need to output something section specific. Here is the first section’s callback function:

After that we can create the options. We create our add_settings_field callback functions and write our inputs in it.

Remember the rewp() function. We need to add settings_fields( ‘rewp-group’ ); and do_settings_sections( ‘rewp’ ); to it and as a result our settings are displayed on the page


For security purposes we need to do a few more things. add_settings_field creates a nonce hidden field and saves us the trouble. We still need to validate and sanitize the data that goes to the database therefore we have to create a function which executes just before the settings are saved. register_setting’s third parameter is the name of such function and we can use for handling security.

We have only two input fields so we only sanitize them, but we can do more complex validations. If we want to whitelist the options of a select as the only accepted input, we could do something like this:

As a result only the whitelisted options will be accepted and saved in the database. Any other input will trigger an error.

Using the options

Finally you we can use our options. We can call your options everywhere using get_option( ‘option_name’ );

If we

we will see “there be dragons”

Featured images alt and title tags

For better WordPress onpage Seo we need to give our featured images alt and title tags. Unfortunately we can’t use out of the box tools for this (yet).

Featured images alt and title tags with custom code

Plugins that give alt and title tags to images don’t cover featured images. To optimize them you need to use  the wp_get_attachment_image_attributes filter. You can put the code bellow to your functions.php

Featured images alt and title tags with a plugin

We are working on a flexible and customizable plugin that will make this task a piece of cake. Here is a sneak preview of it’s options page.

Resources on WordPress Featured images alt and title tags Featured images alt and title tags

IE specific css using media query

Issue: Style problems only in IE

Sometimes websites look as intended on all browsers except IE. To solve this problem we need to write IE specific css.

Solution: Create IE specific css with media query

If you want to have css styles that target only IE ( works for IE10+ ), you can use a Microsoft-specific media query. It is recognized only by IE.

More about -ms-high-contrast he has 1 outbound link(s), all

Redirecting all pages from the old domain to the new one

When you switch domains for a WordPress installation, you should think of not only the how to move the site, but how to keep your content reachable by search engine hits or referrals. 301 Redirect is what is expected of you, and the easy way to do it, even if both domains are still hitting the same directory on the server is by adding the following rewrite condition and rule in .htaccess (works for sites hosted on Apache only):


jCatalog plugin review

I don’t usually do this kind of reviews, but this one deserves it. Here we go:

  • Upon download, you are getting 30 Megabytes (!!!) of 6323 (!!!) files just in the plugins/jcatalog folder. WordPress alone is 18.3 Megabytes and 1216 files.
  • The plugin checks if you are using WordPress or Joomla. So it could work for Joomla with the same code base. “Sweet”, eh?
  • After you install the plugin, you get 3 folders of the plugin in WordPress root (why?!), with overall size of 27Mb and 6463 files. Sounds like a cancer to me. These are “cache”, “tmp” and “joobi”, the latests being with tons of php files inside.
  • Getting around 160 new tables in the database does not seem like the best idea ever.
  • Plugin authors do not keep track of older versions of the plugin in the SVN repository
  • Plugin authors do not maintain the change log, which could lead you to wondering if you should update it at all
  • Deactivating and activating the plugin again, as well as activating it on several subsites in a Multisite installation leads to loads of warnings and notices. I should report them in the support forum, but am a bit not sure if it’s worth the effort, as the authors didn’t do the effort to test these things on the first place.

If you want to have a CMS inside the CMS, something like the Alien, but in PHP, written by Joomla* developers, then I can’t recommend this plugin enough to you!

*I don’t have any prejudices neither on Joomla, nor on it’s developers. It’s just the standard of development that is different. If you are not looking into your code, you should be just fine.

This review was originally posted by me on Plugin version is 1.10.8, WordPress was on 4.5.2.

How to replace your WordPress site with your newly developed one using Duplicator plugin

Staging site is the one that you’ve been developing as a redesign of the live site, that has been active till now.

  1. Install Duplicator plugin on your staging site and run a full backup generation with it. Ignore warnings on the scan step, in most cases they are related to big files, big overall size of the site or other things that are not lethal.
  2. Make a backup of your live site (either by using Duplicator, or any other mean that you are comfortable with).
  3. Create a new database from cPanel of your hosting, create a new database user, and add full privileges for that user on the database you just created.
  4. Move the contents of your live site to a hidden subfolder (e.g. oldsite) and then copy your staging site package and installer.php that you got from Duplicator in the main folder of the live site.
  5. Access your site on and follow the instructions, using the credentials of the newly created database and user when requested by the installation wizard.
  6. After finishing with installer.php, you should be done with the migration.

Bad session handling can lead to performance issues

The reason is shortly explained in the PHP documentation for session_start() function here:

Furthermore, you can read about it in the session_write_close() function reference page.

How we found this? We had slow loading of some admin pages (Plugins, All Pages) in WordPress and every time P3 Profiler was pointing to a different plugin, but never the real source of the problem. After enabling slow execution log in PHP-FPM, we found out it was exactly session-start, combined with some ajax calls.

Note: have in mind that too many session_start() calls can lead to too many cookies being generated:

This was marked as “won’t fix”, probably fixed at some of the currently used PHP versions but I’m still not aware if this is true.

White screen after updating plug-ins

What if you have a very old WP site and suddenly you decide to update everything and in the middle of everything you suddenly get a white screen.

The Great White Screen of Dead. No error messages are displayed and the console is empty as hell. The only thing you get in the web tool of your web browser is 500 Server error.

Ok, that is something. So you will need so FTP access. Then go to the wp-content and look for the debug.log file. This on records all the apache errors that your server is getting. Open it and go to the end of the file. There check with the time you have tried to access for the site and see the log from this time. Its telling you what is causing the problem. In most cases it is a problem with the new update of the plug-in, an error  due to old php version on your server or something like this.

To fix it – just go to wp-contnet/plugins/the_problemed_plugin and rename its folder or just deleted it. An that is should fix it.

Limiting access to (some) files in uploads dir

All you need to do is add a .htaccess file with the following content in your uploads dir:

If you want to limit just any file from being accessed from anyone, just use “./*” instead of the regular expression.