Autonomía digital y tecnológica

Código e ideas para una internet distribuida

Linkoteca. wordpress


Recently I needed to download some files from a WordPress installation where the client only gave me access to the admin dashboard. Fortunately the All-in-One WP Migration plugin was already installed, so I could take a quick backup of the whole site by downloading the installed plugins, theme and database.

To my surprise downloading the backup from the All-in-One WP Migration plugin only gave me a single compressed migration.wpress file that any unpack tool refused to extract. A little web search brought me to a five year old tool called Wpress-Extractor but the provided binaries for MacOS refused to work because the package was already too old.

So I decided to rewrite this little helpful tool in Node.js to make it cross-platform compatible for Windows, MacOS and Linux.

The importance of wp_localize_script is when you can pass data directly from PHP to JavaScript.

Functions is very easy to handle there are only 3 parameters required :

$handle
(string) (Required) Script handle the data will be attached to.

$object_name
(string) (Required) Name for the JavaScript object. Passed directly, so it should be qualified JS variable. Example: ‘/[a-zA-Z0-9_]+/’.

$l10n
(array) (Required) The data itself. The data can be either a single or multi-dimensional array.

You can use single_template filter hook.

/* Filter the single_template with our custom function*/
add_filter('single_template', 'my_custom_template');

function my_custom_template($single) {

    global $post;

    /* Checks for single template by post type */
    if ( $post->post_type == 'POST TYPE NAME' ) {
        if ( file_exists( PLUGIN_PATH . '/Custom_File.php' ) ) {
            return PLUGIN_PATH . '/Custom_File.php';
        }
    }

    return $single;

}

There are a few steps to create the custom quick edit box and custom column

  1. create a custom meta key (assumed that you have 1 already)
  2. add custom admin column title and data (assumed that you want to shows the custom meta key in the column, if not, you may also modify a bit of the logic to accomplish the same effect because the principal is the same)
  3. add custom quick edit box
  4. add save logic
  5. load script to modify original inline-edit-post function in order to support custom meta value
  6. prepare the script file

I’ve just had a nice experience improving and modernizing a large JavaScript codebase in a WordPress plugin. The original code was written in an old-fashioned way with jQuery in a single large file. Using modern EcmaScript and tools like Webpack, I was able to split it into modules and improve the code structure. The new code is much more readable and maintainable, and of course, fewer bugs. In this tutorial, I’ll show you how I did that.

The filter for modifying, removing or adding columns to post list in WordPress admin panel is manage_{$post_type}_posts_columns.

Which hook you need to use for controlling the output of the column content depends on whether or not your post type is set to be hierarchical or not.

Any non-hierarchical post types, including WordPress’ built-in post type ‘post‘, use the hook name manage_{$post_type}_custom_column. Any hierarchical post types, including WordPress’ built-in post type ‘page‘, use the hook name manage_pages_custom_column (note: no injection of post type name in the hook name).

In light of a recent German court case, which fined a website owner for violating the GDPR by using Google-hosted webfonts, WordPress.org’s themes team is updating its recommendations for hosting webfonts. Most theme authors have been enqueuing Google Fonts from the Google CDN for better performance, but this method exposes visitors’ IP addresses.

“The themes team strongly encourages the theme authors to update their themes,” Themes Team representative @benachi said in a recent announcement. “We recommend updating by switching to locally hosted webfonts. Luckily Google Fonts can be downloaded and bundled in a theme. Bundled font files allow users to host webfonts locally and comply with GDPR.”

So how do you set cookies in WordPress? With core constants:

COOKIEPATH — Server path in which the cookie will be available on.
COOKIE_DOMAIN — The (sub)domain that the cookie is available to.

Setting cookies in WordPress, especially the expiration is a cinch using one of the core time constants, available since v3.5:

MINUTE_IN_SECONDS = 60 seconds
HOUR_IN_SECONDS = 3,600 seconds
DAY_IN_SECONDS = 86,400 seconds
WEEK_IN_SECONDS = 604,800 seconds
MONTH_IN_SECONDS = 2,629,746 seconds
YEAR_IN_SECONDS = 31,556,952 seconds

Don’t forget to add the current timestamp to one of these constants, for example:

// 5 minutes into the future
$five_minutes = current_time( ‘timestamp’ ) + ( MINUTE_IN_SECONDS * 5 );

In the first parts we focus on the basics. We set up a development environment with running compilation of our code. And the basics of how to register a block and the necessary PHP parts of it as well. We’ll learn about the huge library of components and methods available to us from WordPress Gutenberg.

Moving on we’ll learn about how to add sections and settings for our block in the editor sidebar (Inspector) as well as customizing the toolbar. Along the way we’ll touch a lot of different input types and how to use Gutenberg’s component for these. And of course we’ll learn how to save, update and output the saved information to our block – and how that works behind the scenes.

At the end we’ll look at more advanced things like dynamic blocks and how to use PHP to render the block output. And finally how to make post queries inside the editor – allowing the user to select a post from a list for render.

Extensibility is key, and we can’t build the next generation of the WordPress Editor without making it extensible. What does “making it extensible” mean? Does this mean providing hooks and filters in JavaScript the same way we do in PHP? Does this mean allowing plugins to extend and tweak any UI component used by Gutenberg? Does this mean adding filters to the REST API? Does this mean Giving access to an Editor object to manipulate the editor’s content?

There’s no clear answer to all these questions. Extensibility is a very difficult problem and unless you build it with real use-cases in mind, you’re more likely to get it wrong. (and being stuck with it for a long time).

The Customizer Export/Import plugin allows you to export or import your WordPress customizer settings from directly within the customizer interface! If your theme makes use of the WordPress customizer for its settings, this plugin is for you!

Decisions not Options

When making decisions, these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option, this ultimately leads to frustration. As developers, we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions, and avoid putting the weight of technical choices on our end users.

The WordPress Foundation owns and oversees the trademarks for the WordPress and WordCamp names and logos. We have developed this trademark usage policy with the following goals in mind:

We’d like to make it easy for anyone to use the WordPress or WordCamp name or logo for community-oriented efforts that help spread and improve WordPress.
We’d like to make it clear how WordPress-related businesses and projects can (and cannot) use the WordPress or WordCamp name and logo.
We’d like to make it hard for anyone to use the WordPress or WordCamp name and logo to unfairly profit from, trick or confuse people who are looking for official WordPress or WordCamp resources.

WP Migrate DB exports your database as a MySQL data dump (much like phpMyAdmin), does a find and replace on URLs and file paths, handles serialized data, then allows you to save it to your computer as an SQL file.

Pantallazo del theme Susty WP para WordPress

Delivering WordPress in 7KB 6KB*

This website aims to act as a guide to making WordPress websites more sustainable, and to serve as a practical example of how we can tune our websites and reduce their carbon footprint. The homepage of this website is delivered to your browser with just 6KB of data transfer. This is achieved by its theme, plugins and configuration. As of 2016, the average website data transfer was 2.3MB, making it 393 times bigger than this website!

…the ability to create and use custom taxonomies has been around since 2007. We didn’t get all the cool functions added until 2.8 though.

However, one thing we’ve had since 2.3 was the ability to create taxonomies for any object type, not just posts. In WordPress, there are several object types:

Posts
Users
Comments
Links

So, you can technically create a taxonomy for any object type. Most of WordPress core support is for posts, but the API is extremely well thought out and can handle the other object types with minimal code effort.

This tutorial will focus on registering and using a taxonomy on the user object type. It will not be a 100% solution for everything you can do with a custom user taxonomy. Consider this an extremely rough draft of what’s possible.

At GPLDL we felt that releasing «Premium WordPress Plugins» and «Premium WordPress Themes» only to people who purchase support licenses constrains the dissemination of GPL-licensed software. So we decided to break up these expensive packages by providing the exact code available from the developers for download at GPLDL.

That’s why we set up GPLDL as a club – legally sharing hundreds of Premium GPL-licensed WordPress items with our members. That gives all of our members access to the code they actually need by removing the developer’s support they are otherwise forced to pay for.

The GPL licence, which is the foundation of WordPress and all plugins in the WordPress repository, is a great license, no doubt. It has permitted WordPress to become what it is today, and have such a wonderful community form around it.

I’m lately seeing a small surge in the number of people who are taking advantage of the GPL in what many consider an unethical way. I’m talking about the WordPress plugin stores that are cropping up and selling plugins developed by other people.

Clearly a project the size of WordPress needs some strong leadership and a clear roadmap. However, when that roadmap starts to be clouded by outside factors such as financial pressure to compete with the market, decisions aren’t made in the best interest of everyone. Don’t forget that whatever is implemented in WordPress.org is being built for WordPress.com (one of the main money-making arms of Automattic) and no doubt their biggest concern when considering losing customers to competitors. Gutenberg is a clear attempt to attract new users to the platform.

The major part of backwards compatibility is not breaking things, or doing everything possible to avoid it. Gutenberg simply will break sites. This won’t be white screening, or breaking appearance on the frontend, but as soon as a site is updated to 5.0, a user will have a broken experience the next time they edit a post, if the site relies on custom meta boxes.

The percentage number of sites on the web that are powered by WordPress is often touted and this number will be made up of a variety of different types of sites and site owners. A large number will be developers, freelancers and agencies who have built sites in the past, manage sites currently, and build every new site with WordPress. From experience, these developers typically don’t use page builder plugins but a combination of custom fields and meta boxes to give clients the ability to add all the data needed to be displayed on the site in a controlled and prescribed style.

These people will need to prepare for 5.0 (more on that later) to make sure their clients aren’t affected by Gutenberg.

Out of all the modern frontend frameworks, React was always the first choice for Gutenberg, even after some token debate, and weathering the storm of patent clauses. But adding a shiny new framework to a critical piece of WordPress core is highly problematic and we’ve seen it before. WordPress 3.5 was released with a new media manager, built with Backbone and landed without documentation, no clear extensibility model, and a steep learning curve for core contributors and developers with media-related plugins.

Gutenberg has the potential to go the same way, but undoubtedly it will reduce the amount of people able to contribute to it, without learning React deeply. It also places a burden on plugin developers (in a short timescale) to learn, adapt, and get their plugins ready.

Of course this is possible for the big guys like WooCommerce (Automattic owned, large team) and Advanced Custom Fields (independant small team, huge user base), but this will affect any plugin which registers a custom post type, or meta boxes. Most developers simply won’t have the time, inclination or skills to make them compatible with Gutenberg. We will likely see a lot of plugins broken which just won’t get fixed. That will have a detrimental effect on user experience and the WordPress ecosystem in general.

Core should leave Gutenberg as a feature plugin for longer. The timeline is just too short for people to prepare. It is too great a change to be rushed. I think the decision to be merged should be rethought and only merged when a certain level of plugin adoption by users is reached.