Mircian

When dealing with highly customised WordPress websites you often end up with a lot of custom fields. Especially if using a manager like  Advanced Custom Fields, it could be tedious to manually copy all the fields.

Why not push the whole database?

That’s a very good solution if you have the staging and live websites in sync. In my experience though, especially when developing websites ( code ), you end up building pages locally or on staging and duplicating them is difficult.

Having a repeater field in ACF or a Flexible content field could mean lots of different text boxes to manage.

What’s the solution?

I wrote a small plugin which does a simple job:

• Adds a textarea field with all your custom fields in JSON format.
• Below that textarea you have a checkbox which when checked will use the value in the JSON to update the custom fields.

A simple usage example is:

1. Install the plugin on both websites ( or just on one if you want to copy paste among pages/posts in the same website )
2. Copy-paste the values and update.

That’s it!

Please note: the plugin is not really tested so use at your own risk, I will try to improve it as time allows it.

If you want to contribute, the GitHub repository is here.

You can download the current version here.

Photo by Paulius Dragunas on Unsplash

In the past months, I’ve been working on a plugin which creates a custom screen in the WordPress admin. It’s a custom functionality entirely but I’ve tried using as much WordPress functions to keep the right feel in the interface.

One of the forms in this page has an image uploader which uses wp.media. I was faced with this challenge: change the filename of the images uploaded on that page.

I looked around the code and inspected the upload requests and this is the solution I came up with.

1. Mark in the media uploader

The first step was to make sure this won’t affect other media uploaders in the website. For that I used the hook current_screen in which I checked on what page we are.

Because this hook is called early on in the admin I added a filter inside of it for plupload_default_params. Using this filter I added a custom parameter which will be sent each time an image is uploaded on that page.

2. Change the filename

The next part was changing the filename. In my case I just wanted to make sure the filename is completely random ( for which I have a separate function ).

I found the most straight-forward way of doing this is using the sanitize_file_name filter. This also ensures that the filename is unique as it is called inside the wp_unique_filename function.

So inside the filter I added a check for the custom parameter added in step one and replaced the name.

The code

In order to make things easier to understand I stripped down the functions mentioned in the article and created a custom class.

Pretty easy in the end but hopefully will save someone time looking into a way of doing this. I am aware this might not be the best solution but it does a good job for what I wanted.

Photo by Samuel Zeller on Unsplash

In the very popular Enfold theme, the author created an easy to use layout builder called Avia Advanced Layout Builder. Because it’s so popular, I am constantly encounter it in the projects I work on for clients.

Most times I work on adding a new feature I prefer extending the builder. From a plugin or a child theme, this allows users to keep the theme up to date.

The Enfold custom element

In order to keep things simple we’re going to create a custom text element. And of course, I’m using the existing “Text block” element as reference & starting point.

Adding the new element is an easy 3-step process:

1. Copy the existing class file to your child theme ( or plugin ), in this case /wp-content/themes/enfold/config-templatebuilder/avia-shortcodes/textblock.php. Don’t forget to include it.
2. Change the name of the class if you don’t want to override the existing element.
   Before:

   class avia_sc_text extends aviaShortcodeTemplate {

   After:

   class custom_text_element extends aviaShortcodeTemplate {

3. Customize by changing the values in the function “shortcode_insert_button”. You’ll notice a few properties:

   $this->config['name']         = __('Text Block', 'avia_framework' );
   $this->config['tab']         = __('Content Elements', 'avia_framework' );
   $this->config['icon']        = AviaBuilder::$path['imagesURL']."sc-text_block.png";
   $this->config['order']       = 100;
   $this->config['target']          = 'avia-target-insert';
   $this->config['shortcode']        = 'av_textblock';
   $this->config['tinyMCE']       = array('disable' => true);
   $this->config['tooltip']       = __('Creates a simple text block', 'avia_framework' );
   $this->config['preview']      = "large";

Customizing your new component

From the properties above I think you should focus on a few:

• “name” – I think it’s obvious, this is the name of the block which is displayed in the builder
• “tab” – this is the tab of elements, by default you have 3 tabs in the builder to group similar elements. You can even create a new tab.
• “icon” – obvious, you can see they also have a nice helper function so you can check out the path at /wp-content/themes/enfold/config-templatebuilder/avia-template-builder/images for other icons available, or use custom one from your child theme/plugin.
• “order” – a number used to order the elements, you can look at the other elements to figure out where to place it. It works similarly to the WordPress custom menu item order.
• “shortcode” – the most important option which I highly encourage you to change if you don’t want to override an existing element. Use a prefix to make sure you don’t override an existing shortcode.
• “tooltip” – this is the text displayed when you hover over the element in the builder.

Adding new options

The reason you created a new element is to add custom options, right? This can be done from the “popup_elements” function which contains an array of arrays defining each field.

Listing all the available fields and their options would require a separate, long, article. I usually just go through other components and look at what fields are available and copy them over to my custom element.

Using the new options

The good news is that once you define a new element in this array it will automatically be added to the shortcode. This means that if you add, for example, a new text input for a caption, or a subtitle, you can use it directly. Take this code as example:

array(
   'name'            => esc_html__( 'Subtitle', 'm_text' ),
   'id'              => 'subtitle',
   'container_class' => 'avia-element-fullwidth',
   'std'             => esc_html__( 'What are you thinking?', 'm_text' ),
   'type'            => 'input',
)

This will create a new property, “subtitle”, in the generated shortcode, which means you can go ahead in the “shortcode_handler” function.

You can use it by calling:

$atts['subtitle'];

Use that in the generated html. That’s all!

A few tips

There are some special elements used for layouts – you’ll notice this:

array(
      "type"     => "tab_container", 'nodescription' => true
   ),
   
array(
      "type"     => "tab",
      "name"  => __("Content" , 'avia_framework'),
      'nodescription' => true
   ),

Very useful to have the elements clearly separated.

Another one I wanted to point out is the “linkpicker”. If you’re familiar with ACF, it works similarly to the “relationship” field. The tabs are also used similarly to ACF as you just list them and when a new one is added it creates a new tab.

Photo by Ant Rozetsky on Unsplash

Luckily, I recently had to find a solution to sync data between 2 WordPress websites. I say luckily because it gave me the chance to use WP REST API’s custom endpoints.

The data to be synced was not very complex fortunately, mostly basic post data. In this particular case I had to sync 2 custom post types, actually some custom fields, the post status and the permalink.

Adding custom endpoints

I must admit, for me, this as clear as it can be. Especially in a WordPress environment, the structure for adding a custom endpoint is very straight-forward.

This is something similar to what I used:

register_rest_route( 'm_api/v1', '/custom', array(
   'methods'  => 'POST',
   'callback' => array( $this, 'handle_api_request' ), // In a class
) );

What this does is:

1. It adds a new route in the form of: http://your-website.com/wp-json/m_api/v1/custom – of course, you can use whichever structure you wish.
2. It only passes through POST requests unless otherwise specified.
3. And also has support for custom variables in the url ( ids and such ) – more on this in the documentation.

In this case – being a “closed circuit” situation, I used a secret key to sign all requests and make sure nobody gets in the middle. Along with HTTPS and considering no secret data was being sent, it was enough. You might want to use different types of authentication.

I’m not going to share the rest of the plugin because this is the only relevant part to this subject. What I am going to share is how I handled things from the other plugin ( on the other website ).

Connecting to the your new endpoint

In the “client” plugin, which I used to initiate the updates, I used a very simple structure.

First, I hooked on the save_post action to listen for a change in the post. After I had the data collected and validated from the post, I used this function to make the call:

public static function make_request( $data ) {
   if ( ! empty( $data ) ) {
      $data['token'] = self::get_token( $data );
      wp_remote_post( self::API_URL, array(
         'body' => $data,
      ) );
   }
}

As mentioned above, I use a secret key to sign the data and use the very nice function wp_remote_post to send the data to the other website.

On the other website, the endpoint takes over and passes the data to the assigned function to process it.

I find this structure very easy to set up with 2 small plugins: safe & simple.