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 http://yoursite.com/installer.php 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:

http://php.net/manual/en/function.session-start.php#110649

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:

https://bugs.php.net/bug.php?id=31455

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.

Monitoring slow queries in MySQL

If you are in doubt that some really slow queries are taking place on your server and they put you on too much load, then use this change in the configuration file to enable logging of slow queries:

The config files usually is /etc/mysql/my.cnf. Uncomment these:

slow-query-log = 1

slow-query-log-file = /var/log/mysql/mysql-slow.log

long_query_time = 1

log-queries-not-using-indexes

The last is not mandatory, but if you got a big db, it would be good if you have a reason to consider indexes, if you got too many queries without ’em.

You can read more here:

https://rtcamp.com/tutorials/mysql/slow-query-log/

json_no_route when querying taxonomy with WP-API

To get a taxonomy, using WP-API, you should make a request to http://example.com/wp-json/taxonomies/category/

All is well, until you have a taxonomy with a dash(‘-‘) in its name – in my case, the taxonomy is called ‘event-categories’ – the default event taxonomy in the Events Manager plugin.

So, a request to http://example.com/wp-json/taxonomies/event-categories/ responds with a “No route was found matching the URL and request method” message.

It’s a pretty big, apparently known issue, and will hopefully be resolved soon. In case it’s not though, here is a temporary solution, stolen from GitHub user zkingdesign on this page:

 

How to do animated scroll window to top or offset of particular element

Whenever you want to do animated scroll using a particular html element as a offset you can use the following jQuery code where -100 it the offset from the element in pixels.

Also if you would like to have the option for scrolling to the toп of your page use this one: