Cyr-To-Lat plugin, in which development we take active participation, grew recently to more than 100,000 active installs. In the last 10 months it grew by 30% (from 70,000 active installs).

New impulse to the popularity of the plugin gave such features as:

  • Increased number of transliteration languages (now it is Russian, Belorussian, Ukrainian, Bulgarian, Macedonian, Georgian, Kazakh, and Hebrew.
  • Friendly interface of transliteration tables
  • Conversion of any number of existing post, page, and term slugs in background processes
  • WP-CLI support
  • Reliable code, with 100% test coverage

In the nearest plans – support of Serbian, Turkmen, and Chinese languages, official WPML compatibility status, performance improvement.

The new version 2.2 of the WOOF by Category plugin, whose number of active installations exceeded one thousand, has a significant improvement in performance.

On client sites with a long list of product categories, there was a significant slowdown in the generation of WooCommerce pages with WOOF filters. The reason is that the WOOF plugin requests its options hundreds of times during page generation. These calls are handled by WOOF by Category to ensure its functionality.

On the site with 2,000 products and 70 categories option was requested 800 times during the generation of the page. The caching used in version 2.2 reduced the number of executions of the main WOOF by Category function to one, and the page generation time on the above site was reduced from 4.5 to 1.5 seconds.

When translating with WPML custom fields created by the ACF plugin, the question arises – how to make all fields translatable? Usually on the site there are quite a lot of such fields (hundreds – a typical example) and to click in the WPML settings hundreds of times – quite tedious work.

Below is an example of how to do this with the code.

The question often arises: how to count downloads and hide the real link to the file?

To solve the task we need to two things: intercept a click on the link and send the real file to the user by php.

What happens by the click on the fictitious link, pointing to an non-existent page? WordPress inits own core and tries to show 404 page. At this moment, we need to intervene by our function, update download counter, and send the real file. Here is code of such a function:

The new editor called Gutenberg is here as plugin in 4.9, and as core functionality called Block Editor, in 5.0. Regarding to it, it is often needed to determine programmatically which editor is used to edit post or page in the site console.

There are several variants:

  • WordPress 4.9, Gutenberg plugin is not active
  • WordPress 4.9, Gutenberg plugin is active
  • WordPress 5.0, Block Editor by default
  • WordPress 5.0, Classic Editor plugin is active
  • WordPress 5.0, Classic Editor plugin is active, but in site console in “Settings > Writing” the option “Use the Block editor by default…” is selected

All the mentioned variants can be processed by the following code: