DEV Community: WPLake

Month in WordPress: June 2024

WPLake — Tue, 02 Jul 2024 07:04:46 +0000

A supply chain attack hits plugins, WordPress 6.5.5 and 6.6 RC 1 are released, plugin install limit tops 10M, and ACF launches its 2024 survey.

1. Supply chain attack on WordPress.org plugins

WP Team: We identified that some plugin authors were reusing passwords exposed in data breaches elsewhere. The compromised accounts were not the result of an exploit on WordPress.org. Instead, the attackers used recycled passwords to add malicious code to a few plugins on the WordPress.org Plugin Directory.

This means that some plugin authors used either weak passwords or the same passwords as for other accounts, and these passwords were leaked. Hackers used these weak passwords to brute-force the wp.org plugin author accounts.

Breakdown of the attack:

June 24th: WP Plugin Review Team notices threat

The WordPress.org Plugin Review Team was notified that a malicious actor had taken over one of the plugins. The Plugin Review Team disabled it and released a “clean” updated version.
June 24th: Wordfence Threat Intelligence finds more infected plugins

The Wordfence Threat Intelligence team conducted additional research based on the WP Plugin Review Team's message and found four more plugins infected with the same malicious code. The Wordfence team notified the WP Plugin Review Team.

In all the cases, the injected malware attempts to create a new administrative user account and then sends those details back to an attacker-controlled server. Additionally, it appears the threat actor injected malicious JavaScript into the footer of websites, adding SEO spam throughout the site.
June 28th: Attack escalation

Another bunch of four more plugins were infected, while three malicious updates were stopped by the team, including the Pods plugin with more than 100,000 active installations.
June 29th: The WordPress team takes Major preventive actions

On June 29th, plugin authors received a notification from the WP Plugins Team requiring a password reset for all plugin authors. Below you can find a full message.

Hello {username},
As a follow-up on the Andrew Wilder (NerdPress) and Chloe Chamberland (WordFence) reports that uncovered a limited number of compromised plugins, the Plugin Review team would like to provide more details about the case.
We identified that some plugin authors were reusing passwords exposed in data breaches elsewhere. The compromised accounts were not the result of an exploit on WordPress.org. Instead, the attackers used recycled passwords to add malicious code to a few plugins on the WordPress.org Plugin Directory.
First, out of an abundance of caution, additional plugin releases have been paused, and all new plugin commits temporarily need approval by the team. This way, we have the opportunity to confirm that the attackers cannot add malicious code to more plugins.
We have begun to force reset passwords for all plugin authors and some other users whose information was found by security researchers in data breaches. This will affect some users' ability to interact with WordPress.org or perform commits until their password is reset.

This action ensures that further infections are impossible, and no new infection reports have been made since. If you are an author of any plugin on WP.org, you should check your mailbox and follow the instructions for resetting your password. Additionally, it is recommended to enable 2FA authentication.

2. WordPress 6.5.5 Security Release and 6.6 RC 1 are available

WordPress 6.5.5, a security release, was made available on June 24th. It contains a series of security fixes, and it is recommended that you update your WordPress installation.

Meanwhile, the first release candidate (RC1) for WordPress 6.6 is also available, offering developers and enthusiasts a preview of the upcoming changes in the WordPress 6.6 release, which is scheduled for July 16th.

3. WordPress plugin directory raised the "Active Install" limit to 10+ Million

The WordPress Plugin Directory has increased the “Active Install” limit, allowing plugins hosted on WordPress.org to display active installation counts exceeding 10 million.

We've updated our most popular WP plugins by active installations article, so you can check which plugins have surpassed this milestone.

4. ACF launched its annual survey for 2024

One of the most popular meta field plugins, Advanced Custom Fields, has launched its second publicly available annual survey. The survey consists of around 30 questions, most of which are multiple-choice, and includes questions about:

How you’re using ACF’s fields and features
Your experiences with building WordPress sites
What improvements or additions you’d like to see in ACF

You can participate in the survey, which is open until July 31.

By publishing the results publicly (and anonymously), ACF makes this survey useful not only for themselves but for the entire WordPress community.

The survey contains not only ACF-specific questions but also general WordPress questions, helping to understand developer preferences. You can find the results of the 2023 ACF annual survey here.

5. New to the web platform in June

This month, new features have landed in stable and beta web browsers during June 2024, including:

JavaScript Set Methods: intersection, union, difference, symmetricDifference, isSubsetOf, isSupersetOf, isDisjointFrom.
Async Clipboard API
Color Interpolation in CSS Gradients
Cross-Document view transitions

6. This WordPress month in numbers

In this ongoing section, we utilize WordPress.org plugin and theme APIs to feature newly published items from this month. It's an excellent opportunity to discover new tools and improve your workflow.

168 new plugins and 111 new themes.
(Note, the list is too long, see the original interactive element).

Thank you for reading! Subscribe to our monthly newsletter to stay updated on the latest WordPress news and useful tips.

WordPress Interactivity API: Detailed Explanation

WPLake — Tue, 28 May 2024 14:54:41 +0000

The WordPress Interactivity is a relatively new API that allows the creation of declarative templates natively. It harnesses Preact and offers SSR out-of-the-box.

1. When and why did the WP Interactivity API appear?

WordPress 6.5, released in April 2024, brings a significant shift with its own front-end reactivity system. In recent years, decoupled (headless) WordPress installations have become more popular. They allow you to leverage modern front-end frameworks like React or Vue.

However, this approach is time-consuming and has a clear drawback: you lose the WP ecosystem features on the front end, such as plugins. Tools like Yoast must be forgotten and switched to manual implementation.

WordPress 6.5 introduces a game-changing feature by adding reactivity tools to its core, allowing you to master modern front-end natively without turning to the decoupled approach. This feature has been developed by the WP Core team for a while but was delivered only in April 2024. Therefore, many developers aren’t familiar with it yet.

While there is a section in the official documentation that explains the key aspects of the Interactivity API, it isn’t as comprehensive as you might want. In addition, in some places it mentions parts related to the Gutenberg blocks only (though it can be used fully independently), so if you’re new to both, it might make understanding more difficult.

That’s why we made this comprehensive and in-depth explanation, in which we’ll share our knowledge with you.

2. WordPress Interactivity API definition

Now let’s figure out what exactly is behind the WordPress Interactivity API name.

The Interactivity API is a standard system of directives, based on declarative code, for adding front-end interactivity to blocks.

In other words, it’s a way to create the front end of a WP website using a declarative approach. If the official definition seems unclear to you, don’t worry, we’ll tackle it piece by piece.

Declarative VS Imperative approach

Declarative, um, what’s that? If you aren’t familiar with React or Vue, this word might be totally unfamiliar to you. But since the WordPress Interactivity API is based on it, we need to understand it. There are two different approaches to mastering the front end: imperative and declarative.

Since the early web days and for decades, we all have been using the imperative approach. The imperative way is when we have a static initial markup and then add interactivity by manually making changes to the markup using JS code. So, we manually query the right nodes and make changes for every action.

The declarative approach is a modern alternative that suggests building a dynamic layout by declaring the elements and their behavior rules all at once. When a user interacts with it, the layout is updated automatically according to the behavior rules we specified, so we don’t need to manually query nodes and make changes.

Drawbacks of the Imperative approach

As an example, let’s review an advanced accordion, which shows its state above. While you’re rarely going to meet similar accordions in real life, the idea is to showcase the weak sides of the imperative way when it comes to handling multiple states.

Besides the classic items toggle feature, we simply need to display the current accordion state (opened or closed) with the item name (so opened item name and last closed item name). The markup can be:

<div class="accordion">
  <div class='accordion__panel'>
    <div class='accordion__heading-opened' hidden>
      Current open item is <span class='accordion__open-item-name'></span>
    </div>
    <div class='accordion__heading-closed'>
      Items are closed.
      <p class='accordion__closed-item' hidden>
        Last opened item is <span class='accordion__closed-item-name'></span>
      </p>
    </div>
  </div>

  <div class='accordion__item'>
    <p class='accordion__item-title'>Title</p>
    <div class='accordion__item-content'>Content</div>
  </div>

  <!--other items-->
</div>

For hiding elements, we’ll use the “hidden” HTML attribute, and for the initial state, we hide the ‘__heading-open’ and ‘__closed-item’ elements. So, what would a classic JS implementation look like? Something like this:

document.addEventListener('DOMContentLoaded', () => {
    document.body.querySelectorAll('.accordion__item-title').forEach((title) => {
        title.addEventListener('click', () => {
            let item = title.closest('.accordion__item');
            let isToOpen = !item.classList.contains('accordion__item--open');
            let accordion = item.closest('.accordion');
            let prevItem = accordion.querySelector('.accordion__item--open');

            // Handle closing the previous item
            if (prevItem) {
                prevItem.classList.remove('accordion__item--open');
                accordion.querySelector('.accordion__closed-item').removeAttribute('hidden');
                accordion.querySelector('.accordion__closed-item-name').innerText = prevItem.querySelector('.accordion__item-title').innerText;
            }

            // Toggle the current item
            if (isToOpen) {
                accordion.querySelector('.accordion__heading-closed').setAttribute('hidden', true);
                accordion.querySelector('.accordion__heading-opened').removeAttribute('hidden');
                item.classList.add('accordion__item--open');
                accordion.querySelector('.accordion__open-item-name').innerText = title.innerText;
            } else {
                accordion.querySelector('.accordion__heading-opened').setAttribute('hidden', true);
                accordion.querySelector('.accordion__heading-closed').removeAttribute('hidden');
                item.classList.remove('accordion__item--open');
                accordion.querySelector('.accordion__closed-item-name').innerText = title.innerText;
            }
        });
    });
});

As you see, the task that looked straightforward and sounded quite simple when described in text turned into a series of conditional checks and DOM queries.

If you’re an experienced developer, you know how the JS code looks for real complex logic scenarios in real life. With the imperative approach, we must write an update query chain for every possible action manually.

The more actions we support, the more complex the code becomes. Gaining experience, you indeed can find shorter and better solutions, but you can’t write less than the necessary minimum, which is still tough.

Benefits of the Declarative approach

As we saw above, the main drawback of the imperative approach is the necessity of manually handling conditionals and queries. The declarative approach offers a solution by declaring the elements and their behavior rules all at once.

Let’s consider this with an advanced accordion example, without getting into the implementation details for now. Starting from the top, we have the panel with two different headings: “__heading-open” and “__heading-closed”.

Only one of them should be shown at a time. So, we conclude that we need an isOpen state and bind this state to the visibility of the items. When isOpen is true, “__heading-open” is visible while “__heading-closed” is hidden, and vice versa.

Introducing this state and moving conditional checks to the markup would allow us to simplify the JS code and change the UI as simply as changing the boolean value of our state. Let’s see how it should look in pseudo-code:

<div class='accordion__heading-opened' {if !isOpen then add 'hidden' attribute}>
  Current open item is <span class='accordion__open-item-name'></span>
</div>
<div class='accordion__heading-closed' {if isOpen then add 'hidden' attribute}>
  Items are closed.
  <p class='accordion__closed-item' hidden>
    Last opened item is <span class='accordion__closed-item-name'></span>
  </p>
</div>

Then in JS, we can just do:

isOpen = true || isOpen = false;

and the layout will change its state without manual node queries.

We hope that now you get the idea of the declarative approach. Don’t worry about the implementation details or other accordion elements, as the example above is only for demonstrating the idea. Below in the article, we’ll implement the advanced accordion example completely using the WP Interactivity API.

For now, you should know that nowadays there are multiple JS frameworks based on the declarative approach, including React, Vue, Preact, and others. The WordPress Interactivity API is another way to achieve this, built on top of the Preact framework.

Interactivity VS Reactivity

If you’re familiar with React or Vue, you know that both frameworks use the term reactivity.

For example, Vue’s documentation states: “One of Vue’s most distinctive features is the unobtrusive reactivity system. Component state consists of reactive JavaScript objects. When you modify them, the view updates.

This term is widely used and describes a key characteristic of the declarative approach, allowing the layout to change as soon as the variables used in it change.

What about interactivity? Let’s review its definition again:

The Interactivity API is a standard system of directives, based on declarative code, for adding front-end interactivity to blocks.

From this description, you might think that reactivity and interactivity are very similar, or even the same.

In fact, Interactivity is just the name that WordPress has chosen for this API. The Interactivity API’s front end is built on top of Preact, which is a reactive framework. So, when you’re using the WP Interactivity API, you can say that it’s a reactive tool as well.

Additionally, keep in mind that reactivity is a feature, even if it’s a key feature of the Interactivity API. Besides it, the API includes more, such as Server Side Rendering, which has its own implementation.

We’ll delve into SSR later, but for now, you should know that the Interactivity API encompasses all the features related to it, while reactivity is an important part of it.

3. Key aspects of the WP Interactivity API

The WordPress Interactivity API consists of two main features: directives and store , which are used in blocks. The store is a common term that describes state and context storages.

Let’s figure out the new terms:

Block — it’s an independent page element with its own store and template that contains directives . One block can include other blocks as children and can also “talk” to each other.

Storage — it’s a set of variables based on which we write directives and add any logic. It’s the way to ‘expose’ some variable to the declarative template.

Directive — it’s a declaration rule added to the markup that controls an element’s behavior based on the element’s state. In pseudocode, it looks like this: {if isOpen then add ‘hidden’ attribute} .

While state and context have differences that we’ll review below, both of them act as a scope of variables for specific elements.

If you’re familiar with React or Vue, you’ll likely understand the concepts more easily. However, the WP Interactivity API has its own implementation, and you can’t directly use things from the React world as is.

If you are encountering this for the first time, don’t worry if you haven’t grasped all the terms yet. In this chapter, we’ll review each in detail and apply them to the accordion example mentioned above.

Usage note

Keep in mind that though the WP Interactivity API is built into the WP core, it isn’t applied to all the HTML by default. By default, it works only within your custom Gutenberg blocks that have the related option enabled. It’s also supported by the Advanced Views Framework.

We recommend reading this chapter without practical reproducing. After getting familiar with the key concepts, you can try implementing them on your own. The ‘Where you can use’ chapter below will share when and how you can harness it.

3.1) Block

Let’s start with this basic term.

A block is an independent page element with its own store and template that contains directives . One block can include other blocks as children and can also “talk” to each other.

We can turn any HTML tag into a block as simply as adding a data attribute. So, in our case, the top accordion element is going to be a block.

<div class="accordion" data-wp-interactive="my-accordion">
  <!-- inner HTML elements here -->
</div>

The data-wp-interactive attribute is necessary to ‘mark’ a specific element as a block. Everything inside it will be considered as block parts. As mentioned above, we can have a block within a block, so:

<div class="accordion" data-wp-interactive="my-accordion">
  <!-- inner HTML elements here -->
  <div class='popup' data-wp-interactive="my-popup"></div>
</div>

This is a valid example. As the attribute value, we can pass any string, but it must be unique within the page. We recommend always giving clear and human-readable names because to ‘talk’ with some block on the page from another block, we’ll use exactly the name defined in this attribute.

3.2) State

So, we’ve defined an interactive block. But before we use any ‘magic’ directives , we need to define some data that can be used in the directives.

State is a set of variables based on which we can write directives and add any logic. It’s one of the ways to ‘expose’ some variable to the declarative template. The main characteristics of the Block state are that it is global and public, i.e., it’s saved in the page scope under the block name and available to others.

Note: State is an optional feature, so we can have an interactive block without the _ **_state** .

So, any variables defined in the state are:

Global across all the blocks with the same type (within the current page) This means that even if you have multiple blocks of the same type on the same page, they’ll all share the same state. That’s the primary difference from the context , which allows defining ‘current block-only’ variables.
Public This means other blocks can ‘request’ their values based on the variable name and use the block name as a ‘namespace’.

State variable can be passed from the backend, or defined on the front. Since WordPress is a PHP framework, the state can be passed from the backend by calling a PHP function.

If we need to define a state variable on the backend, we must call a specific function above the block definition. The function is called wp_interactivity_state. So let’s introduce the isOpen state and add it to our accordion.

<?php echo wp_interactivity_state( 'my-accordion', [
 'isOpen' => false,
] ); ?>
<div class="accordion" data-wp-interactive="my-accordion">
  <!-- inner HTML elements here -->
</div>

The wp_interactivity_state is a WordPress function that accepts two arguments: the block name, and an array of state variables.

If we have nothing to pass from the backend, we can define the state on the front end in the JS code like this:

const { state } = store("my-accordion", {
  state: {
    isOpen: false
  },
});

FYI: The ‘mixed’ way is also supported, so you can pass some state variables from the backend while defining others on the front.

3.3) Context

Context is another way to define variables that can be used in directives.

Context is a set of variables based on which we can write directives and add any logic. It’s one of the ways to ‘expose’ some variable to the declarative template. The main characteristics of the Block context are that it is local and private, i.e., it’s saved within the current block and not available to others.

Note: Context is an optional feature, so we can have an interactive block without the _ **_context** .

So, any variables defined in the context are:

Current block only This means that even if you have multiple blocks of the same type on the same page, each of them will have its own context. That’s the primary difference from the state , which allows sharing variables across block instances with the same type.
Private This means other blocks can’t ‘request’ their values directly.
Inheritable Context variables are available to the current node and all its inner elements.

Unlike state variables, which can be defined both on the back-end and front-end side, context can only be defined on the back-end. Context variables must be passed as JSON using the data-wp-context attribute. Let’s add the isOpen context variable to our accordion block:

<div class="accordion" data-wp-interactive="my-accordion" 
data-wp-context='{"isOpen": false}'>
  <!-- inner HTML elements here -->
</div>

So, that’s how it looks like in the markup. But in real life, you’ll likely want to pass PHP variables. It can be done like so:

<div class="accordion" data-wp-interactive="my-accordion" 
data-wp-context='<?php echo json_encode(["isOpen" => false]); ?>'>
  <!-- inner HTML elements here -->
</div>

You can define the data-wp-context attribute manually or call wp_interactivity_data_wp_context , a special WP function, like this:

<div class="accordion" 
data-wp-interactive="my-accordion" 
<?php echo wp_interactivity_data_wp_context(["isOpen" => false]); ?>'>
  <!-- inner HTML elements here -->
</div>

As we mentioned, the context is private and inheritable, so it’s available only for the current node and all its children. So you can have multiple contexts inside your block:

<div class="accordion" data-wp-interactive="my-accordion">
  <div data-wp-context='<?php echo json_encode(["someVar" => "some value"]); ?>'>
    <!-- inner HTML elements here -->
  </div>
  <div data-wp-context='<?php echo json_encode(["anotherVar" => true]); ?>'>
    <!-- inner HTML elements here -->
  </div>
</div>

3.4) Directives

Now, let’s review directives , the key feature of the Interactivity API, which allows us to create reactive layouts.

Directives are custom attributes added to the markup of your block to define behavior of the DOM elements.

At first glance, they appear to be plain HTML data attributes, familiar to everyone. They follow the data-wp format, appearing as data-wp-{x}=”y” , where x is the directive name, and y is the value.

To illustrate with our accordion example, let’s recall the heading part in pseudocode:

<div class='accordion__heading-opened' {if !isOpen then add 'hidden' attribute}>
  Current open item is <span class='accordion__open-item-name'></span>
</div>
<div class='accordion__heading-closed' {if isOpen then add 'hidden' attribute}>
  Items are closed.
  <p class='accordion__closed-item' hidden>
    Last opened item is <span class='accordion__closed-item-name'></span>
  </p>
</div>

Now, let’s convert it into real WP Interactive code:

<div class="accordion"
     data-wp-interactive="my-accordion"
     data-wp-context='{"isOpen": false}'>
    <div class='accordion__panel'>
        <div class='accordion__heading-opened' data-wp-bind--hidden="!context.isOpen">
            Current open item is <span class='accordion__open-item-name'></span>
        </div>
        <div class='accordion__heading-closed' data-wp-bind--hidden="context.isOpen">
            Items are closed.
        </div>
    </div>
    <!--other items-->
</div>

In this example:

We defined the ‘my-accordion’ block.
Defined isOpen variable in the block context.
Added ‘data-wp-bind — hidden’ directives to the target elements.

Directive explanation

Let’s examine the first directive: data-wp-bind — hidden=”!context.isOpen”.

For the data attribute name, we used:

data-wp- as a common prefix, necessary for any directive.
bind , which is a directive name. Bind is one of the WP directives that allows controlling attributes based on boolean variables.
— hidden , representing the name of the attribute we want to control. Here, we can place any valid HTML attribute.

Now, let’s review the value: !context.isOpen.

This is reactive code, creating a bind that persists until the page is closed. Even if you change isOpen later, after some action or timeout, it will execute our rule and keep the attribute in sync.

Why did Interactivity API choose directives instead of JSX or others?

If you’re familiar with Vue or React, you can draw an analogy with their approaches. For example, in Vue, we also use built-in directives, like v-bind:src=”srcVariable” , and in React, we use className={className}. In WordPress, we use data-wp-class — classname=”y”.

While the longer directive format may initially frustrate you, you’ll likely agree that their names are very clear. Keep in mind that WordPress is built on a classic base, and the WP Interactivity API is designed to work with any plain HTML code. Here the official documentation explains all the reasons directives were chosen.

So, even though JSX style is shorter, WP uses the classic data-attribute approach. From our experience, after creating several blocks, you’ll get used to it and won’t notice it at all. If you’re still considering that the WP Interactivity API isn’t as great as you envisioned, it has something to make you happier:

Unlike React and Vue, it offers SSR (Server-Side Rendering) out-of-the-box! This means that initially the directives will be processed on the server side by WordPress, and the browser will receive the already correct markup, with all classes and attributes set.

Also, WordPress will take care of hydration/rehydration and will sync the data and markup, so in JavaScript, you’ll be able to access and change state , context , and more.

We have taken a step away from the directives to show the power of the Interactivity API. We’ll review SSR in detail a little later. For now, let’s return to directives.

List of the available directives

The Interactivity API brings a row of directives that cover all our needs. You can find the full list on this page of the official documentation. Let’s review commonly used:

wp-bind As you saw, this directive allows you to control any HTML attribute, like data-wp-bind — hidden=”context.isOpen”.
wp-text Allows you to control the innerText of the node. Inside the value, you should pass a string variable, e.g., data-wp-text=”state.submitLabel”.
wp-class Allows you to control the class appearance based on a boolean value. E.g., data-wp-class — active=”context.isActive”. The class name can contain any valid characters, so don’t worry, things like button — enabled won’t break the directive.
wp-style Allows you to control inline styles, e.g., data-wp-style — color=”context.color”.
wp-on Allows you to assign listeners. E.g., data-wp-on — click=”actions.submit”.

3.5) JS code

Now let’s review the final piece: the JavaScript code itself, which allows us to attach listeners and add external actions, like Ajax. On the frontend, the WordPress Interactivity API is available as a separate file — a tiny library (35KB) built on top of Preact.

We import this library in the JavaScript code of any block. Not all blocks require JavaScript code, so it’s optional. If we don’t need to add listeners to our block, we don’t include JavaScript code, and consequently, the library won’t be imported.

As we mentioned earlier, the Interactivity API provides Server-Side Rendering out-of-the-box, so directives will be executed on the server side. When we need to set state variables on the frontend or define any actions, we have to add the following line to our JS code:

import { store } from '@wordpress/interactivity';

This is a classic JavaScript module import, and @wordpress/interactivity is an alias to /wp-includes/js/dist/interactivity.min.js , added by WordPress using the ImportMap feature. The following parts are available to import: store , getContext , and getElement. Let’s review all of them.

For now, let’s focus on the store , the primary one. To define the block in JavaScript, we must call the store function imported from the Interactivity library.

The first argument must be the name of our block from the data-interactive attribute, and the second is an object with the settings. Let’s add the isClosed state to our accordion block:

import { store } from '@wordpress/interactivity';

const { state } = store("my-accordion", {
  state: {
    isClosed: false,
  },
});

The object supports the following keys: state , actions , callbacks. Items defined inside the state key are used as state variables. Items inside actions are used in action directives, such as wp-on — click. Callbacks are for internal events, like init , which is called when the node is created.

Note: As we mentioned earlier, you can define a state both on the backend and frontend. This means if we’ve defined the isOpen state on the backend using the wp_interactivity_state function, we can access this property in JavaScript code too, even without defining it again.

So we can write let isOpen = state.isOpen in our JS code and it’ll return the value of the state variable that we defined on the backend, as WordPress will pass them to the front as JSON automatically. However, keep in mind that state variables defined in JavaScript will only be available on the client side.

This means if you haven’t defined a state variable on the backend but only on the frontend, you can still use this ‘front-only’ state in directives. However, such directives will be skipped during Server-Side Rendering and executed only on the frontend.

Consequently, if you use them for UI control, the client may see the element you want to hide until JavaScript is loaded and executed. Therefore, if you use state variables in directives that affect the initial UI, we recommend defining them on the backend.

getContext function

Besides state , we can also get access to the block context. For this, we need to import the getContext function from the Interactivity library. After that, we can call getContext() in any action and get any context variable as a property.

import {store, getContext} from '@wordpress/interactivity';

store("my-accordion", {
    actions: {
        toggleItem: () => {
            let context = getContext();
            context.isItemClosed = !context.isItemClosed;
        }
    }
});

Similar to store variables, the context variables are also writable, so you can change them when needed, and it will update all the directives where the context variable is used.

Note: The getContext() call will automatically get the closest context to the node on which the event is fired. This means if you’ve added data-wp-context to a block and its inner child, and then added a click listener to that child, in the action method, the getContext() call will return the context of this child.

Store variables in Actions

Let’s combine store and actions to add a click action to our accordion example to see how it all looks together:

import { store } from '@wordpress/interactivity';

const { state } = store("my-accordion", {
  state: {
    isClosed: true,
  },
  actions: {
    toggle: (event) => {
      state.isClosed = !state.isClosed;
    },
  },
});

Then we assign this listener to our accordion item using the wp-on directive:

<div class='accordion__item'>
  <p class='accordion__item-title' data-wp-on--click="actions.toggle">Title</p>
  <div class='accordion__item-content' data-wp-bind--hidden="!state.isOpen">Content</div>
</div>

That’s it! Thanks to the reactivity, when we change the state variable, it will execute directives in which that variable was used and will add or remove the hidden attribute. We can use the same variable in multiple directives.

getElement function

Using the getElement function, we can directly access the HTMLElement of the current block. In most cases, you won’t need it, but there are rare instances when it’s useful. For example, if you need to access the browser’s API to scroll the content inside or get the element’s width.

To get the HTMLElement, we need to get the ref part of the function response:

const { ref } = getElement();
// ref is an ordinary HTMLElement instance, so we can do anything with it, like:
console.log(ref.getBoundingClientRect());

Callbacks

Returning to the store object keys: state , actions , and callbacks — we have seen the first two in the action. The third key, callbacks , is used to define general block callbacks that are called by the library, such as init or run.

init is called only once when the node is created, while run is called on every node rendering. To add them to the block, besides defining them in JS, we need to set them in directives too, like this:

import {store, getElement, getContext} from '@wordpress/interactivity';

store("my-accordion", {
    callbacks: {
        init: () => {
            let {ref} = getElement();

            console.log('Accordion node is parsed', {
                HTMLElement: ref,
                isOpen: getContext().isOpen,
            });
        }
    }
});

<div class="accordion"
     data-wp-interactive="my-accordion"
     data-wp-context='{"isOpen": false}'
     data-wp-init="callbacks.init">
    <!--inner items-->
</div>

3.6) Summary

Breathe out, because at this step, we can congratulate you — the most complex parts are behind you, and you’ve learned the key aspects of the Interactivity API.

Let’s depict them all at once so you can get a complete picture in your mind.

The WordPress Interactivity API is based on plain HTML and provides directives , store , and context , which allow for declarative templates. Let’s look at a simple example:

<?php wp_interactivity_state('my-accordion', ['isClosed' => true,]) ?>
<div class="accordion"
     data-wp-interactive="my-accordion"
     data-wp-context='{"isOpen": false}'
     data-wp-init="callbacks.init">
    <div class='accordion__panel'>
        <div class='accordion__heading-opened' data-wp-bind--hidden="state.isClosed">
            Current open item is <span class='accordion__open-item-name'></span>
        </div>
        <div class='accordion__heading-closed' data-wp-bind--hidden="context.isOpen">
            Items are closed.
        </div>
    </div>
    <!--other items-->
</div>

import { store, getElement, getContext } from '@wordpress/interactivity';

const { state } = store("my-accordion", {
    callbacks: {
        init: () => {
            let { ref } = getElement();

            console.log('Accordion node is parsed', {
                HTMLElement: ref,
                isOpen: getContext().isOpen,
                isClosed: state.isClosed,
            });
        }
    }
});

So what’s happening here?

1. In the PHP backend, the templates are rendered and directives are processed

Before passing to the browser, WordPress processes the directives and updates the markup accordingly. In addition, WP converts all the state variables into JSON and passes them to the browser along with the markup.

In our case, the __heading-opened element will have the hidden attribute, according to the false value of the isOpen context variable. Meanwhile, the __heading-closed element won’t have this attribute, because isClosed state variable is true.

2. On the frontend, our JS code loads the interactivity API JS library

That library parses the JSON (in React it’s called rehydration) and calls our block definition. The WP Interactivity.js library will put the store variables defined on the backend into the state variable in our JS code ( isClosed in our case).

It will also call the init callback to which we added a listener using the wp-init directive. In this callback, we print the HTML element of the block, along with the isOpen variable from the context and the isClosed variable from the state.

From a logical point of view, it’s pointless to have both variables at once, but we included them to showcase how you can use both store and context simultaneously. That’s the way the WordPress Interactivity API works, so make sure you get the whole picture.

If something is unclear, we recommend re-read the related explanation above before continuing with the article.

4. Server Side Rendering in the Interactivity API

Note: This information is useful for understanding how the SSR works in the Interactivity API behind the scenes, but it is not necessary for the basic API usage. You can safely skip this chapter.

About the SSR overall

The main drawback of any reactive frameworks in JS is client-side rendering. While classical applications send ready HTML to the client, reactive frameworks like React or Vue create HTML on the fly, based on the defined components and their data.

In practice, this means clients will see an empty page, or at least sections, for some time until JS processes everything. This not only hurts the UX but also SEO, as search engines can’t immediately parse the page content.

Many search engines don’t support it, and while Google claims to support it, SEO experts don’t recommend using client-side rendering for pages sensitive to SEO scores. If you’re familiar with React/Vue, you know that full-stack frameworks like Next.js (React) and Nuxt.js (Vue) offer SSR.

They can ‘preload’ HTML by executing JavaScript on the server side (Node.js) and passing already prepared HTML along with the necessary states, so the client can ‘hydrate’ this data and restore its state. They seamlessly handle all the nuances, but behind the scenes, it requires quite a significant effort.

One of the difficulties here is that frameworks use Node.js on the backend and plain JavaScript on the client side in the browser. This means that the same piece of code can be executed in either of these environments, which are quite different.

SSR implementation in the WP Interactivity API

Now, back to WordPress. As we mentioned, the Interactivity.js on the front end is based on Preact, so it doesn’t offer any SSR. Fortunately, WordPress comes with its own SSR solution, and while it may sound a little crude, it’s a nice solution that supports any plain HTML.

SSR in WordPress Interactivity API is based on its own HTML API ( WP_HTML_Tag_Processor), which WordPress introduced in version 6.2.

The idea is to parse HTML pieces with the interactive directives on the backend (PHP) and modify the markup based on them, to deliver the built markup ready to the client. In addition, it includes ‘hydration’ on the client, to transfer all the states to the client side.

In this way, all state variables that we add to the blocks using the wp_interactivity_state function call in PHP, and context variables from the data-wp-context attribute, will be used during directives execution in PHP SSR.

Afterward, the state variables will be added to the current page as JSON, and then will be parsed on the client and attached to the JS block states, as we showed in the JS code explanation. In this way, the client and SEO engines get the ready HTML from the beginning, while developers can access all the data from the backend.

Though it required directive support in PHP from WordPress, it integrates well with the WP ecosystem, making developers’ lives easier and the user experience much better. If you think this is a rough solution that may be bad for performance, you shouldn’t worry about it.

It’s implemented smartly, so WordPress doesn’t parse all the page HTML, but only the pieces where the Interactivity API can be used, additionally limiting parsing to nodes with data-wp attributes. In this way, it doesn’t add significant overhead to the whole process.

5. Where you can use WordPress Interactivity API

Since we’ve learned the basics, let’s now see where we can apply this knowledge. As we mentioned earlier, the Interactivity API SSR isn’t applied to all the page content, so by default, you can’t start using it in any template. Below we provide the ways you can apply it:

5.1) In custom Gutenberg blocks (created manually)

By default, the WordPress Interactivity API is available in Gutenberg blocks. To enable its support for a specific block, you need to define “interactivity”: true in the block.json data and can use all the WP Interactivity features in render.php and view.js files.

This is good news if you’re already familiar with and experienced with the custom Gutenberg block creation process. Otherwise, we wouldn’t recommend this method, as creating custom Gutenberg blocks from scratch is time-consuming and requires React knowledge.

In most cases, you’ll need to write the markup for the same block twice: first in React for the Gutenberg editor, then in PHP for the front end.

5.2) In custom Gutenberg blocks (created using a third-party vendor)

Overall, building WordPress pages from custom Gutenberg blocks is still a good idea because they’re modular, efficient on the front end, and provide a good UX for editors. In our agency, we harness the ACF Blocks feature of the Advanced Custom Fields plugin.

This feature allows the creation of custom Gutenberg blocks without hassle. You can also use MB Blocks or Pods blocks features. Check our best custom field plugins review to compare and learn how to use them.

5.3) In templates of the Advanced Views Framework

The Advanced Views Framework introduces smart templates for the WordPress front-end, simplifying post queries and template creation. These templates harness the Twig engine and support the Interactivity APIout-of-the-box, so you can use it in any template without extra actions.

These templates can be stored inside your theme, making them Git and IDE-friendly. Additionally, you can employ TypeScript/Sass and Tailwind for them.

Another benefit is that it also supports Gutenberg block creation (via third-party vendors mentioned above), so you can turn any template into a custom Gutenberg block, providing a nice experience for editors while enjoying the modular approach and Interactivity API features.

5.4) In plain PHP templates

Though the Interactivity API may seem like a Gutenberg-oriented tool, it isn’t so by the fact. It’s a core and public API that can be used anywhere.

In your theme or plugin, you can call the wp_interactivity_process_directives function and pass a string with the HTML code that has directives. These directives will be executed, and the function will return the updated markup.

So it may look like this:

<?php

echo wp_interactivity_state('my-accordion', [
    'isOpen' => false,
]);

ob_start();
?>

<div class="accordion" data-wp-interactive="my-accordion">
  <!-- inner HTML elements here -->
</div>

<?php

$html = (string) ob_get_clean();
echo wp_interactivity_process_directives($html);


import { store, getElement, getContext } from '/wp-includes/js/dist/interactivity.min.js';

store('my-accordion', {
    actions: {
        // ...
    }
});

While it’s possible to use the Interactivity API in this manner, we recommend building websites modularly, using independent blocks with their own assets, as in the case of custom Gutenberg blocks and smart templates of the Advanced Views Framework.

6. Example of the interactive block

Now, you have all the knowledge, and we recommend you to make several examples with your own hands to practice and store the knowledge better in your head. Below, as promised, we provide an advanced accordion example mentioned above, turned into the WP Interactive block.

<?php 

wp_interactivity_state( 'my-accordion', [
 'isOpen' => false,
 'isLastItemSet' => false,
 'lastOpenedItemName' => "",
] ); ?>

<div class="accordion"
     data-wp-interactive="my-accordion">
    <div class='accordion__panel'>
        <div class='accordion__heading-opened' data-wp-bind--hidden="!state.isOpen">
            Current open item is <span class='accordion__open-item-name' data-wp-text="state.lastOpenedItemName"></span>
        </div>
        <div class='accordion__heading-closed' data-wp-bind--hidden="state.isOpen">
            Items are closed.
            <p class='accordion__closed-item' data-wp-bind--hidden="!state.isLastItemSet">
                Last opened item is <span class='accordion__closed-item-name'
                                          data-wp-text="state.lastOpenedItemName"></span>
            </p>
        </div>
    </div>

    <div class='accordion__item' data-wp-context='{"isItemClosed":true,"itemName":"First"}'>
        <p class='accordion__item-title' data-wp-on--click="actions.toggleItem" data-wp-text="context.itemName"></p>
        <div class='accordion__item-content' data-wp-bind--hidden="context.isItemClosed">Content of the first item</div>
    </div>

    <div class='accordion__item' data-wp-context='{"isItemClosed":true, "itemName":"Second"}'>
        <p class='accordion__item-title' data-wp-on--click="actions.toggleItem" data-wp-text="context.itemName"></p>
        <div class='accordion__item-content' data-wp-bind--hidden="context.isItemClosed">Content of the second item
        </div>
    </div>
</div> 

import {store, getContext} from '@wordpress/interactivity';

const {state} = store("my-accordion", {
    state: {
        openedItemTitle: null,
        get isLastItemSet() {
            return '' !== state.lastOpenedItemName;
        },
        get isOpen() {
            return null !== state.openedItemTitle;
        }
    },
    actions: {
        toggleItem: (event) => {
            let titleElement = event.target;
            let context = getContext();

            // Handle closing the previous item
            if (null !== state.openedItemTitle &&
                titleElement !== state.openedItemTitle) {
                state.openedItemTitle.click();
            }

            // Toggle the current item
            context.isItemClosed = !context.isItemClosed;

            // update the top state
            state.lastOpenedItemName = context.itemName;
            state.openedItemTitle = false === context.isItemClosed ?
                titleElement :
                null;
        }
    }
});

Getters: In this implementation, we used the built-in JS getter feature to add dynamic state variables. This feature can be added to any object in JS and is particularly useful in our case, as wp-bind boolean properties support only boolean primitives, so we couldn’t add conditions there.

So, this is a declarative implementation of the accordion block. Let’s now recall how the JS code looked in the imperative approach:

document.addEventListener('DOMContentLoaded', () => {
    document.body.querySelectorAll('.accordion__item-title').forEach((title) => {
        title.addEventListener('click', () => {
            let item = title.closest('.accordion__item');
            let isToOpen = !item.classList.contains('accordion__item--open');
            let accordion = item.closest('.accordion');
            let prevItem = accordion.querySelector('.accordion__item--open');

            // Handle closing the previous item
            if (prevItem) {
                prevItem.classList.remove('accordion__item--open');
                accordion.querySelector('.accordion__closed-item').removeAttribute('hidden');
                accordion.querySelector('.accordion__closed-item-name').innerText = prevItem.querySelector('.accordion__item-title').innerText;
            }

            // Toggle the current item
            if (isToOpen) {
                accordion.querySelector('.accordion__heading-closed').setAttribute('hidden', true);
                accordion.querySelector('.accordion__heading-opened').removeAttribute('hidden');
                item.classList.add('accordion__item--open');
                accordion.querySelector('.accordion__open-item-name').innerText = title.innerText;
            } else {
                accordion.querySelector('.accordion__heading-opened').setAttribute('hidden', true);
                accordion.querySelector('.accordion__heading-closed').removeAttribute('hidden');
                item.classList.remove('accordion__item--open');
                accordion.querySelector('.accordion__closed-item-name').innerText = title.innerText;
            }
        });
    });
});

Wow, how much shorter the event handler is now, and what a nice thing to update variables instead of querying nodes directly and updating attributes manually!

You can already see the huge benefit and shift in the approach even in this small example. Recall all your JS code from real life, and envision now how much better it’s going to be when it’s written using the Interactivity API.

Now it’s a great time to experiment! Try to change something in that to get practical experience with the WordPress Interactivity API!

Demonstration note: If you’re an exprienced web developer, you can see that our implementations are quite simple and can be improved. In real life, it would use the wp-each directive, or at least a PHP loop by the data array. But don’t judge strictly, we made it as simple as possible for demonstration purposes.

7. Pro Tips on the Interactivity API

There are several useful things you should know to harness the full potential of the API. Some of them we already briefly mentioned, and now let’s review them in detail:

7.1) Getters in State

As you saw in the declarative advanced accordion implementation above, we can define any getters in the state object. This is a very useful feature, and you’re going to use it often due to the fact that most directives support only boolean variables.

It means you can’t write conditional statements, like in plain JS code, data-wp-bind — hidden=”state.isFirst && !state.isSecond” or “state.name == ‘’”. These won’t work. So when you need such conditions, you can put them into a getter and define that getter inside the attribute.

import {store, getContext} from '@wordpress/interactivity';

const {state} = store("my-accordion", {
    state: {
        get isLastItemSet() {
            return '' !== state.lastOpenedItemName;
        },
    },
});

Inside that getter, we can also harness context variables by calling getContext(). Also, pay attention that getters defined in the JS code aren’t available on the backend, so during SSR, directives that include them will be skipped.

In these cases when you want them to participate in SSR, you can define them using the wp_interactivity_state function as primitive booleans, and then just override them in the JS by assigning a function to the same name.

7.2) Event object in Actions

When we assign our callback to some element in plain JavaScript, like .addEventListener(‘click’), this callback will receive the first argument with the Event type. The object will vary depending on the action itself, but in all cases, it implements the general Event interface.

Actions in the WP Interactivity API also receive this object, so you can use it as you need, e.g., to get the current element, like event.target :

import {store} from '@wordpress/interactivity';

store("my-accordion", {
    actions: {
        toggle: (event) => {
            let clickedHTMLElement = event.target;
            // clickedHTMLElement.innerHTML = 'x';
        }
    }
});

7.3) Loop Directive: wp-each

It’s an advanced directive, which you’ll need only in cases where the interface requires dynamic item creation and removal. An example is the classic ‘todo’ list, where besides editing, items can be added and removed.

This directive allows defining a template that will be applied to all items of the list. The idea is that when you change the related variable in JS, it’ll keep the items in sync automatically.

Let’s review this example:

<?php

$context = [
 'list' => [
  [
   "id" => "en",
   "value" => "hello"
  ],
  [
   "id" => "es",
   "value" => "hola"
  ],
  [
   "id" => "pt",
   "value" => "olá"
  ]
 ]
];

?>

<div class="accordion"
     data-wp-interactive="my-accordion"
     data-wp-context='<?php
     echo json_encode( $context ); ?>'>
    <ul>
        <template
                data-wp-each--item="context.list"
                data-wp-each-key="context.item.id">
            <li data-wp-text="context.item.value"></li>
        </template>
    </ul>
    <button data-wp-on--click="actions.removeLastItem">Remove last item</button>
</div> 

import {store, getContext} from '@wordpress/interactivity';

const {state} = store("my-accordion", {
    actions: {
        removeLastItem: (event) => {
            let context = getContext();

            context.list.pop();
        }
    }
});

In this example, we have a list of items, where each has an id and value. Using the special Template tag and data-wp-each directive, we define the loop by the list. In the directive name, we define the item name, in our case item (data-wp-each — item=), and as value, we define the list itself, which can be either a context or state variable.

Pay attention that we use the wp-each-key directive to point to the unique item ID, thanks to which the Interactivity API will keep items in sync.

This loop will be processed during SSR and replaced with the markup built based on the items. But unlike a plain PHP loop, it’ll keep the list context variable defined in the wp-each directive in sync with the markup, so when we remove the last item of the array in the action, it’ll remove the target item in the markup automatically.

7.4) Cross Block Communication

As we mentioned earlier, all the block state variables are public, so they can be accessible from other blocks. But how can we do it?

To get the state of another block, we should call the store function with the name of the target block, but without passing the second argument, as we did before.

Below we show how to get the someData state variable from the my-another-block. This code can be placed anywhere, e.g., inside any action of our accordion block.

import {store} from '@wordpress/interactivity';

// ....

console.log(store("my-another-block").state.someData);

8. Conclusions

The appearance of the WordPress Interactivity API is a significant shift in the WordPress ecosystem. Although it was released recently and hasn’t gained widespread recognition yet, it is definitely going to play a crucial role in WordPress development in the near future.

This built-in integration will help developers build interactive frontends easily. Thanks to the unified approach, plugin and theme vendors can develop their own interactive blocks, which will be able to interact with each other, regardless of the vendor.

We hope this article was useful and that you’ve understood all the key aspects of the Interactivity API. Happy developing!

Display Custom Post Types and ACF fields in WordPress — WPLake

WPLake — Wed, 07 Jun 2023 09:35:56 +0000

Display Custom Post Types and ACF fields in WordPress — WPLake

Custom Post Types lets you add more functionality to your website. It’s also helpful when you’re already using the standard post for something else.

Custom Post Types are a way of organizing your content, like jars in your kitchen.

About Custom Post Types

WordPress already has a built-in post type called ‘Post’. Which of course, is what many bloggers use to write their articles. As you may already know, this is one of the things that has made WordPress so popular. It’s a blogging tool on steroids, extending it with embedded content and so many other extras. With the birth of the Gutenberg editor, you now have something called blocks. Which has really been a game changer in so many ways.

Okay, so what are Custom Post Types, what can it do and why, would you even want to create more complexity in an already “feature rich” WordPress post. Well you’d be surprised.

Let’s dig in.

Plugins mentioned in this article;

Advanced Custom Fields (Free)
ACF Views (Free)

Reasons to use Custom Post Types

When you’ve got posts, it’s great, but what if you’re creating a business directory. Is each post then a business or an article, what if you’ve got a news section too?

Of course you could use taxonomy to define some content categories, or even tags if you’re desperate. But ultimately the “posts” will still be posts at the end of it, saved in the same database tables. And still be listed under “Posts” in the WordPress back-end.

This isn’t actually the correct way to define different types of content. If you’ve got some blog posts and they’re in different categories, like news and notices, then it isn’t such a big deal.

Example of CPT usage

You’ve decided that you’re going to just use the built-in posts and that’s that. Then consider this, what if some content needs an extra sub headline field, or still on the business directory example. What if the “company” post already uses the ‘Featured image’ for the profile cover. Now you need an extra field for the logo, but again this logo isn’t applicable for use on other content.

It therefore quickly becomes obvious, that yes you need a way to define different types of content, and with that to assign some extra fields that’s specific to that content type.

There are ways to create a Custom Post Types (CPT) using code or other plugins, but when you’re a veteran WordPress web developer or designer. Then you probably know that every single plugin you install affects your site. So always try to reduce the number of plugins, and use only well supported plugins, which is an important aspect of WordPress speed optimization.

So with that in mind, we always try to use as few plugins as possible. In this case and most other cases we usually choose Advanced Custom Fields (ACF) for creating extra fields and since ACF v 6.1 you now have the added benefit of creating CPT’s.

Behind the scenes for Custom Post Types

There is Post Meta and Custom Post Type. Each of these play a role when it comes to custom fields.

In WordPress there are certain types of data like Posts, Images, Pages and even Users that you can create yourself. All the information is stored in a single database table that’s called ‘wp_posts’.

Therefore, when we create a Post, a Page or a User or even a WooCommerce Product. The information will be stored inside the ‘wp_posts’ table.

In the screenshot you’ll see that there a few post types, attachment, pages and acf-field. Now inside each post it has the same structure, an ID, Post Author, Date, Content, Title, Excerpt and Post Type. These attributes are all necessary and required.

Database structure

So, every entry has the same exact structure, which is defined by the structure of this table. And therefore we cannot add another column and name it what we like. That just isn’t possible, and this is where Post Meta comes in. The Post Meta is saved within a separate database called ‘wp_postmeta’. See the table below.

In this table we have ‘meta_id’, ‘post_id’, a ‘meta_key’ and a ‘meta_value’. Each entry in this table has a key and a value, and we can associate this pair to any Post ID. So in these rows of data are associations to Post ID’s, and they’re considered characteristics of the Post, or Page etc.

When you need to add a characteristic to a Post or Page or another Post Type. Then you’d need to add it in the ‘wp_postmeta’ database, and not in the ‘wp_posts’ table. That’s all you need to know about Post Meta for now.

Now let’s take a look at what Custom Post Types are.

When you look at the ‘wp_posts’ table, you’ll notice that every entry has a ‘post_type’. So we can have a Post, a Page, Attachments, Company and Images etc, they’re all considered Post Types. Where the “Company” is actually a Post Type we’ve registered in our theme.

This PHP snippet below is placed within the functions.php, file inside your theme directory.

// register a custom post type "company"
<?php
function add_cpt()
{
    $args = array(
    'labels' => array(
    'name' => 'Companies',
    'singular_name' => 'Company',
    ),
    'hierarchical' => true,
    'public' => true,
    'has_archive' => true,
    'menu-icon' => 'dashicons-building',
    'show_in_rest' => true,
    'supports' => array('title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments',),
    'taxonomies' => array('category',),
    );
register_post_type('company', $args);

}

add_action('init','add_cpt');

When the Custom Post Type is registered correctly, you will find the “Companies” in the admin menu.

Watch the video below for more info.

https://www.youtube.com/watch?v=fFz6OTeoiMI

Register a Custom Post Type in ACF

If you’d like to follow along, then make sure you’ve got the ACF plugin v6.1 or later installed and active.

Continue by visiting ACF -> Post Types in your Admin Back-end, here you’ll see a screen with the basic settings for a new Custom Post Type (CPT). Fill the Plural Label, Singular Label and Post Type Key. This is also the bare minimum you’d need to create a post type.

For my example, I’ll call my Plural Label as “Companies”, Singular label as “Company”, and my post key as “company”. You should feel free to create whatever you’d like here, the steps are pretty much the same.

Let’s set some advanced configuration for your new Content Type. On the same creation screen, switch on the “Advanced Configuration” toggle to show the settings. Under the ‘Supports’ heading check for various content editor features, and tick or un-tick to enable and disable them. For my case I’ve unchecked “Editor”, as I don’t plan on using it.

Switch to the Visibility tab and in the Menu icon field, add in the Dashicons class name. This isn’t critical but I recommend having some unique icon in the back-end, and if you’re building the site for a client then it looks more professional with the small extra touches. See the ‘Permissions’ tab for and turn on “Delete With User”. As in my case if a user no longer has a profile. Then I won’t allow them to have a business listed. Lastly, click “Save changes” and that’s it. You’ve just created a new Custom Post Type.

You can read more about CPT’s in the official ACF article.

Adding ACF fields to my CPT

Alright, there you have a Custom Post Type, now what?

We need some extra fields, as you know by now, we’re not just creating CPT’s for the fun of it, we’re doing it with a purpose. As a reminder the purpose is to have custom content types, for specific use cases and to keep content organized in the back-end.

Let’s create some Advanced Custom Fields (ACF) that we’ll assign to our ‘Company’ CPT.

Head over to the ACF -> Field Groups, click “Add New” and fill in the Field Group name (mine is called ‘Details’). Add a field with the “Add Field” button, select your Field Type, in my case I’m selecting “ Image “ with the field label “Logo”, with Return Format as “Image ID”.

Each “Company” really needs a Map too, so I’ll add a Google Map field, along with the User field. The intention is for a ‘company’ to get more exposure, and so that someone can find them with the map. The User field will be for associating the ‘company’ to a profile, and then also add a URL field for the company website. Lastly, in the Settings under “Location Rules” select ‘Post Type’, ‘is equal to ‘Company’ (Note: Select your CPT, if you’ve got another).

Important note: Google Maps API should be registered or the ACF Google Map field won’t work or display.

As a base set up for a ‘Company’, I’d say this is pretty solid. Any more ideas can be added later as the site grows, so let’s not add too many fields just yet. Remember to Save changes.

ACF fields with location rules for Custom Post Type.

Display a set of Posts with PHP code

Now that we’ve got all the groundwork ready, we need to display the CPT items.

Each Post Type has a template to display the associated information of a single item, but in this article we’re going to focus on displaying multiple items with their fields in a grid.

Now, you may know it’s quite a complex thing to display Posts with code, so I won’t blame you for skipping to the next section on how to display Posts with a shortcode.

For the PHP code to work, you’ll need to follow closely, and pay close attention to the field names you’ve defined when you added your fields to your Custom Post Type.

Here’s an example of a Custom Post Type for ‘Companies’, with a filter to show posts if the “Since date” year is bigger than 2010.

<?php

$queryArgs = [
    // todo use your post type here
    'post_type' => 'company',
    'post_status' => 'publish',
    // todo maximum amount of posts, use -1 to set unlimited
    'posts_per_page' => 5,
    // todo type of order
    'order' => 'DESC',
    // todo order field
    'orderby' => 'date',
    // todo use your fields
    'meta_query' => [
        [
            'key' => 'since',
            'value' => 2010,
            'compare' => '>',
            'type' => 'numeric',
        ],
    ],
];

// SQL query will be executed during this line
$query = new WP_Query($queryArgs);

// @var WP_Posts[]
$posts = $query->get_posts();

echo "<div class='companies'>";
foreach ($posts as $post) {
    $postId = $post->ID;
    $title = get_the_title($postId);
    $description = get_the_excerpt($postId);
    $since = get_field('since', $postId);
    ?>
    <div class="companies__company company">
        <h2 class="company__title"><?php
            echo $title ?></h2>
        <div class="company__description"><?php
            echo $description ?></div>
        <div class="company__about">
            <p class="company__field-label">Since:</p>
            <p class="company__field-value">
                <?php
                echo $since ?>
            </p>
        </div>
    </div>
    <?php
}
echo "</div>";
?>

Alright, time for a summary.

When you want to display a custom set of posts you will need to a) write a query, then b) get the field data, and c) write the necessary HTML markup to display the posts. It’s all pretty flexible, and you can do great things with this method, but it also requires a lot of time and effort. And of course some PHP knowledge, so let’s rather focus on an easier way without the drawbacks.

Display a set of Posts with a shortcode

At this point you’ll need to install and activate the ACF Views plugin, because it’s really the power house of features in displaying Posts with their ACF fields without having to write the code.

Visit the ACF Views link in your admin backend, and click “Add New” to create an ACF View. We’ll use this to assign fields from our Company CPT. I’ve named my ACF View “company stub”.

Next, in the Fields section, assign the fields by selecting them from the drop down list.

Assigning the ACF fields to your ACF View.

Save your ACF View by clicking ‘Publish’.

We’re done with assigning the fields at this stage, you can edit your ACF View at any time, to add or remove fields. (Note: we’re not copying the ACF Views shortcode, we’re assigning it to our ACF Card)

Creating an ACF Card

Visit the ACF Cards and click “Add New”, name your card, in my case I’ve named it “Company list”, scroll down and assign your ACF View created earlier. This View will be used to display your Post items. Now switch to the ‘Filters’ tab and for Post Type, choose ‘Company’ or your CPT name, next, in the ‘Sort’ tab, select Title and keep “Ascending” selected for Sort order.

Click “Publish” to save and publish your ACF Card. Copy the shortcode to clipboard, we’ll paste it on our page in a minute.

Finally it’s time to create a page where you’ll display the list of posts for Company CPT.

Visit the “Pages” list and “Add New” page, call it whatever you’d like. But remember to make it clear and user friendly. I’ve kept mine simple for clarity, so just “Companies”.

If you’re using the Gutenberg editor, then add a ‘shortcode’ block, paste your ACF Card shortcode from earlier, otherwise paste your shortcode anywhere in the content. Click “Publish” or “Save draft”. We’ll come back to this page in a bit.

Fill the fields

Did we forget something?

Yes, yes we did, we have to create some ‘company’ posts, at least some dummy ‘company’ items to test if everything is working as expected.

Head over to “Companies” in the admin list and add posts, the same way you’d usually do when creating Blog posts.

When you add your first ‘Company’ post, the first thing you would notice is that it looks like a normal post edit screen, but with the extra ACF fields that were added.

Once you’ve created some ‘Company’ posts, go back to the Pages list, find your page (the page where you pasted the ACF Cards shortcode) and view it to see the results. You should have a list of posts with the fields you’ve filled displayed.

All you have to do now is add in some styles with CSS. So, go back to your ACF Views item, switch to the ‘Advanced tab” and add your styles in the CSS code field.

A set of ‘company’ custom post types displayed in a grid.

Create a list or grid of posts

To create a grid of custom post type items, like above, you could use the following CSS, replacing the tags with your field names (if needed);

/* style the cpt items, paste in ACF Views item, in CSS code field */
#view {
 width: 30%;
 border-radius: 24px;
 border: 1px solid #f4f4f4;
 padding: 20px;
 margin-bottom: 30px;
 margin-right: 20px;
}

.acf-view__logo img {
 max-height: 40px;
 position: absolute;
 margin-top: 10px;
}

.acf-view__post_title_link {
  font-size: 24px;
  padding-top: 10px;
}

.acf-view__thumbnail_id img {
 width: 100%;
}

/* show card items in one row, paste in ACF Cards item, in CSS code field */
#card__items {
 display: flex;
}

Alternatively, you could opt for a easier, more responsive route, especially if you’re still learning CSS. Visit your ACF Card item, switch to the ‘Layout’ tab.

This tab enables you to add rules, for mobile and other desktop screen sizes. Then it adds the CSS into the CSS code field in the ‘Advanced’ tab. It has options for different types of layouts, like “Row”, “Column” or “Grid”, with easy to define gap size and amount of columns for grid. In other words, you could have 3 per row for desktop, 5 in a row for larger screens, and then only 2 in a row for mobile, making sure it always looks neat and uncluttered on the screen.

Furthermore, if you’d like to show “Company” items, and there are some special behavior that you need to include, like having “Featured companies” which show at the top of the list, or ‘companies’ with different tiers, then you could filter by those field meta. Just include an extra section on your page (or Gutenberg block) and so forth, following a similar approach as below, where you filter by meta or taxonomy depending on your requirements.

Let’s see where you could add these filters.

Sort and Filter by Taxonomy or ACF field meta

When using ACF Views Pro, you get access to the Taxonomy Filters and Meta Filters, where you can add rules to filter by a taxonomy query, and also to add rules for filtering by a fields’ meta. In other words, if you have ‘company’ CPT items, and they have “Industry” categories, you could have a page to display only companies for a specific industry category.

Powerful meta filters allow you to do a bit more. Let’s take an example, you have ‘company’ CPT items and you’d like to show all items that have the same owner (User), then you could use $posts$.user rule.

Final thoughts

In this article we’ve shown you how to register new Content Post Types, and how to add extra ACF fields and finally, how to display a list or grid of posts, with their ACF fields on a page.

We hope this article is useful to you and that you’ll be creating more post grids and blocks of content with different CPT items for different purposes.

…and remember the main rule is to have fun, and to use as few plugins as possible.

Originally published at https://wplake.org on June 7, 2023.

How to use and display the ACF Google Map field

WPLake — Mon, 01 May 2023 11:32:00 +0000

How to use and display the ACF Google Map field — WPLake

Learn about the ACF Google Map field, the field’s options, and two ways to display it, one without any coding. Read about what happens behind the scenes and how information is stored.

The ACF Google Map field allows you to display… You guessed it, a Google Map.

About the Google Map field

The ACF Google Map field stores an address, that is then turned into a map on the frontend.

The Google Map field is one of many ACF field types, there are more than 35 field types already and still somehow that number is still growing.

ACF Google Map field is like an embed field, where you don’t have direct control over the content, but still have some control on how it displays and in what size visitors see the map and the all important location marker.

There are many reasons why you’d want a Google Map on your post or page. You can show the location of a business, e.g. a Business directory. Perhaps you have an online store and one of your delivery options is “Free pickup”, buyers may need an actual map to find their way.

Embed the map the old way

You could embed the map directly. As you may know, in the past and still today it was quite easy to just go to Google Maps or Visit maps.google.com, perhaps even with Google Earth it was possible, but let’s not lose focus here. Google Maps is simply one of those technological things we can’t live without, enough said.

To embed a Google Map directly, visit a location on Google Maps, select ‘share’ and then switch to ‘Embed the map’, select a size and then ‘Copy HTML’ and paste it in place.

Example of HTML embed code for Somerset West, City Center in South Africa;

<!--a map that's directly embedded-->
<iframe src="https://www.google.com/maps/embed?pb=!1m18!1m12!1m3!1d105767.5598163991!2d18.746078233330014!3d-34.063457740807046!2m3!1f0!2f0!3f0!3m2!1i1024!2i768!4f13.1!3m3!1m2!1s0x1dcdb565fbc4f737%3A0x42f889f307a16bb9!2sSomerset%20West%2C%20Cape%20Town!5e0!3m2!1sen!2sza!4v1682081617435!5m2!1sen!2sza" width="600" height="450" style="border:0;" allowfullscreen="" loading="lazy" referrerpolicy="no-referrer-when-downgrade"></iframe>

Embedding maps directly has of course many drawbacks, the main points are; it doesn’t provide any settings or UI to editors, and if you need to add a map to for example a CPT, different locations can’t be used on different pages in this way. At least not without a lot of manual work and effort.

Field settings

With the Google Map field you have some settings when creating the field. You can define latitude and longitude coordinates to center the initial map around that point, you can set the zoom level and customize the height of the Google Map.

These settings are useful and help on the post/page edit screen, it even saves time, and helps with consistency across the site post and pages, so the maps look similar and have the same height.

The Google Map field settings, define the zoom level and height.

Behind the scenes in ACF

Behind the scenes, the ACF Google Map field type allows editors to see and interact with a live map to define a marker. It uses the Google Maps JS API to provide address autocomplete searching and reverse geocoding lookup.

Information about your choice is returned as an array, and it’s saved into the meta field as a serialized value. It contains several keys, like ‘address’, ‘lat’, ‘lng’ and ‘country’, see below for an example of the meta value.

a:10:{s:7:"address";s:10:"London, UK";
s:3:"lat";d:51.5072178;s:3:"lng";d:-0.1275862;
s:4:"zoom";i:8;s:8:"place_id";s:27:"ChIJdd4hrwug2EcRmSrV3Vo6llI";
s:4:"name";s:6:"London";s:4:"city";s:6:"London";
s:5:"state";s:7:"England";
s:7:"country";s:14:"United Kingdom";
s:13:"country_short";s:2:"GB";}

Use this data as you see fit, from the most common usage, like displaying the address on the contact page, to using it in some API request as an argument.

But don’t forget the fact that ACF doesn’t provide any frontend for the map. This means that ACF includes the Maps’ API only for editors in the backend. Therefore you’d need to load Google Maps API, and initialize the map yourself for it to appear on the frontend of your site.

Doing it in this was does provide flexibility in the usage of the data, as you can display the map using an alternative vendor (like OpenStreetMap), but also usually results in more time spent on integration.

Register Google Map JS API key

To use the Google Maps JS API you’d need to register an API key. The Google Map field requires the following APIs; Maps JavaScript API, Geocoding API and Places API.

Follow Google’s API instructions to Get your API key.

Register your Google Map API on your site, using one of these methods;

Paste it in your theme’s functions.php template file, replacing ‘xxx’ with your key.

// Method 1: Filter.
function my_acf_google_map_api( $api ){
    $api['key'] = 'xxx';
    return $api;
}
add_filter('acf/fields/google_map/api', 'my_acf_google_map_api');

// Method 2: Setting.
function my_acf_init() {
    acf_update_setting('google_api_key', 'xxx');
}
add_action('acf/init', 'my_acf_init');

It’s often tough to navigate complex code and know where to paste it.

Display ACF Google Map with PHP code

Be sure to Register the Google Map JS API key as mentioned above. To display a live map, we need to transfer the field data (about the selected marker) to the front JS. Then we need to query the Google Maps API, and ensure the map is uninitialized. Below we provide a universal code, that suits both cases, for when you either have a map marker or not.

1. Create the markup

Add the code below into your theme template file or to your functions.php as a code snippet.

<?php

// TODO your field name here
$mapInfo = get_field("map");

$zoom = $mapInfo['zoom'] ?? '16';
$lat = $mapInfo['lat'] ?? '';
$lng = $mapInfo['lng'] ?? '';

// zoom level - gets from every specific map (when admins zoom out and saves a page, the zoom is also saved)
printf(
    '<div class="my-map" style="width:100%%;height:400px;" data-zoom="%s">',
    $zoom
);

printf(
    '<div class="my-map__marker" data-lat="%s" data-lng="%s"></div>',
    esc_attr($lat),
    esc_attr($lng)
);

echo "</div>";

2. Query Google Maps JS

Use the code below to load the Maps JS API for all pages.

<?php

add_action('wp_footer', function () {
    $apiData = apply_filters('acf/fields/google_map/api', []);

    $key = $apiData['key'] ?? '';

    $key = !$key ?
        acf_get_setting('google_api_key') :
        $key;

    if (!$key) {
        return;
    }

    wp_enqueue_script(
        'google-maps',
        sprintf('https://maps.googleapis.com/maps/api/js?key=%s&callback=googleMapsCallback', $key),
        null,
        true
    );
});

This code snippet uses the same Google API key that you’ve defined for ACF for site admins.

Pro tip: For better performance, we recommend adding some checks, to make sure this only loads on pages where the map exists. E.g. Limit it to a single page by URL with is_page, or to the CPT type with is_singular.

3. Initialize the map

Continue by adding the following JS code to the target page.

class Map {
    constructor(element) {
        this.element = element
        this.map = null
        this.mapMarkers = []
    }

    readMarkers() {
        // TODO replace the selector if you've changed it in the markup
        this.element.querySelectorAll('.my-map__marker').forEach((markerElement) => {
            let lat = markerElement.dataset.hasOwnProperty('lat') ?
                markerElement.dataset['lat'] :
                0
            let lng = markerElement.dataset.hasOwnProperty('lng') ?
                markerElement.dataset['lng'] :
                0

            this.mapMarkers.push({
                lat: parseFloat(lat),
                lng: parseFloat(lng),
            })

            markerElement.remove()
        })
    }

    createMap() {
        let mapArgs = {
            zoom: parseInt(this.element.dataset.hasOwnProperty('zoom') ?
                this.element.dataset['zoom'] :
                16),
            mapTypeId: window.google.maps.MapTypeId.ROADMAP,
        }
        this.map = new window.google.maps.Map(this.element, mapArgs)
    }

    createMarkers() {
        this.mapMarkers.forEach((marker) => {
            new window.google.maps.Marker({
                position: marker,
                map: this.map,
            })
        })
    }

    centerMap() {
        // Create map boundaries from all map markers.
        let bounds = new window.google.maps.LatLngBounds()

        this.mapMarkers.forEach((marker) => {
            bounds.extend({
                lat: marker.lat,
                lng: marker.lng,
            })
        })

        if (1 === this.mapMarkers.length) {
            this.map.setCenter(bounds.getCenter())
        } else {
            this.map.fitBounds(bounds)
        }
    }

    init() {
        if (!window.hasOwnProperty('google') ||
            !window.google.hasOwnProperty('maps') ||
            !window.google.maps.hasOwnProperty('Map') ||
            !window.google.maps.hasOwnProperty('Marker') ||
            !window.google.maps.hasOwnProperty('LatLngBounds') ||
            !window.google.maps.hasOwnProperty('MapTypeId') ||
            !window.google.maps.MapTypeId.hasOwnProperty('ROADMAP')) {
            console.log('Google maps isn\'t available')
            return
        }

        // before the map initialization, because during creation HTML is changed
        this.readMarkers()
        this.createMap()
        this.createMarkers()
        this.centerMap()
    }
}

class Maps {
    constructor() {
        this.isMapsLoaded = false
        this.mapsToInit = []

        // TODO change to yours if you've defined own callback (for https://maps.googleapis.com/maps/api...)
        window.googleMapsCallback = this.mapsLoadedCallback.bind(this)

        'loading' !== document.readyState ?
            this.setup() :
            window.addEventListener('DOMContentLoaded', this.setup.bind(this))
    }

    setup() {
        const observer = new MutationObserver((records, observer) => {
            for (let record of records) {
                record.addedNodes.forEach((addedNode) => {
                    this.addListeners(addedNode)
                })
            }
        })
        observer.observe(document.body, {
            childList: true,
            subtree: true,
        })

        this.addListeners(document.body)
    }

    mapsLoadedCallback() {
        this.isMapsLoaded = true

        this.mapsToInit.forEach((map) => {
            map.init()
        })

        this.mapsToInit = []
    }

    addListeners(element) {
        if (Node.ELEMENT_NODE !== element.nodeType) {
            return
        }

        // TODO replace the selector if you've changed it in the markup

        element.querySelectorAll('.my-map').forEach((mapElement) => {
            let map = new Map(mapElement)

            if (!this.isMapsLoaded) {
                this.mapsToInit.push(map)

                return
            }

            map.init()
        })
    }

}

new Maps()

The snippet above will initialize all the maps on your page, that have the markup from the first step. If you made changes to the markup classes, don’t forget to reflect them here too (see TODO).

This snippet uses the MutationObserver feature, so it will work even in case your maps’ info was added dynamically, e.g. after an ajax request.

You can read more about the Google Map field in the official ACF article.

The road to endless possibilities.

Display ACF Google Map with a shortcode

Using the code method is quite complex and becomes a little worse when you want to do more with a Google Map, it’s worth mentioning that there are some drawbacks, of which the biggest is that you would need to write and add several different code snippets (see above PHP way).

However, there is an alternative way to solve this without so much code. It will still allow you to display the Google Map and you can have markers too. It’s done with the incredible ACF Views plugin. It was built for handling complex field types, read more about the shortcode approach here.

ACF Views will create the HTML markup, so you won’t have to. All you do is install it, active it and start creating. You select fields from a dropdown, one by one, each field has some settings, then once you publish your ACF View you get shortcodes, each with its own purpose. Copy the shortcode in place on a post or page, that’s it.

Read more on how to display Google Map fields without coding and the field options available.

How-to Step-by-step

Follow along by installing and activating the ACF Views plugin on your WordPress website. You’ll also need Advanced Custom Fields installed and active, both plugins are available free of charge from Wordpress.org plugin directory.

Now that you’re ready, let’s continue.

Step 1. Define Google Map API key

Be sure to Register the Google Map JS API key as mentioned earlier.

See the ACF Views Google Map field for up-to-date documentation.

Step 2. Create an ACF View

When you activate the ACF Views plugin a new item appears in the admin menu, called “ACF Views”. The item has several sub-items, but in our case, we’ll be working only with the one called “ACF Views”.

Click that menu item to open the ACF Views page and then click the ‘Add New’ button to create a View. On the new page give your View a name, it can be anything that describes the View. I’ve called my View “business locations”.

Step 3. Assigning fields

It’s time to assign the Google Map field to your View. Click on the ‘Add Field’ button and select your ‘Group’ from the dropdown. In my case, I’ve called the group “Map Location”.

Assign the ACF Google Map field in your ACF View.

Then continue to select the target field from the list. I’ve selected “Map” which is what my Google Map field is called. See Field Options tab for more settings and to hide map or change address format (only in ACF Views Pro).

Now you can ‘Publish’ your ACF View or click ‘Update’ (if you’ve saved before), then copy the first shortcode and paste it in place, anywhere in the post or page content area. For Gutenberg editor, use the “shortcode” block. Save your page and view the post/page to see the results.

That’s it, you’re done.

A Google Map with location marker.

Final thoughts

In this tutorial we’ve shown you how to use and display an ACF Google Map field in two ways with an added bonus for native Google Map Embed, the first with coding and the more practical and easier way with using a shortcode.

An ACF View can contain any number of fields of different types, which means you could extend your View at any time, ACF Views supports all available field types with extended support for complex fields.

Different types of maps on a stand

To get more info about the plugin we’ve used in our shortcode example, visit the official plugin page.

Maps don’t always need to be associated with a business, you can create literally any type of map.

Have fun out there!

Originally published at https://wplake.org on May 1, 2023.

How to use and display the ACF Repeater field

WPLake — Mon, 03 Apr 2023 14:10:49 +0000

About the Repeater field

The ACF Repeater field is one of many ACF field types and is known as a complex field, mainly due to the fact it allows you to add sub fields that can be repeated over and over again when editing content. So it’s true to its name.

The Repeater field is similar to the ACF Group field in that allows you to “group” sub fields, although with the Group field you can’t “repeat” the sub fields, only one set of sub fields is allowed.

A huge benefit of the Repeater field is that you don’t need to create another Custom Post Type (CPT), yet you can still display a list of items.

Layout options

The Repeater field has Layout settings with 3 options, these are Table, Block and Row. Whichever you’ve chosen here will affect the look of the field for admins and editors.

When choosing the “Table” layout you’ll be presented with a Table of sub fields on the edit screen, with labels in the table header. When choosing the Block layout the sub fields are displayed in blocks, one after the other, and with Row, sub fields are displayed in a two column table, with labels in the first column.

The three types of layout options for the ACF Repeater field. Fltr: Block Layout, Table Layout and Row Layout

Pagination in the field creation step, when switched on is useful for when you have a large number of repeater rows, this helps to improve the performance while saving (before, saving even just 10 rows took some time).

Repeater pagination for a large number of rows to improve performance.

Behind the scenes in ACF

Behind the scenes, the ACF Repeater field stores the data in the Custom Fields’ Meta of the current page (or post).

As you know, the repeater field allows you to have multiple rows of the same sub fields and stores it within a single main field. It sounds simple enough, but it could lead you to think that in the database, it’s also saved as a single meta field, when really it isn’t.

Field Search Queries

Remember, pay close attention to the fact that, users and developers should have the option to make search queries by this field. E.g. You have several posts, each with a repeater with several rows, and you need to find them all, how would you know the specific value exists in one of the rows? This task actually appears much more often than you may think.

The Developers at Advanced Custom Fields (ACF) already thought about this, and decided to store each sub field in its own meta field, but with a special structure.

Repeater sub fields in the WP meta table.

As seen above each sub field is prefixed with the row number, and the repeater name.

So, for example, you named your repeater field ‘datasheets’, and your sub fields are called ‘datasheet’ and ‘attachment’, then in the database they’ll be stored in the following way:

datasheets_{row-number}_datasheet and 
datasheets_{row-number}_attachment, 
where {row-number} begins from zero.

When you “request” this field from ACF with the get_field function, ACF does a trick and turns this structure into an array, so you can work in PHP in a similar fashion as with a plain array. In our example, if we need to get the sub field from the first row, we would be able to do this with the following code:

$datasheets = get_field('datasheets'); 
echo $datasheets[0]['datasheet']; 
echo $datasheets[0]['attachment'];

It’s important to know and understand this approach, as querying posts by repeater sub fields requires knowledge of the structure, to be able to write the correct WP_Query. You can learn how to create a WP_Query for repeater subfields in the official Docs.

Performance

The Repeater field is a useful feature that helps you store multiple data entries, but it also has a drawback, which is the search performance for larger datasets.

So, although querying by sub fields is possible, it eats much more server resources and takes more time when compared to Custom Post Type (CPT) items and taxonomies.

You won’t notice the difference in case you’re querying for several posts that have 5 to 10 rows each, but if we talk about a few hundred posts with lots of rows, then it’ll be much slower than the alternative CPT approach. Therefore, if you know there’ll be a lot of data, and you would need to query for them, consider creating a CPT instead. Creating CPT’s is possible with the ACF plugin since version 6.1 beta

Display ACF Repeater with PHP code

Displaying Repeater sub fields means you’ll need to create HTML markup, for the fields and for the variables for when fields are filled.

Here’s some examples of PHP code needed to display sub fields and a basic image slider.

PHP code to display Repeater sub field values with the Basic loop.

$items = get_field('repeater');
// value can be null, convert in case the array is empty
$items = $items ?: [];

echo "<div class='view'>";
foreach ($items as $item) {
 printf("<div class='view__address'>%s</div>", $item['address']);
}
echo "</div>";

PHP code to display a basic image slider.

$items = get_field('repeater');
// value can be null, convert in case the array is empty
$items = $items ?: [];

echo "<ul class='slides'>";
foreach ($items as $item) {
 // Return Format of the image must be 'ID'
 $imageId = $item['image'];

 // skip if the image is not selected
 if (!$imageId) {
     continue;
 }

 // wp_get_attachment_image() will create HTML markup for the selected image (the img tag)
 printf("<div class='slides__slide'>%s</div>", wp_get_attachment_image($imageId, 'full'));
}
echo "</ul>";

You can read more about the Repeater field in the official ACF article.

If you’re interested in the more technical side of WordPress, consider reading about what good WordPress developers must know.

Display ACF Repeater with a shortcode

Using the code way to display the fields is quite flexible, but has many disadvantages;

It takes some time to write the code.
You need to know the Return Types of the sub fields.
Remembering specific key names for the response array.
You need to manually find the correct page template in your theme and amend it.

On the other hand, there’s another way that allows you to display the ACF Repeater field, (and its sub fields) without having to write the code. The ACF Views plugin allows you to display ACF fields, and with ACF Views Pro, you can display complex fields which includes the Repeater field, thus making it super easy and saves tons of time.

ACF Views takes care of the HTML markup. We only need to choose the ACF fields to display, then copy the auto-generated shortcode and paste it into any place on a page, that’s it, there’s nothing else we need to do except style the output.

Watch a short video tutorial below on how to display ACF Repeater fields using the shortcode way.

There are more video tutorials on the Official YouTube Channel.

Skip past the video for a full texted based, step-by-step guide for displaying the ACF Repeater.

https://youtu.be/VON-Ew_FIW8

How-to Step-by-step

If you’d like to follow along, then please purchase, install and activate ACF Views Pro plugin on your WordPress website. You’ll also need to install and activate Advanced Custom Fields Pro to unlock the Repeater field type.

Now that you’re ready, let’s continue.

Step 1. Creating a View

Click that menu item to open the Views page and then click the ‘Add New’ button to create a View.

On the new page give your View a name, it can be anything that describes the View. I’ve called my View “download datasheets”.

Assigning fields

It’s time to assign the Repeater field and subfields to your View. Click on the ‘Add Field’ button and select your ‘Group’ from the dropdown. In my case, I’ve called the group “Download Datasheets”.

Then continue to select the target field from the list. I’ve selected “Datasheet”.

Assigning ACF fields to your ACF View with a dropdown.

You’ll notice that each field will have it’s field type shown in brackets. In this case you should see the type as “repeater”. Continue by switching to the “Sub fields” tab and then add your sub fields from the list, one at a time and then insert a label for each field as required.

Pro Tip: Add the first field, then duplicate the row and change the field to another. This saves time not having to first select the Field Group each time and then choosing the field.

Assigning Sub fields to an ACF View.

Click the “Publish” button to save and publish your View. Shortcodes are then generated and shown on the right of the View edit screen. Read more about the different shortcodesand their uses in the ACF Views docs.

Copy the first shortcode without the object-id parameter to the clipboard.

E.g. [acf_views view-id=”123" name=”Name of View”]

Step 2. Paste the shortcode in place

Everything should now be ready to display your ACF Repeater field. Go to your target page (the page where you’ve located your ACF fields) and on the edit screen, paste the copied shortcode anywhere you’d like in the page content.

In case you’re using the Gutenberg editor: click on the plus button in the top bar and choose the “Shortcode” block from the list, then paste your shortcode in the block.

Now, all that’s left to do is to fill in the fields (sub fields really). Add more rows of sub fields as you need them.

In my case I have a ‘Datasheet’ text field, and a file field I’ve called ‘Attachment’. I ended up using three Repeater rows for English, French and German datasheets.

Rows of Repeated fields for my Field Group Datasheets.

Be sure to save your page by clicking “Update” or “Publish”, then visit your page. As a result and if you’ve done it all correctly then you should see the list of Repeater items.

The final result of my Repeater Datasheets field group with CSS styles.

If you don’t see your list of items, then go back and edit the page. For instance, make sure you’ve filled the fields and saved the page, if they are indeed filled, then go further back to your View edit, were you assigned the fields. Then double check they’re assigned from the correct field group. Consequently if you’ve left the fields unfilled on the page or post then there’ll be nothing to display.

Learn how to display repeater fields on WooCommerce product pages, so relevant information is seen by potential customers.

Final thoughts

In this tutorial we’ve shown you how to use and display ACF Repeater fields in two ways, first with coding and the more practical and easier way with using a shortcode.

A View can contain any number of fields of different types, which means you could extend your View at any time, ACF Views supports all available field types with extended support for complex fields.

Get more info about the plugin we used in our shortcode example, by visiting the official plugin page.

Only the sky’s the limit now with what you can achieve with WordPress, Advanced Custom Fields and ACF Views. Good Luck.

Originally published at https://wplake.org on April 3, 2023.

5 important things about WordPress Cron

WPLake — Tue, 28 Feb 2023 12:24:36 +0000

WordPress Cron provides an easy way to schedule actions without taking care of the implementation. We review specific moments to help you manage Cron properly.

What is Cron?

The Cron in short, is a way to run some tasks (or jobs if you will) on a schedule. For example, to keep the currency rates up-to-date on your website you need to update them once a day. Instead of doing it manually, you create a cron task and set it up with the frequency of once a day. Cron is widely used in many WordPress plugins and themes to keep information up-to-date.

System Cron VS WordPress Cron

With WordPress you have 2 different ways to do it.

System Cron

The first way is adding it in the Linux system cron (this is on your hosting server). These tasks are in the /etc/crontab file and with this approach being the most universal and most reliable way to run Cron tasks. Your server operating system (e.g. Linux, Ubuntu or RedHat) guarantees that tasks in our PHP files will be called as they were scheduled, regardless of any external events.

Though it’s more universal and reliable, it has no integration with WordPress. This means if you call PHP files within your theme directly, then they won’t have access to any WordPress functions and the Database. Due to the fact that WordPress can’t load properly in this way. Furthermore, it’s not suitable for plugins, because if you’re using the plugin, you can’t simply set up the system Cron for all your clients.

WordPress Cron

Then here WordPress Cron comes in and is the second way to run cron tasks. You can easily registry your cron task within WordPress, and WordPress will take care of loading and executing your tasks within your specified schedule. Sounds sweet, and it’s suitable for plugins.

What can be better, right? But nothing is perfect and this approach also has drawbacks.

WordPress is a PHP based application and has no access to your system Cron (OS running on your host). In fact, it means WP needs some external event to check the schedule list and execute relevant tasks. Another thing is that WordPress can ONLY run Cron tasks when someone visits or opens a page on the website. If nobody visits your website, the Cron tasks will NOT run.

This may sound scary, but the good news is that WordPress guarantees that tasks will be called , there just isn’t a guarantee when exactly they’ll be called. For example, you’ve set up a Cron currency rates task to run once a day. Now in real life it means the task will be executed with the first visitor, after one day at the set time. Not earlier, but perhaps later, maybe even much later if you’ve had no visitors for several days.

There are some tasks that are okay to run with this approach, however while nobody visits your site, Cron doesn’t run and therefore doesn’t actually “work”. But there are other tasks that require reliability. So if your cron tasks are about pulling info from external sources, or simply very important tasks that need to run, like any API stuff, you can’t rely on this approach.

Verdict

Both ways have their advantages and drawbacks.

For that reason the best solution which is used by professionals, and recommended by WordPress, is a combination of the two approaches, giving you the best of both and having them counteract each others drawbacks.

As a website owner (or a developer) you need to set up the system Cron job which will call WordPress Cron. Overall, it’s relatively simple to do, and in this way WordPress Cron will be more reliable while keeping the native WordPress approach.

See point no. 2 below to learn how to go about it.

About WordPress Cron

Above, we’ve learned that WordPress a PHP-based application, and its internal Cron relies on external events, i.e. user requests. Besides this fact, there is a list of important aspects, which we’ll go through in more detail.

1. WordPress Cron is asynchronous

Firstly, you should know that WordPress Cron is asynchronous. Asynchronous means it runs Cron jobs in a separate request from the event itself.

So, a user request won’t have delays due to WordPress Cron , a user that triggered some Cron job won’t wait until the job is finished to see the result of his request. So you can breathe easy knowing there aren’t any delays for your visitors. WordPress handles it all quietly in the background.

If you’re interested in the finer details, then technically it happens in the following way;

WordPress checks the Cron schedule on every user request to a website, and if there is a need to run Cron jobs, it creates a new request to the website cron file ( /cron.php ), using the cURL library. The user receives the response to their request immediately, while Cron executes the other cron tasks in a separate request, which is independent.

2. WP Cron isn’t reliable (out-of-the-box). Way to fix

As we already know, WordPress Cron out-of-the-box depends on external events. Compared with the system Cron, it has a big drawback. But we can easily fix it by merging the system Cron and WordPress Cron.

So the solution is creating a Cron job within the system Cron and calling WordPress Cron from there. In this way, we receive a reliable Cron with all WordPress features and support for plugin cron jobs. It may sound a little tricky, but it isn’t really.

For the official manual see here.

The task can be split into 2 steps. The first step is about creating a new system Cron job. Basically, there are two different types of hosting (shared and dedicated), and how to create cron jobs depends on your hosting type.

How to add a system Cron job for shared hosting

When using shared hosting, there are many different vendors, and you need to check the features offered by your vendor about the Cron tasks. Usually, a hosting admin panel has a special tab or item about Cron, where you can manage Cron jobs. The most common admin panel is cPanel, you can read more on how to add a Cron job for cPanel in the official article. Below is the official video.

How to add a system Cron job for the VPS hosting

In case you’re an owner of VPS (Virtual Private Server i.e. Dedicated), you need to log in to your server with SSH and run the following command to open a file in editing mode.

Step 1. Setup a system Cron job for WordPress Cron

Now it’s time to create a system Cron job that will call WordPress Cron. Add a new line in your cron file and copy the content below.

*/10 * * * * wget -q -O - https://YOUR_DOMAIN_HERE/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Note: The line above isn’t suitable for use with WordPress Multisite mode. If you’re using WP Multisite mode and you need a reliable Cron, then read more about workarounds here.

Don’t forget to replace YOUR_DOMAIN_HERE with your domain.

The first part of the command states that we want our command to be executed once every ten minutes, regardless of an hour number, day of the week, and others options. The middle part uses the wget tool to request the WordPress Cron file, and the last part states that we don’t want to save the output of the Cron file.

You can read more about the arguments here.

Step 2. Disable default WordPress checks

As we’ve now integrated WordPress Cron with the system Cron, WordPress no longer needs to check the schedule list within every user request. We tell WordPress by setting up a special constant in the wp-config.php file.

/* Add any custom values between this line and the "stop editing" line. */

define( 'DISABLE_WP_CRON', true );

/* That's all, stop editing! Happy publishing. */

As you can see the file has a special section for custom values, so you need to add this constant after the first comment, and before the second.

Don’t worry about the label of the constant, “ DISABLE_WP_CRON ” doesn’t actually mean completely disable WordPress Cron. It disables the checking of the schedule list with every user request. WP Cron should still work properly, as we call the wp-cron.php file directly via the system Cron.

That’s it! Congrats! Now your WordPress installation has a reliable Cron with all the WordPress features. Cron will run jobs according to the schedule, regardless of the amount of visitors’ to the website.

3. How to add and remove Cron jobs

WordPress Cron job is just a bit of PHP code that is executed by some schedule. Furthermore, it can use all the WordPress features and has access to the Database. Here you can find an article for developers from WordPress on this topic.

Choosing an interval

Firstly, we need to choose an interval by which Cron will repeat our job. Default WordPress intervals are hourly , twicedaily , daily , weekly. Though it’s good enough for most cases, you may need a custom interval. We can define it by adding the following code.

add_filter('cron_schedules', function ($schedules) {
    return array_merge($schedules, [
        // here is the name of our custom interval. used when adding a new job
        'five_hours' => [
            // the number here represents seconds, so the formula is: 5 hours * 60 minutes * 60 seconds
            'interval' => 5 * 60 * 60,
            'display' => esc_html__('Every Five Hours'),
        ],
    ]);
});

Adding a new reoccurring job

To add a new Cron job we need to add a new shortcode and attach a schedule to the shortcode. The interval (the second argument to the wp_schedule_event() function) must be of one of the default intervals, or some custom name that you can add using the code snippet above.

add_action('YOUR_NAME_HERE', function () {
    /* your job here
    you can use all the WordPress features and functions
    e.g. wp_insert_post() */
});

// we must check that the event wasn't scheduled as each call creates a new one
// otherwise, if we've skipped the check it'll create a new event for each user request
if (!wp_next_scheduled('YOUR_NAME_HERE')) {
     /* the first argument is the timestamp which controls when the job 
       will be run for the first time
       the next argument reflects the chosen interval */
    wp_schedule_event(time(), 'hourly', 'YOUR_NAME_HERE');
    return;
}

In the code above we’ve created an empty job that Cron runs once an hour.

Adding a new single job

The example above adds a job that Cron runs in a reoccurring method. But you also have the option to schedule a single job. For this goal, you need to use the wp_schedule_single_event() function instead of the wp_schedule_event(). It can accept two (2) types of arguments: timestamp with the next execution time and the hook that contains the job. So let’s create a job that Cron will run only once, after 5 hours:

add_action('YOUR_NAME_HERE', function () {
    /* your job here
     you can use all the WordPress features and functions
     e.g. wp_insert_post() */
});

// it's necessary to check that the event wasn't scheduled as each call creates a new one
// if you've skipped the check it'll create a new event for each user request
if (!wp_next_scheduled('YOUR_NAME_HERE')) {
    // as before, the first argument is the timestamp which controls when the job will be run
    // it's presented in seconds, so the formula is: 5 hours * 60 minutes * 60 seconds
    wp_schedule_single_event(time() + 5 * 60 * 60, 'YOUR_NAME_HERE');
    return;
}

Removing a Cron job

You can remove a scheduled job that you have previously added. It’s especially useful for reoccurring tasks. For this purpose, we’ll call the wp_unschedule_event() function with a couple of arguments. The first must contain the next timestamp for the event (we get it dynamically) and the second is your job name.

The code below removes single and reoccurring jobs. Also, pay attention, that for the reoccurring jobs, it’ll not only remove the schedule or the next event but also all future events of the job.

add_action('YOUR_NAME_HERE', function () {
    /* your job here
     you can use all the WordPress features and functions
     e.g. wp_insert_post() */
});

// it's necessary to check that the event wasn't scheduled as each call creates a new one
// if you've skipped the check it'll create a new event for each user request
if (!wp_next_scheduled('YOUR_NAME_HERE')) {
    // as before, the first argument is the timestamp which controls when the job will be run
    // it's presented in seconds, so the formula is: 5 hours * 60 minutes * 60 seconds
    wp_schedule_single_event(time() + 5 * 60 * 60, 'YOUR_NAME_HERE');
    return;
}

4. How to monitor Cron jobs

Information about all WordPress Cron jobs is stored in the Database. This means we can get a list of all the scheduled jobs and manage them. It’s an important thing for developers and website owners.

If you have seen the WordPress Database scheme, then you know that there is no separate table for Cron. All Cron tasks are stored within a single option in the Options table. Most likely you already know this table, as any good WordPress developer knows the main tables of the WordPress Database. This knowledge is necessary to clear understand internal processes. If you want to check and improve your knowledge, read what must a good WordPress developer know.

WordPress stores Cron tasks as an option in the Options table

But looking at the serialized data directly via PhpMyAdmin isn’t the best idea. That’s why we’ll use the WP Crontrol plugin which will give us a clear UI. Using the tool we can debug our Cron jobs or check external ones that are added by plugins. For example, we created our custom Cron job and ran it immediately using the tool to make sure it works correctly.

The plugin provides the interface for managing both Cron jobs and the intervals. Using it is quite simple. Install and activate the plugin then visit the “Tools” — “Cron events” item in your admin menu.

Here you can manage Cron jobs (called Cron Events) and Cron Intervals (called Cron Schedules).

You can control each job individually. Hover your cursor on the target item to see the list of actionsp

5. Cron and Cache plugins

The important thing that you have to pay attention to is the collaboration of WordPress Cron and cache plugins. Most WordPress websites use some cache plugin to reduce the response time. Overall the approach is good and important for SEO. Also, cache means a lot for WordPress speed optimization. But in our case, it also means we skip PHP execution and return HTML.

By default, WordPress Cron relies on user requests. Whether or not WordPress Cron will be called during requests to cached pages depends on the plugin that’s in use. From our experience cache plugins don’t call WordPress Cron or call Cron more rarely than when it’s out-the-box.

WordPress Cron will still be called during editor visits to the dashboard, but that may not be enough. This approach is okay in case your Cron jobs aren’t important and can be delayed for longer periods. Otherwise, consider the second part of the article.

The solution described in the second part of the article, regarding the merging of the system Cron and WordPress Cron, shows the clear benefits, so if you have used it in that way then you’re set and don’t need to worry about it any longer.

The wp-cron.php file is called directly and WordPress Cron will work properly.

Conclusion

We’ve reviewed the 5 important things about WordPress Cron. We recommend following the second part (merging system Cron and WordPress Cron) for each of your WordPress sites. It’ll save you from tonnes of headaches in the future. Also, don’t forget about the tools that allow you to monitor your Cron jobs. They’re quite useful.

We hope our article was helpful to you, and that you now have a clear picture of WordPress Cron and how to add your own Cron jobs using the code snippets.

Guide for WordPress Multisite

WPLake — Fri, 30 Dec 2022 12:45:15 +0000

Learn about WordPress Multisite Network, when you may need it and how to setup. We’ll review advantages and drawbacks, and also will share tips that will help to create, manage, or split your own multisite.

About WordPress Multisite

You can be familiar with WordPress for many years, but may not know what is WordPress Multisite. That’s because most WordPress websites are a single installation. This feature is used pretty rarely, but it’s an essential feature of WordPress, and in some cases can be indispensable.

What is a WordPress Multisite Network? It’s a couple, or more, WordPress websites that use a single WordPress installation. It means they have a common file system and a common Database. Don’t worry if it sounds foggy, we’re going to review it in a simple example.

An example with flowers

Let’s say we have a website about flowers, and our domain is flowers. We review all kinds of flowers here, but there are very popular kinds, like roses. So we have a lot of requests about them and want to dedicate a separate website, which will cover only them. It may be either roses.flowers or flowers/roses.

A separate website means a lot of work, we’ve to create a new theme, and set up and configure all plugins. And what if we want to have a separate website for several kinds of flowers, not only roses? It means we’ll have many different WordPress websites, with separate dashboards.

Just imagine that you’ll need to login into all of them from time to time. Updating plugins on each of them will be a problem. But the real nightmare will be updating a theme, if you’ve made changes to one of the websites, you’ll need to repeat the update on each of them.

WordPress Multisite feature suggests a solution. A network of WordPress websites that use the same installation. In our case with flowers, we can have an unlimited number of subdomains (kinds of flowers) for our primary flowers website, and all of them will be available via one dashboard. They’ll use one installation, which means all of them will have an access to the primary plugins and your theme. You’ll update plugins or make changes to the theme only once, and all subdomains will display it immediately. It’s possible thanks to the common file system.

Limitations of Multisite

We hope it’s clear to you now overall, what is WordPress Multisite. Let’s talk about limitations, to understand in which cases it won’t work.

The biggest limitation is the domain. WordPress Multisite feature can work only with subdomains or subfolders. It means we technically can’t join several different domains, like flowers and clothes. The feature allows joining only subdomains of one domain.

A subdomain is a secondary domain that is based on the primary. For example, in the case with roses.flowers the flowers is a primary domain, and a subdomain.

A subfolder looks like a plain permalink, but instead of a page contains a whole website. For example, in the case of flowers/roses , the roses will be not a page, but a website. It means that all pages of the roses website will have the such prefix. For example, flowers/roses/history and flowers/roses/how-to-care

WordPress Multisite allows joining the primary website and all subdomains into a single installation, single network. If you want to have different domains, unfortunately, you must use several single installations.

There are other differences between single and multisite installations, but they aren’t limit us. We’ll review them a bit later.

Features of Multisite

Now let’s review the key principles of the Multisite.

a) Common file system

All websites in the Multisite Network use the same single folder. It means a common list of plugins and themes. Don’t worry, each website has its own active list, so you can activate some plugins or a theme only for one website of a Network.

Uploads of the primary website are still stored within the ordinary /wp-content/uploads/ folder. Uploads for secondary websites (subdomains) are also stored within the /wp-content/uploads/ folder, but within adding subfolders.

For example, a newly uploaded tulip.png to the primary website will be saved as /wp-content/uploads/2022/12/tulip.png. A newly uploaded rose.png to the secondary website will be added to a subfolder, like /wp-content/uploads/sites/2/2022/12/rose.png. Where 2 in this path means an ID of the secondary website. Each secondary website in the Network will have its own ID, but you shouldn’t take care of it.

b) Shared Database

All websites will use a single Database. But each website will have its own tables for content. Posts, PostMeta, Taxonomies, Options, all of it will be unique for every website. It means you can have different pages, categories, and settings for each website, just like in the case of independent websites.

An exception is the Users, they’ll be common for the whole network. It’s a good thing, otherwise, editors and users would have to sign up separately for each of them. But don’t worry, user roles are unique for every website, so you can easily manage access. For example, you can deny users from website A to use of their credentials to log in to website B. Of course, if it needs.

WordPress Multisite creates several extra tables, like wp_blogs and wp_sites , but you shouldn’t worry about them. Those tables are needed for WordPress to manage the Network.

c) Dashboards

There is one common dashboard for a whole Network, and separate for websites.

A new role appears, Super Admin. By default, this role will have that administrator, which has created the Network. This administrator will be able to access a Network dashboard, which is common for all the websites. In this dashboard, he will be able to install, update or remove plugins and themes.

Each website still will have a separate dashboard, where its content can be managed in the usual way. Only one new limitation appears here: administrators won’t be able to add, update or remove plugins anymore. Administrators now have only the right to activate or deactivate plugins and themes for the current website. The right to install, update and remove plugins and themes belongs completely to the Super Admin. These changes can be done only via the Network Dashboard. So, you can update your plugins for all the websites in one place. It’s beautiful.

d) robots.txt and .htaccess

It’s important to mention these files separately. robots.txt relates to SEO, and .htaccess manages permalinks (navigation). These files are a part of the file system and will be common for all the websites in WordPress Network.

But there is a major change: WordPress won’t rewrite these files automatically anymore. Before it was so, and every time you visited the Settings — Permalinks page, WordPress rewrote that file automatically. With the Network, you’ll be able to change those files only manually. It’s not a problem, just keep in mind that if your theme has any code that modifies those files, for example, uses the mod_rewrite_rules hook, it won’t work anymore.

Also, some plugins rely on similar hooks, like cache plugins. But don’t worry, all big plugins support the Multisite mode and will show notices with a guide, in case they’ll need to modify .htaccess

e) Cron tasks

Cron tasks will work in the usual way. In case you’ve made no changes and your website uses the built-in WordPress cron, then everything will be the same for you.

But, in case you’ve disabled the built-in WordPress cron, and used crontab (e.g. to guarantee calls with fixed intervals) then your current approach won’t work anymore. You’ll have several websites, and the previous line in crontab won’t cover all of them. To keep using crontab for cron, you must install wp-cli and use a special bash script. You can read more about the setup here. You can also use the bash snippet from that article, just don’t forget to change the relative path in the bash code to absolute.

How to setup WordPress Multisite

Note: before setting up a WordPress Multisite, think twice to make sure it fits your requirements. It’s pretty easy to create a WordPress Multisite, but there is no simple way to split or unmerge the Multisite Network back to single installations. Create Multisite only when you’re sure that you won’t need to have them as separate installations.

There is a great official guide from WordPress, which you can find here.

Overall, the process is pretty simple and consists of several steps.

Important: Don’t forget to make a backup before any changes.

1. Define a special constant (in the wp-config.php )

It’s necessary to unlock the Multisite feature.

define( 'WP_ALLOW_MULTISITE', true );

2. Deactivate all your plugins

It’s necessary to make sure you’ll have no conflicts during the setup.

3. Visit the Tools — Network setup page

Here you have to choose a Network type (subdomain or a subfolder) and you’ll receive pieces of code for your wp-config.php and .htaccess . You’ll need to follow the instructions and paste those pieces into the files.

4. Final. Log in and activation of the plugins

After the steps above, you’ll see a message that asks you to log in again. When you’ve logged in, you’ll see the common Network dashboard and links to the specific website dashboards. Now you can activate your plugins for specific websites.

Congrats! Now you have the Multisite installation!

How to transfer WordPress Multisite

To another hosting

You may need to transfer your WordPress Multisite to another hosting. In this case, no extra actions are required. Everything will be the same as with a single installation. If you’re unfamiliar, you can read the official article from WordPress. You have to move your files, and your Database to the new hosting, and then update DNS records to point to a new hosting. That’s it.

To another domain

It’s pretty easy to move WordPress to another domain if we talk about a single installation. In the case of the Multisite Network, the task can’t be done using built-in tools, as the whole Network depends on a primary domain. But don’t worry, we can achieve it with manual updates in the Database. For example, via PhpMyAdmin.

You can copy your Live database, import it to a new place, and then perform the following:

Changes in the wp_site table Replace the old domain with the new for values in the domain column
Changes in the wp_sitemeta table Replace the old domain with the new one for meta_value in the rows where meta_key = ‘siteurl’
Changes in the wp_blogs table Replace the old domain with the new for values in the domain column

After that, don’t forget to update the DOMAIN_CURRENT_SITE constant in the wp-config.php to the new domain.

Also, don’t forget to make ordinary changes that are necessary for a single installation. I mean changes in the wp_options table for the rows where option_name = ‘siteurl’ or option_name = ‘home’.

That’s it. Following the steps, we’ve moved a WordPress Multisite to another domain.

How to split WordPress Multisite

By default, WordPress doesn’t provide an option to ‘unmerge’ WordPress Multisite Network. The task is pretty unusual, that’s why developers didn’t make a feature for it.

There are only a few reasons why you need to split WordPress Multisite into several single installations. One of them can be a case when the subsites have grown and now have nothing in common with the primary website. So there is no sense to keep them within a Multisite Network anymore.

Usually, in this case, it’s better to create a new installation for each of them, and then import content from the related subsite manually. And then just remove the related subsite in the Network.

As a plan B, you can try to split the Multisite with manual changes in the Database. But you need to have strong WordPress knowledge and skills to work with dumps. Here are the steps that you need to follow for each website:

Make a MySql dump With all tables related to one website, plus common tables: wp_users and wp_usermeta
Import the dump into a new Database Don’t forget to update a table prefix to the ordinary ( wp_ ), in case it was a subsite.
Log in, to make sure everything works If you had roles only on of the websites, you may need to recreate them again

You can easily recognize which tables belong to which website. As we’ve mentioned each website in the Network has an ID. This ID is added to all website tables. For example, the Posts table for the first subsite will have a wp_1_posts name, for the second will have a wp_2_posts name, and go on and go forth. Only the primary website tables will have no prefixes. So, the Posts table name will look like as usual, wp_posts.

Conclusions

We’ve reviewed all important topics related to the WordPress Multisite feature. We hope that now you understand how it works, and what the goal of the feature is.

Using a Multisite Network can solve a row of problems. In case Multisite fits your requirements, use this knowledge to easily create and manage your own WordPress Network.

Thank you for reading! Follow us to get notified about new articles.

Originally published at https://wplake.org on December 30, 2022.

9 tips for WordPress speed optimization

WPLake — Thu, 29 Dec 2022 15:18:49 +0000

WordPress is designed to be fast. We’ll describe deadly mistakes that break it, and features that will help to improve the speed. These 9 practical tips will help you speed up your WordPress website.

Loading time is less than a second and a permanent place in the green area of the PageSpeed Insights tool isn’t a miracle for a WordPress website, but a reachable goal.

In this article, we’ll share practical tips about WordPress speed optimization, and we promise that we won’t lie. We aren’t going to tell you that any existing WordPress website that is super slow, regardless of a number of issues, can be optimized to the 100% using some magic plugin or tool.

Speed is a topic that should be considered from the first day of creating a website. Our tips will definitely help you to improve the speed of your website, but how good results will you achieve, will depend on your WordPress theme.

Developers can learn best practices to build a theme with great performance. In case you’re a website owner and your website is already ready, don’t worry — some tips below will work for all WordPress websites.

How to measure the speed of a website

Note: this chapter is for beginners, feel free to skip it in case you already know it.

First of all, let’s clarify how usually we measure the speed of a website. In this area, we can’t rely on our personal feelings, that say to us was this or that website loaded fast. We use special tools and metrics that show special numbers and reports to us. There are many tools, but we’ll review the most popular.

1. PageSpeed Insights tool

It’s a tool from Google that is available for everyone for free. The tool uses a row of factors, like LCP (First Contentful Paint), TTI (Time To Interactive), TTFB (Time to First Byte), and others. You can read more about them in detail on the official website from Google.

There are two ways to use the tool:

a) Via the website

Here is a tool website, you just need to paste any url and press the Analyze button, and after some time the tool will provide a report. The main score will be in a range from 1 to 100 and will consist of many factors. It’s a very useful tool, as besides the score the report will also contain specific tips for this url, that will help to improve the score.

b) Via Chrome/Brave browser

These browsers have a ‘Lighthouse’ tab in the Developer tools, and you can test any website in the same manner. When you have to make a row of tests this way may be preferred.

2. Developer tools panel

Every browser has its own Developer tools panel, you can open this panel by pressing F12 on your keyboard (your browser must be open of course at this time). I mean here first of all a Network tab. If we talk about estimation, this way will give you only a couple of numbers (DOMContentLoaded and Load), but it’ll be enough for a primary estimation.

This way shows its full power when you need to debug speed issues in detail, as only this way allows easily to get a list of all page resources by categories (fonts, JS, CSS) and their personal load time. So, developers usually use both of these tools, PageSpeed Insights, and Developer tools together.

Why you can trust us

Before we’ll go with the tips, we have to confirm our expertise, so you’ll trust our words and advice. The best confirmation in our view will be not portfolio jobs or screenshots, but something that is easy to see and check. It’s the current website — wplake.org. It’s a WordPress website and his pages (including the current article) have a loading time of less than a second and a permanent place in the greed area of the PageSpeed Insights tool.

100% score for mobile

Loading time is 278MS (a quarter of a second)

I’ve shared screenshots for our blog overview page, you can easily check the results yourself using DevTools of your browser or the PageSpeed Insights tool. All pages of wplake.org have such results, but of course, the final numbers will be a little varied depending on the server loading and the quality of your internet connection.

Tips

1. Don’t use visual page builders

Like Elementor or any others. There are no visual page builders for WordPress, that allow the building of pages with good performance. It’s the nasty truth, but we promised to tell the truth only. These visual builders are attractive for beginners in development or website owners, as give an easy way to build beautiful pages. But everything has a price in this world, and in this case, the price is performance and page loading time.

Pages built by visual page builders have a lot of heavy JavaScript, dirty and overloaded HTML markup and your users will never receive good UX. You can use builders only if you’re ready to sacrifice SEO and user experience to receive easy editing.

Don’t trust their sweet stories that exactly their visual builder is optimized and your website will be fast — trust yourself and check yourself. It’s so easy to open the PageSpeed Insights tool, paste a url of their official website and check the report. For example, I’ve checked elementor.com for you and sharing the result:

I think no extra comments are needed. If the official website of the visual page builder with a big team of developers, that already used all tricks to improve the score, isn’t able to get good results, do you think your website will?

Just look at the markup of their website:

How many classes every element has, this markup is unreadable and stretches the page length, which is harmful to page speed and SEO.

2. Choose the right theme

As we mentioned above, exactly your theme will predict, which the maximum score your website will have. The perfect case is when a theme is custom and built by professional WordPress developers. In this case, they’ll able to use best practices, like using pure JS and avoiding unused CSS/JS code on pages. These things are predicted by a theme, and can’t be changed easily. They can use some bones or frameworks to decrease developing time, but it won’t decrease performance.

In case you don’t have this opportunity and have to choose something from ready WordPress themes, then the same advice — don’t trust promises, trust yourself and check yourself. Check their website via the PageSpeed Insights tool, find and check famous websites that were built using that theme, and only after that purchase and use that theme. It’s not a problem, as usual, themes highlight their top clients.

Theme isn’t a glove, in most cases you won’t be able to change it on a fly. Every theme has its own unique settings and style, that can’t be migrated to a new one automatically.

3. Use CDN for static assets

Content Delivery Network, CDN — is the most simple and cheap way to decrease page loading time. By default, static assets, like images, scripts and styles are placed only on a server of your hosting vendor. It’s a specific place, which means users from other countries, especially those that are away from this location, will have a big loading time of these assets.

CDN vendors offer a solution, a worldwide network of their own servers, that stores copies of your assets. In this way, a user that requests your website will receive assets from the nearest server, which decreases page loading time significantly.

This solution won’t be very useful in case your website reflects a local business. In this case, your visitors always visit your website only from one region. CDN still will be helpful for SEO, as SEO robots are placed in different locations, and consider page loading time. But your users won’t see a big difference.

For our website we use Cloudflare, it’s one of the most famous CDN vendors, furthermore, it has a free tariff which will be enough for most websites.

4. Use SSD hosting

Chose a good SSD hosting vendor. SSD hosting means disks on servers are SSD, not HDD. It will significantly reduce delays in all operations with files and will decrease page loading time.

Even in case you use some CDN, SSD hosting still will make a change. WordPress website consists not only of images and styles: it’s a lot of PHP files that are included within every request. It’s hundreds of requests to the Database (which is also a file btw) and many other operations with files.

It’s not a paid article, we’ve no advertising here, so I’m not going to promote any hosting vendors. Just try to search ‘SSD hosting’ and choose the best, or make sure that your hosting vendor uses SSD disks.

5. Use server cache

By default, when a user requests some page on your website it’s being generated by WordPress from a scratch. It means hundreds of requests to the Database and many PHP operations. Time that came since a user requested some page to the moment when his browser received an HTML code is pretty big. This delay slow downs your website and is harmful to SEO.

You can decrease this time by using the server cache. It means the page generation process happens only once, and then users receive ready HTML without the execution of expensive PHP code.

The are many good cache plugins for WordPress, that take care of everything and make the server cache feature for you the same easy as enabling a plugin. For our website, we use WPSuperCache, which is free.

6. Use lazy loading for images

It’s another very efficient and simple way to decrease page loading time. By default browser parses the HTML of your page and loads all found images immediately. It forces users to wait more and makes a website slower.

Lazy loading says to a browser that images on a page must be loaded only when a user is near them and scrolling a page. In this way downloading images that are at the bottom and invisible delays, and makes loading time better. Then, when a user scrolls, a browser loads images step by step, but in ahead, so it all happens in the background and unnoticable to the user.

Before developers had to write their own JS code to implement lazy loading, but now all major browsers support it. You can use the loading="lazy" attribute for images. Read more about the attribute here.

WordPress since 5.4 has it by default for all images that are added to a page via the Gutenberg editor. But it also depends on your theme, many images can be out of the Gutenberg content and have no lazy loading. You need to check if the loading="lazy" attribute is presented for all of the images, and in case it isn't, then you've to amend your theme or ask your developer.

7. Use pure JavaScript

Under pure JavaScript and I mean avoiding using any big libraries, like jQuery. Using TypeScript is still a good idea, as it makes your JS code better, and after compiling turns it into plain JavaScript.

There are so many libraries and tools that use jQuery, so many sliders, tables, and data charts. Forget about them. Do not use jQuery, use only pure JavaScript and libraries that don’t require jQuery.

Using jQuery on a front will slow down your website, as the library contains hundreds of functions. From them you’ll use only a few on a page, others will just waste precious loading time. Furthermore, jQuery code isn’t optimized regarding working with DOM. It means this library can’t provide a good and smooth experience for users.

It may sound complex and difficult to forget about jQuery, but believe us, you’ll get used to pure JS very quickly. Prety soon you’ll ask yourself: why did I use it before? After some time you’ll have your own list of pure-js libraries that will help you in solving different tasks.

We can suggest using the @splidejs/splide package to create sliders and carousels, this package is written on pure JS and helps to create sliders very easily, is also flexible, and has a lot of settings. You can read more about the package on the official website.

Open to yourself WebComponents. This feature is supported by all major browsers and allows you to work with HTML elements easily. You can read more about it here. On our website we use Catalyst. It’s a tiny TypeScript library that makes working with WebComponents super easy.

8. Use minification and avoid unused CSS and JS

Unused CSS and JS

A large amount of unused CSS rules and JS code is one of the main reasons that make your website slow. Usually, it happens when you’ve global styles and scripts for a whole website or for many different templates.

In this case the story with jQuery repeats, a page uses only a bit of a CSS or JS file, but a browser has to load all the file. Precious time is spent, as CSS and JS files require not only loading, but also parsing and executing, which is expensive about resources.

Minification

Your CSS and JS code is written by humans. It means variable names must be pretty long there (to be clear), and formatting (spaces, tabs) is used to make code readable. But any browser is software and doesn’t require it. Empty spaces and tabs can take more than half of the size of a not minified file. Minification is a process that removes all spaces from human-written code and replaces variable names with shorter. For example, var screenSize=1920; will be replaced with var o=1920;. Do you see how shorter it is? Programmers can't use such short names, as this code isn't readable for humans, but a browser won't have any issues with such code.

The solution

The solution for both is creating template-specific CSS and JS bundles. Bundle is a file that contains a row of small CSS/JS modules. It can be done only within a theme, so if you’re a website owner without coding skills then you can’t change it for an already existing theme.

In case you’re a developer, consider Webpack or alternative solutions that allow keep CSS and JS in modules and provide an automatic minification process.

In this way for example homepage and contact page will have different CSS and JS files, that will contain rules only for presented elements. Don’t worry, you still can have common elements, as modules can be imported many times, so you won’t need to write the same code multiple times.

On our website we use LaravelMix, a Webpack extension that takes care of all settings of Webpack and provides a super easy way to work with Webpack.

9. Inline critical CSS

This is a powerful way to improve user experience and many PageSpeed Insights metrics, like FCP and CLS. It means that all CSS that is critical should be added right to the head tag of the HTML code of a page, instead of the ordinary way including it as a separate file via the link element.

In this way, a browser shouldn’t spend time loading the file, with it parsing and applying CSS rules beginning much earlier, which reduces page loading time.

To reach it you’ve to use a custom theme, and the developer of the theme must implement this feature. You can read more about critical CSS here.

On our website we have page specific bandles, and inline all the CSS code from a bandle, without splitting into critical and not critical. It saves a lot of time. The main thing in this approach is that you must have a clear and simple design. Otherwise, a number of CSS rules will be too big and it’ll stretch the size of an HTML document, which will increase page loading time.

Conclusions

We’ve reviewed all the main items that you must know in order to optimize WordPress speed.

Some of them require programming skills and can’t be done by website owners, those items are for developers, please consider them while creating a new theme.

But some of the items don’t require programming skills at all, in case you’re an owner of a slow website and want to speed up your WordPress, then it’s easy to set up CDN yourself or install a cache plugin. Those items will help you even in case you don’t know how to modify a theme code.

We’ve considered speed optimization, but security is also an important topic. Read 5 Pro Tips to secure WordPress from hacking.

10 Best add-ons for the Advanced Custom Fields plugin

WPLake — Thu, 29 Dec 2022 07:29:34 +0000

There are plenty of add-ons for ACF and it may be difficult for you to navigate by them, that's why we've created our list of the 10 best add-ons that extend the ACF plugin and make ACF even more useful.

Advanced Custom Fields (ACF) plugin is one of the most popular plugins in the WordPress universe. It gives you full control over meta fields and supports many field types. Using the plugin you can add and manage any new characters to any post type with a few clicks. Below you'll find our list of the 10 best ACF add-ons which add new features or integrations and make your experience better.

1. ACF: Better Search

Do you want the build WordPress search to be able to find posts and pages by ACF fields? This addon improves the built-in WordPress search by including meta fields in the request. It works both for the admin area and for the front, which means both editors and users will be able to use this feature.

ACF: Better Search in the WordPress repository

2. ACF Quick Edit Fields

Do you want to be able to amend ACF fields right on the page overview table screen? It's possible with this addon, you can choose which fields must be available for quick editing without hassle.

ACF Quick Edit Fields in the WordPress repository

3. ACF Views

Do you want to display ACF fields on the front quickly, without modifying your theme and reading ACF's docs about the target field's type? This plugin allows to display selected ACF fields (or even Posts) anywhere using shortcodes, HTML markup is created automatically by the plugin. You'll need only to choose the fields to display, copy and paste a shortcode. Everything else will be done by the plugin.

ACF Views in the WordPress repository

4. Image Aspect Ratio Crop Field

Do you want to make sure that the selected image will be displayed with a specific ratio? This addon adds a new field type, that looks and works like the native ACF field, beside the native features it gives a popup using which you can crop any selected image to a specific ratio or size. This field gives you a way to configure the size for a specific ACF image field and be sure, that all images in this field will have the chosen ratio (or size).

Image Aspect Ratio Crop Field in the WordPress repository

5. Table Field

Do you want to have a meta table with flexible columns for editors, and be able to easily display it on the front for users? This addon adds a new field type and makes it possible. Allows easy to create tables and to manage columns.

Table Field in the WordPress repository

6. ACF Options Page Admin

ACF provides the option's page feature, using which you can create a settings page and attach any fields there using the ordinary ACF UI, then access values in an ordinary way. Do you want to create these pages without coding? This addon makes it possible.

ACF Options Page Admin in the WordPress repository

7. Admin Columns

Do you want some ACF fields to be displayed on the page overview table screen as extra columns? This addon gives your full control of all overview table columns and allows you to add new, reorder or remove current columns.

Admin Columns in the WordPress repository

8. ACF Content Analysis for Yoast

Do you use Yoast and want to improve SEO reports by including ACF fields in the analysis? The plugin does it for you without hassle.

ACF Content Analysis For Yoast in the WordPress repository

9. Font Awesome Field

Do you want to display some FontAwesome icons on a page, be able to change the choice later without changing a code, and don't enquire FontAwesome on pages manually? This addon adds a new field type to your ACF, called FontAwesome. You can select any icon and display it like an ordinary ACF field.

Font Awesome Field in the WordPress repository

10. Gravity Forms Add-on

Do you want to be able to select any existing Gravity form in an ACF select field? The addon adds a new ACF field type (Forms) and makes it possible. Now you can 'attach' any Gravity form to your page or any post type, it may be useful if you want to be able to get or display Gravity forms dynamically, depending on a choice.

Gravity Forms Add-on in the WordPress repository

Conclusions

You've reviewed our list of the best ACF add-ons. ACF gives endless opportunities about meta fields, just learn them and you won't have any issues with metadata anymore.

ACF plays nice with WooCommerce, read how to display ACF fields on the WooCommerce shop page.

5 Pro Tips to secure WordPress from hacking

WPLake — Wed, 28 Dec 2022 15:11:34 +0000

Follow these 5 Pro Tips to secure your WordPress installation like Pro. After implementation, you’ll receive a great level of protection, which will be enough for most websites.

Some people feel lazy when hear talking about security and don’t follow very basic instructions (as long won’t hacked). Others become crazy and lock everything that can be locked, making the user experience worse. Let’s fit the gold middle and secure WordPress from the most often threats, but without becoming paranoid. Following these tips will save you from using heavy and expensive security plugins.

Basic for beginners

Here I must say a couple of words about very basic things that are related to security. The next information is only for beginners, feel free to skip it if you feel self-confidence in basic security questions.

So, as a beginner, you must know that most hacks happen not due to vulnerability in code, but due to rough mistakes in using the software.

Passwords

A. Don’t use weak passwords

Any password must contain 16+ random characters, including special characters. Hackers have a list of commonly used phrases and can easily get access to your admin panel, in case your password isn’t a random string. Never, ever use names or words in your password.

B. Don’t share passwords with third party faces

Even with developers. If you need to get some work done by them, create them a separate account, and change the password for the account after they’ve done tasks.

C. Keep password in a safe place

Writing on paper is a bad idea. Storing in online services also may be a bad idea. The best case is using an offline app. There are plenty of programs that allow storing passwords securely. For example, I use KeePassXC.

D. Don’t share passwords via insecure channels

If you need to share a password (for example you’re a developer and have created an account for your client) do it via secure channels or require changing the password after sharing. Slack or messenger channels aren’t fit for this goal.

Unverified themes and plugins

It’s the most common mistake of beginners. They see how many options there are to customize a website and begin to install all plugins and try all themes that can be found. Usually, prefer free or nulled (hacked). Most of these plugins WILL contain viruses or vulnerabilities, it’s a price of accessibility.

If we talk about free plugins, download plugins ONLY from the official WordPress repository (or from the built-in Plugins item in your WordPress admin menu). Also, check the number of active installations (must be bigger than 100) and the last updated date (must be less than a year ago). If we talk about paid Pro plugins, make sure that you’re purchasing on an official website, and that there are independent reviews that confirm the quality of the plugin. (Not on their website, but on other resources).

5 Pro Tips to secure WordPress

1. Change your login url and add a captcha

The brute force of login credentials is the most often practice of hackers. They send hundreds of requests to your website via the login page, and even if you have a strong password it creates extra loading to your website. Plus, if you’re a developer, you can’t guarantee that owner or his editors won’t use weak passwords. This step will be an extra layer that will protect admin accounts.

I use the WPS Hide Login plugin to change the login url. It can be done easily, and furthermore, it won’t change the admin url for authorized users. So it only locks ‘wp-admin’ and ‘wp-login.php’ from unauthorized users, editors and admins must visit a new url to login, and then can use ordinary ‘wp-admin’ to access the admin panel.

I use the Simple Google Captcha plugin to add a captcha to the login page. It works well with the first plugin and adds a captcha via code hooks, which means it will work with any custom login url. The plugin only adds Google Captcha code, but doesn’t sign up a Google account for you. You must sign up and get credentials from Google ReCaptcha to use the plugin.

2. Disable REST API for unauthorized users

REST API allows getting a list of usernames without trouble. Hackers still will need to get a password, but hey, let’s make their life even worse. Plus, even the names (usernames) of editors of your website can be a part of private information, what is the goal to share it with the whole world? REST API is used in WordPress for example by Gutenberg editor (and different plugins), so completely disabling will break the work of a WordPress website.

The golden middle is disabling REST API for unauthorized users, it won’t create any issues for authorized editors and admins, but will protect against leaking usernames to third-party faces.

I use the Disable REST API plugin for this goal, and by default its configured to disable only for unauthorized users, so you can just enable the plugin and don’t make any extra steps.

3. Disable directory browsing

Directory browsing is an insecure feature, that allows seeing a list of files in a request folder via browser, in case the ‘index.php’ file is missing. To find vulnerabilities in your plugins and themes hackers must know their file structure.

WordPress has the index.php stub for all the basic folders, like /wp-content/, /wp-content/plugins/, and /wp-content/themes/, but can't guarantee that every plugin or theme developer does the same. For this goal, you need to make sure that your web server doesn't allow directory browsing.

Try to visit YOUR_DOMAIN/wp-includes/ in your browser and in case you see the 'Not Found' message, it means your server already doesn't allow it, you can skip this item. In case you see a list of files, you must do extra actions to disable directory browsing.

To do this, we need to modify the .htaccess file. I don't recommend editing this file via FTP (like many others suggest), due to the fact that this file is regularly recreated by many plugins (like all cache plugins or others) and your change will be lost after some time. We can add our modification on a permanent basis with the following code snippet, which you can add to your functions.php:

add_filter('mod_rewrite_rules', function ($rules) { 
  return $rules . "\n" . 
  "#Disable directory browsing\n" . 
  "Options -Indexes\n"; 
});

Then visit the Settings-Permalinks page in your admin panel, it’ll force WordPress to recreate the .htaccess file immediately. After, you can visit YOUR_DOMAIN/wp-includes/ again to make sure that now it displays the 404 message (which is good).

4. Deny access to the git folder

Skip this step in case you use plain hosting or your website was uploaded manually without GIT.

Many developers use GIT, which is a wonderful tool. Using GIT on production is also a good idea, but you must disable access to the .git folder via a browser in this case. Otherwise using the .git/HEAD file they'll be able to recreate all a tree of commits and get the source code of your website.

For this goal, you need to lock all /.git/* requests. You can contact your system administrator or hosting provider, or if you've enough skills and your server uses NGINX then you can reach it by adding the following code (add to the NGINX config file of your website):

# deny access to all special files and folders, like .git, .htaccess
location ~ /\. {
  deny all; 
}

Don’t forget to restart NGINX after it.

5. Deny access to the xmlrpc.php file

XML-RPC is an old feature of WordPress, which almost isn’t used nowadays and left just from compatibility with old software reasons. This feature allows interaction with your website directly, without opening in a browser. The bad thing is that hackers can brute force passwords using this feature because even if you’ve changed the login url and added a captcha from the steps above, this feature still gives an option for them to check passwords.

To deny access to the file you can contact your system administrator or hosting provider, or if you’ve enough skills and your server uses NGINX then you can reach it by adding the following code (add to the NGINX config file of your website):

# wordpress xmlrpc 
location /xmlrpc.php { 
  deny all; 
}

Don’t forget to restart NGINX after it.

Conclusions

We’ve reviewed the 5 most important steps to protect your installation from hacking. In fact, steps 3–5 can be done by a system administrator (or hosting provider) only once and will work for all websites on your account. Since you’ve done them, you can be sure that you have a very good level of protection, and you can don’t purchase security plugins, which are often heavy and slow down a website.

In case you’re a WordPress developer, read what must know good WordPress developer.

What must know good WordPress developer?

WPLake — Wed, 28 Dec 2022 11:54:12 +0000

All of us want to be good professionals, regardless of our field. This aim lets us grow and makes us better. I’ll share my list of must-know items, that I’ve learned through the years.

Below you can find my must-know list for WordPress, split by levels, just like in case when you learn a new language.

It’s very useful if you learn WordPress or you can use this list to check yourself and fix gaps in your knowledge of WordPress if there are any.

For each level, I’ve highlighted the main items that you must know. Every item contains a row of topics behind itself, and if you feel that your knowledge is weak when you’re thinking about some item, write down this item in your notes and read more about those items later, dig into that topics to fix gaps.

Level A. Getting familiar

It’s a minimum level for people that want to have a WordPress website. Even in case you’re not a programmer, you must know the very basic things to be able to manage your WordPress website without issues.

What is WordPress
How to manage all types of content (posts, images, taxonomies, users)
What are CPT and PostMeta
The file structure of WordPress (where are unique to specific installation files, where are common)
How to move a WordPress website from one hosting to another

Level B. Beginner

It’s a minimum level for people that want to create WordPress websites. Even if you’re not going to create code, and want to build websites only using ready solutions, you must know these items.

List of most popular plugins and how to use them (like ACF, WooCommerce, SuperCache, All in One Seo, Redirection and others)
How WordPress works (the chain of main hooks and common filters, in which order themes and plugins are loading)
What are Taxonomy and Terms
Default thumbnail sizes, how to customize
Theme’s templates (all built-in template names, what are page templates, how to add them)

Level C1. Medium

These knowledge will allow you to solve different kinds of tasks with WordPress and build fast websites.

Database scheme (all main tables and their main columns, e.g. posts-postmeta, users-usermeta, terms-taxonomy, options)
How to use all options of WP_Query (e.g. with complex filters by meta and taxonomy)
WooCommerce templates and main hooks, how to customize the checkout
Cron tasks (how to create, manage and debug them)
How WP permalinks work behind the scene, custom rewrite rules (e.g. how to support several variants of one url, like product1-vs-product2 and product2-vs-product1)
WP internal cache (to clearly understand what happens when you call ‘get_post’ or ‘get_post_meta’, to be able to reduce resources usage by your code)

Level C2. Extended

At this level, you feel yourself with WordPress just like a fish in a lake, you always know the best way to solve any task and nothing is too complex for you about WordPress.

Multisite mode (what are common and separated here, how do robots.txt and .htaccess act, and what about users)
Transients (what is it, where is it stored, and how to use)
WP CLI (e.g. how to regenerate all thumbnails without plugins)
Weak points of WordPress, how to prevent hacking from them (brute force of login form, xmlrpc.php, parsing user names via REST API and etc)

Conclusions

You’ve read my list of must-know items, and I hope that you’ve found some items interesting for your next learning, and this article will be a small push to improve your knowledge. Do you feel strong? Don’t relax — here I’ve covered only basic topics. Try to dig into tools and topics which you meet every day and you’ll find plenty of new and unknown things. Like with big plugins, each of them is like an ocean, wide and deep. Do you use ACF? Make sure you know all its features, e.g. how to create Gutenberg blocks using the plugin.

Let’s make WEB and the world better — don’t forget to contribute. Help other people to learn and share your features with others. For this goal, you can publish your own WordPress plugin. You can read how to publish your own WordPress plugin.

10 WordPress plugins that you must know in 2023

WPLake — Tue, 27 Dec 2022 12:23:05 +0000

List of plugins that change the game. Great mix of famous and unknown plugins, that will make your life in 2023 easier.

I’m an experienced WordPress developer and would like to share with you plugins that I use in development. These plugins are super powerful, but also easy to use, so can be used both by developers and by website owners without deep technical skills.

The list below contains only free plugins, each item has a short description, my personal comment and a link to download. Enjoy!

1. CPT UI

Provides an interface for registering and managing custom post types and taxonomies for your website.

I always create CPT and taxonomies using this plugin instead of adding via code, as it’s very simple, has all the necessary options and can be changed by clients later.

If you don’t know what is CPT, then you must learn it, as it is one of the main bricks in WordPress. Here is a good article about CPT and PostMeta.

CPT UI in the WordPress repository

2. Advanced Custom Fields (ACF)

Gives you full control of your WordPress edit screens & custom field data. Allows you to quickly and easily add fields to WP edit screens with only the click of a few buttons.

The most famous plugin in the WordPress universe. It’s the best wrapper for WordPress Meta fields that allows you to manage them without hassle.

By default WordPress Posts and Pages (and any other post types) have static set of fields. ACF allows you to add any custom characters to your Pages. ACF supports more than 30 different field types: strings, selects, checkboxes, links, images, maps and more.

Post Meta is the other main brick of WordPress. If you’re a developer, you must know how Meta fields work behind the scene, as ACF is only a wrapper on them. Here is a good article about it.

ACF in the WordPress repository

3. ACF Views

Allows to display selected ACF fields or Posts anywhere using shortcodes, HTML markup is created automatically by the plugin.

By default, ACF allows to add fields via UI, but requires coding to display them. This amazing ACF addon extends ACF and allows to display fields without coding.

This plugin saves a lot of time and efforts, and the main thing for me that his automatic generated markup has a great quality, the same as hand make. The difference that you don’t spend time to create it. As a user you won’t even deal with HTML directly, as plugin generates shortcodes that you paste in target places.

ACF Views in the WordPress repository

4. Admin Menu Groups

Allows to create nested menus in the WordPress admin sidebar navigation and organize all menu items in groups as needed.

WordPress has the great admin UI from the box, but after some time the left (sidebar) menu becomes overloaded, as it reflects all the website data: every Post Type, every plugin has its own menu item there. Navigation becomes a nightmare.

This plugin solves the issue and allows to create groups and attach every menu item to specific group. It means by default only groups are visible, and items are hidden in a submenu of the related group. For example, I always create 3 groups: WordPress, [Project Name], Plugins. The first contains all the built-in WP items, the second all project related things, like theme settings, theme’s Post Types and similar. The last contains plugin’s items.

Admin Menu Groups in the WordPress repository

5. Members

Allows to set permissions to restrict content on your site by providing a simple user interface (UI) for WordPress’ powerful roles and capabilities system.

I always add new roles using this plugin instead of adding via code, as it’s very simple, has all the necessary options and can be changed by clients later.

If you website must support any type of membership then this plugin will make your life much more easier. You can easy see list of roles that available on your website, unlike the code way, that requires you to research by theme files. Also you can change role’s capatibilies with simple checkboxes.

Members in the WordPress repository

6. WP Super Cache

Generates static html files from your dynamic WordPress blog. After a html file is generated your webserver will serve that file instead of processing the comparatively heavier and more expensive WordPress PHP scripts.

One of the best cache plugins that I’ve used ever. Simple, free and very efficient. Easy to setup.

Using some caching plugin in WordPress is a necessary thing to decrease page loading time for your users, it’s also one of the main SEO factors.

WP Super Cache in the WordPress repository

7. Redirection

Allows easily manage 301 redirections, keep track of 404 errors, and generally tidy up any loose ends your site may have. This can help reduce errors and improve your site ranking.

Very useful plugin, whenever you’re changing a page or product slug (permalink), you must create a 301 redirect from the old url to the new one, to make sure that users that request the old url will be redirected to the new one. Also, it’s very important for SEO.

The plugin has a very clear UI, so you can easily create a new redirect rule or review already existing.

Redirection in the WordPress repository

8. Better search and replace

When moving your WordPress site to a new domain or server, you will likely run into a need to run a search/replace on the database for everything to work correctly. The task can be done easily using this plugin.

Every time I have a task to transfer a website, I use this plugin to update urls in a database. It works perfect regardless of amount of data on your website, and it’s the very important moment, as some my clients had large databases (usually shops), and other plugins weren’t able to perform the update.

The plugin has a great UI, clear report and allows to have ‘a dry run’, which allows you to see tables (and records) that will be changed, without performing the action by the fact.

Better Search Replace in the WordPress repository

9. Updraft Plus

Backup your files and database backups into the cloud and restore with a single click.

Business must be sustainable. Unfortunately your hosting vendor can have issues, regardless of his reputation and number of clients. There is no place that is guaranteed from fires or floods. You must not rely on your vendor only and regularly make backups of your website (database and files) to another place, like any Cloud drives.

This plugin allows you to make a setup and forget about this task. The plugin creates automatic backups and uploads them to the selected Cloud by schedule. Important moment for me, that the plugin is able to handle large backups, e.g. 20GB (usually shops have big number of images, that important for them like any other data).

Updraft Plus in the WordPress repository

10. All in One SEO

Improve your WordPress SEO rankings and traffic with comprehensive SEO tools and smart SEO optimizations.

As long your website isn’t a closed resource you must use some SEO plugin, that will make your website SEO friendly. There are so many things, that aren’t presented by default, like structured data, and SEO plugins take care of it.

There are several good and famous SEO plugins, but my personal choice is “All in One SEO”, it gives better results for my clients than others.

All in One SEO in the WordPress repository

Conclusions

I hope you’ve picked up something new from this list for your current and further projects. Share plugins that you use in comments, and we’ll make the article even more helpful.

If you found this article useful, don’t forget to ‘applaud’ and share with friends.

Good luck in the 2023 year.