WP Clips

Update-Safe Code Customizing for WordPress

Jon Barratt

Adding Custom Code in WordPress Multisite

·Written by

When it comes to code customizing WordPress themes and plugins in multisite, adding custom code can be a bit of a challenge. Where do you put your PHP, JS and CSS code? How do you protect it from updates? How do you target this site but not that site, or that site but not this site, or perhaps all sites? Well, we believe WP Clips has the answer!

Version 3 of WP Clips Multisite provides an ideal solution for developers when it comes to custom coding across WordPress networks. On installing and activating the plugin, sets of editable custom files (called Clips) are added to the network and to each of the individual blogs or sites. And if a new site is added in the future, a new set of custom files is automatically installed.

What specifically is a Clip?

A Clip is a plugin-activated folder of custom files which can be used to safely customize WordPress themes and plugins. The network’s Core Clip contains a single functions file (PHP) while each of the site’s Custom Clips contain functions (PHP), script (JS) and stylesheet (CSS) files. Custom code is added directly to the files, and when present, the files are included or enqueued via the plugin immediately following setup of the theme.

How are Clips and custom files organised in multisite?

The diagram below illustrates the Clip directory and file architecture for a multisite installation, where two sites are in use. If we were to add further sites, more Clips and file sets would be added similar to the primary and secondary sites.

The WP Clips Manager settings page is shown on the left and the corresponding architecture is to the right. Here, settings are being accessed from the primary site. However, if we were to access settings from a different site, it’s respective blog name, ID and Clips would be shown.

Note that the Custom Clip for the primary site is shown as active. However, if it were set to ‘unclip’ (—) followed by a rebuild of the Clips directory, the Clip would be moved to the /site-1/unclipped folder and temporarily disabled.

Details in regard to the Precoded directory and Precoded Clips can be found at https://wpclips.net/precoded-clips/

What are the benefits of using WP Clips?

  • Customize child themes, parent themes and plugins
  • Custom code is protected from all theme and plugin updates
  • Declare theme and plugin dependencies to prevent errors on site changes
  • Lightweight, portable and database independent
  • Plays well with caching and minifying tools
  • Contains a translation file (update to include your customizations)
  • Simple to back-up, copy and transfer

More information can be found at the WP Clips website https://wpclips.net

How can you get started with WP Clips Multisite?

Simple. Just go to https://wpclips.net/installing, download and install WP Clips Multisite v3. And get cracking adding custom code to your files!

Also be sure to check out the WP Clips website, FAQ section and Multisite page for more information.

Here are just a couple of tips to get started.

Add any theme or plugin dependencies to your functions file header tags as per the protocols outlined in https://wpclips.net/customizing/. This will safeguard against site errors should the theme be changed or a plugin be deactivated. It’s also a good idea to delete any unused (dormant) custom files to prevent them being enqueued and adding to page load. If you prefer to keep them in the directory, simply renaming the file (e.g. custom-script-dormant.js) will have the same effect.

And that’s about it! Wishing you happy, stress-free customizing on WordPress Multisite.

WP Clips V3 Released!

·Written by

That’s right WordPress fans! WP Clips has been revived! The popular WP code customization plugin has been redesigned and relaunched with some major developments in WP Clips Version 3.

Here is a list of important developments which now make WP Clips Version 3 the best custom code repository for WordPress developers:

  1. Clips have moved out of home — The most common complaint with former versions of the plugin has been the inclusion of custom and precoded Clips within the plugin folder itself. This meant plugin updates needed to be conducted manually and custom code was at risk of accidental deletion by a novice developer.

    This has all changed with Version 3.

    The new release builds a new Clips directory in the wp-content root folder, securely protecting all Clips and custom code from plugin updates. Even if the plugin is removed, the Clip directory will remain until it is manually deleted, and will reactive once plugin is reinstalled.

  2. Plugin non-essentials are now squatting with Precoded Clips — Previous versions of the plugin included file/folder version upgraders and functions for the custom Clip editor. This simply added bulk to the plugin. So, we’ve separated these functions to precoded Clips which can be installed via the plugin’s WP Clips Manager. For example, below are two precoded Clips which may be helpful with your version 3 upgrade:

    WP Clips v3 File Upgrader — version 3 upgrades to files and folders.
    WP Clips v3 Clips Editor — enables Clip editing via WP Plugins Editor.

  3. Improved architecture and Clip naming conventions — The new Clips directory brings about adjustments to filenames, directory structure and hierarchy. In single site installations, the core, custom and precoded Clip folders reside in the root Clips directory as they did in the plugins folder, however the unclipped folder has now been moved from the precoded directory to the root. In multisite installations, new network and site (blog) directories have been introduced to the Clips directory root, each with their precoded and unclipped folders. The new structures are shown below:

    Single Site
    /wp-content/clips/clip-core/ {core functions file}
    /wp-content/clips/clip-custom/ {custom functions, script, style files}
    /wp-content/clips/precoded/ {precoded Clip folders}
    /wp-content/clips/unclipped/ {disabled Clip folders}

    Multisite
    /wp-content/clips/network/clip-core/ {core functions file}
    /wp-content/clips/site-{blog id}/clip-custom/ {custom functions, script, style files}
    /wp-content/clips/site-{blog id}/precoded/ {precoded Clip folders}
    /wp-content/clips/site-{blog id}/unclipped/ {disabled Clip folders}

    In addition to architecture, some minor filename changes have been made for better logic and readability. The custom-jquery.js file and references have been renamed custom-script.js, and filename underscores have been replaced by dashes for more reliable web accessibility.

  4. Vitals file replaced by Clip headers — Previous plugin versions supported an independent vitals.php file for declaring theme and plugin dependencies for custom and precoded Clips. Support for this file is now deprecated and replaced by file headers added to the main functions file. Note that if updating to the new version, custom Clip vitals declarations (if any) must be transferred to the custom-functions.php file. Click here to read more.
  5. Headers add display data and links for precoded Clips — Custom and precoded Clips can now include a variety of readable headers for greater functionality and user support. The custom Clip can be renamed and include theme and plugin dependencies, while precoded Clips can further include version numbers, information links, author details, and network requirements. Click here to read more.

    6. Download WP Clips V3

    Upgrading to V3

    If you’re an existing user of WP Clips or WP Clips Multisite, updating is easy! Visit the Updating or Upgrading page on the WP Clips website, download the new plugin version and follow the instructions provided.

WP Clips V2 Released!

·Written by

It’s been nearly 12 months since WP Clips was released, and during that time the plugin has undergone several evolutions including the addition of Precoded Clip capability with WP Clips Plus, multisite compatibility with WP Clips Multisite, and the introduction of ClipBank™ as a helpful resource for sharing and downloading Precoded Clips.

The uptake of the product has grown dramatically in the last 3 – 6 months and so has the feedback. Mostly complimentary, but some critical. I always welcome critical feedback because it offers an opportunity for evolution and improvement. And so, I proudly announce the release of WP Clips Version 2.

Here are some great new developments in this handy customizing plugin:

  1. The first thing you’ll notice is that WP Clips Plus has now been deleted. Precoded Clips capability is now built into the WP Clips plugin by default.

    The decision to merge the two products was based on feedback from new users who would download the basic plugin and then immediately upgrade to Plus to enable Precoded Clips. Great for download stats but not so good for frown lines. So, double-install frustrations be gone!

  2. The custom Clip now has a vitals.php file for declaring compatible themes and required plugins. Similar to precoded Clips, conditions can be set to dictate whether the custom Clip should or should not be enabled.

    This is a helpful feature to prevent site irregularities and errors when switching between themes or deactivating dependent plugins. It’s a development inspired by the Great Update Debate for Genesis child themes, and more particularly the assertion that customizer plugins can be risky for the above reasons. Problem solved.

  3. A new addition to WP Clips is the core Clip, which includes a single core-functions.php file. It’s the equivalent of a core-functionality plugin and is used specifically for adding WordPress core functions. Like the custom Clip, the core Clip can be unclipped (i.e. disabled), but otherwise remains active irrespective of themes, plugins or any other conditions.
  4. WP Clips Multisite continues with no major changes other than the network Clip is now the core Clip.
  5. Many general code improvements have been made to ensure a leaner, faster and more secure plugin. Precoded Clip update prompts have also been deemed unnecessary and now been removed.

Download WP Clips V2

Updating or Upgrading to V2

If you’re an existing user of WP Clips, WP Clips Plus or WP Clips Multisite, updating is easy! All new file additions and filename changes are automatically implemented on install of the new plugin (providing you are logged into admin).

Visit the Updating or Upgrading page on the WP Clips website, download the plugin and follow the instructions provided.

Note: WP Clips Plus users should upgrade to WP Clips (strange as it sounds).

 

You don’t NEED to update your Genesis child theme … but SHOULD you?

·Written by

It’s the most fiercely debated topic on Genesis forums – Should you or shouldn’t you update Genesis child themes? And, as importantly, how does this affect StudioPress best-practice of applying customisations directly to child themes.

Former StudioPress support rep Andrea Whitmer said it best in her excellent article,  “No, You Don’t Need to Update Your Genesis Child Theme”  –”Want to start a debate that will continue until all parties are too exhausted to keep going? Ask about methods or reasons for updating Genesis child themes – Days later, when you crawl out of the fray – bruised, broken, and determined never to ask a question again – you may still be looking for a recommendation.”

Yep. That about sums it up. Andrea’s article sets the background for this fiery debate and offers a well-articulated case for saying NO to Genesis child theme updates.

In this article, I present a case for saying YES to child theme updates. And at the risk of a few more bruises, I’ll illustrate why I believe the current best-practice is becoming outdated, impractical, potentially damaging, and should be reviewed.

Important note! This article assumes basic levels of code customising. Significant deviation from the original theme, either stylistically or functionally, should really qualify as a new theme in its own right. Hence, this debate does not apply.

Progress in the update debate.

Thankfully, the debate is evolving. StudioPress fundamentalists have shifted from “Genesis child themes don’t get updated” to “Genesis child themes don’t NEED to be updated”. A necessary step given that a quick scan of StudioPress child themes reveals that out of 95 child themes (as of October 2016), 76 have received updates with nearly half occurring this year.

This statistic is likely to climb. Why? The answer is as simple as it is compelling – the most innovative framework attracts the most innovative developers.

Genesis child themes aren’t limited to StudioPress. An expanding community of creative, forward-thinking theme developers are continually pushing the Genesis framework to new and exciting levels. As a result, many child themes are no longer just aesthetic skins, they’ve become virtual theme extensions, including more complex functions, scripts and even built-in support for external plugins such as WooCommerce.

StudioPress founder Brian Gardner recently confirmed in an interview with Matt Mullenweg that StudioPress itself “has put WooCommerce compatibility on the roadmap for its themes” – further evidence the Genesis child theme landscape is changing.

  1. We’re seeing an increase in quality third-party theme developers creating more child themes for the Genesis framework.
  2. StudioPress, while expanding its own child theme vision, recognises this external asset and is adding more third-party child themes to its store.
  3. Many of these child themes are more functionally complex, and so have a greater susceptibility to deprecated code.
  4. Many of these child themes include built-in support for third-party plugins and so are  susceptible to updates in supported plugins.
  5. Developers are keen to ensure their themes are current by removing deprecated code, including new theme support features, and maintaining compatibility with supported plugins.

Add to this the ever-increasing speed at which web technologies, protocols and standards are advancing, plus the frequent addition of theme support features to comply, and I believe it’s a mistake to bury our heads in the sand with respect to child theme updates.

After all, as a user I want the latest version, and as a developer, I want my users to be equipped with the latest version. Andrea quite rightly claims, Genesis child themes, in most, don’t need to be updated. But, my argument is not whether you need to, it’s whether you should. And if there is an update available, why you wouldn’t?

So, why wouldn’t you update your child theme?

Those that don’t, and those that won’t, have two primary reasons –

  1. The belief that only the parent theme receives updates, not the child theme.
  2. Best-practice is to customise the child theme directly, and so updates will overwrite customisations.

Only the parent theme receives updates, not the child theme.

This line is usually followed by, “That’s the point!”. However, I’m not sure it IS the point given that Genesis child themes DO get updated and the trend is sure to increase.

It’s also important to acknowledge the difference between a standard parent theme and a framework. Adopting the StudioPress ‘car’ analogy, the framework is the chassis and the child theme is the ‘cherry red’ paintwork. Both are necessary. However, a standard parent theme stands alone. The child theme is optional and created only for ‘customising’. In the context of this debate, there is a profound difference.

Best-practice is to customise the child theme directly.

This is really at the core of the entire update debate. On a near-weekly basis, we witness the Genesis newbie querying where to place customisations so they’re not overwritten by child theme updates, only to be belted with an array of conflicting responses and best-practice recommendations which, in my mind, no longer make any practical sense.

It’s an escalating issue. Why? Because Genesis users, new and old, can quite clearly see that Genesis child themes are being updated and an undeniable conflict is presented if a user wants the freedom to apply updates while subscribing to best-practice.

Updating is a good habit.

If users are encouraged to update WordPress, to update the framework and plugins, why exclude child themes? This seems genuinely illogical to me. Not only does it blur the lines on good routine, but it places a site at greater risk of faltering due to incompatibility with its up-to-date components. Andrea’s article refers to a fear and bad habits contagion in the context of “freaking out” about updates. However, I’m more likely to “freak out” over ‘not updating’ than I am having the most compatible, most secure, most up-to-date version of a child theme.

The Danger.

I believe that in the long-term, clutching onto current best-practice may actually damage Genesis framework’s well-earned market position.

Business models thrive on innovation and harmony, and wither on uncertainty and dissension. In fact, it’s fair to say that innovation and harmony have been two cornerstones in the framework’s success! However, there is now a simmering level of frustration creeping into the Genesis community in regard to the update issue. And it’s growing –

  1. Genesis newbies are getting caught in the crossfire of the best-practice debate. And their confusion is warranted given they’re told Genesis child themes don’t get updated when clearly they do.
  2. Genesis veterans are clinging onto best-practice methods while becoming increasingly cognisant of the changing landscape in child themes.
  3. Genesis theme developers, who should be encouraged to stretch the boundaries and push the framework’s capacity forward, may be curbing their creativity, either consciously or subconsciously, over best-practice concerns and the fear that ‘something’ in their theme may, at some time, require updating.

These factors create a feeding ground for uncertainty and disagreement, and result in retardation, at some level, of an otherwise flourishing business model.

The knuckle-biting solution.

I believe most Genesis users would apply child theme updates if it was simple and safe to do so. Therefore, the solution is obvious.

Isolate customisations from the theme folder, making them update-safe.

There. I said it. It flies in the face of current best-practice. But, there won’t be any plagues, no floods or fires, we won’t descend into darkness. All we’ve done is acknowledged that the child theme landscape is changing and either discarded or adapted best-practice accordingly.

What are the negatives?

I’ve heard several reasons why custom code should not be separated from the theme folder, ranging in extremes from overridden code costing a site a few hundredths of a second in loading time, to endangering a client’s business! However, the most popular argument is that separate files or plugins can be dangerous.

This assumes that if an active theme is substituted for another, theme-specific customisations may see the site go haywire and the owner promptly committed to a mad-house. I believe this argument is lost with quality developers, however. Good code or a good plugin should include safety measures to block a code’s engagement if a related theme is not active. So, the result should be no different to substituting any other theme.

There is a risk, however, that a plugin is neglected by its developer and becomes obsolete, or that the plugin will be accidentally deleted by another admin. Both risks are negated by writing custom code direct to accessible plugin files rather than a database, and installing these files as a must-use (mu-) plugin to prevent deletion via WordPress admin. This can be achieved manually or by installing a database-independent plugin such as WP Clips.

Important note! Page builders and intuitive customiser plugins such as Beaver Builder, Genesis Extender and Design Palette Pro, are also designed for non-coders and, therefore, not relevant to this discussion.

What are the benefits?

Simple. Customisations are safe from child theme updates. In addition, they are easy to find, easy to back-up, easy to copy and easy to transfer.

There is also an advantage when it comes to multisite. Separate files allow a user to customise each individual site using the one Genesis child theme. This is not possible with current best-practice which would require multiple copies of the theme, each with its own customisations.

To summarise.

I’ve mentioned Andrea Whitmer a few times in this article, so I’d first like to say that I have great respect for Andrea, her contributions to StudioPress, and her educated opinion in regard to this issue. I just have an alternative point of view.

In a nutshell, these are my points.

  1. The Genesis child theme landscape is changing. We’re seeing more child theme developers and more child themes with greater functionality and dependence on third-party peripherals.
  2. StudioPress recognises this asset and in addition to introducing a new league of child themes in its own right, it’s embracing more third-party products and involvement.
  3. Greater complexity and dependencies in child themes, plus an accelerating advancement in web technologies, means a greater susceptibility to external code changes and the need to release updates.
  4. Updates are already occurring. As a result, there is a perceived conflict when arguing that child themes don’t get updated (or don’t need to be updated) when there is an obvious progression in versions. This is causing a level of contradiction and uncertainty in the Genesis community, particularly with new users.
  5. Continuing uncertainty and dissension could have a negative effect on the Genesis brand.
  6. Updating is a good habit. And in general, users want the latest version, and developers want their users to be equipped with the latest version.
  7. Current best-practice is a limiting methodology. It prevents users from updating their child themes or, at the very least, makes it problematic to do so.
  8. The issue is easily resolved by changing or relaxing best-practice to endorse the isolation of code customisations from the child theme folder, and hence the debate of whether child themes should or shouldn’t be updated is annulled. The user is free to choose.

Who am I to say?

Two and a half years ago, I developed the Envy e-commerce Genesis themes. Sometime after that, I developed WP Clips to allow my clients to add update-safe theme customisations because major updates in WooCommerce occasionally required updates to my themes. My clients quickly embraced the product, so I elected to make it available to all Genesis users at http://wpclips.net.

What’s my personal process?

As you’d expect, I use WP Clips to create a custom Clip of PHP, JS and CSS files. Custom code is added to these files and any modified templates, scripts and images are added to the same custom Clip folder. I often install a few precoded Clips to serve up my common customisations, one of which is to combine and minify all CSS and JS files within the plugin.

After completion, I turn the custom Clip into a precoded Clip and specify the theme and plugins required for the Clip to activate, then transfer the plugin files to a must-use (mu-) plugin to prevent accidental deletion. And that’s it! No fuss. Easily backed-up. Easily transferrable. Database independent. Safe and secure. Quite honestly, an extremely simple solution to what I see as an unnecessary problem.

A final word.

It could easily be said that I’m perpetuating the problem by adding fuel to the debate. And that perhaps I should simply accept that ‘this is how it is’, retreat quietly into the night, and it all goes away.

However, I am quite certain it won’t go away. Users will continue raising the issue because there is a conflict. There is a problem. And avoiding discussion, even fierce discussion, is not how progress is made. It’s not how new truths emerge and it’s not how better practices are formed.

So, this debate is absolutely necessary for the good of the framework and its community. I’m not saying that mine is the right solution and I’m not saying Andrea’s is the wrong one. I’m saying it’s in everyone’s interest to have their say. Because, eventually we may “crawl out of the fray – bruised and broken”, but there will be an outcome. A decision. And if the decision is the right one, the “question will never be asked again”.

Add or Customize / Replace JS and CSS Files with WP Clips

·Written by

The custom Clip installed with WP Clips contains three custom files for adding functions, styles and jQuery. But, what if you want to add a new JS or CSS file, or customize / replace a theme or plugin’s existing file (e.g. responsive-menu.js or responsive-menu.css)?

Note: You can easily override individual class selectors within the Clip‘s custom-style.css file. However, when applying significant customization to small or accessory stylesheets, it is better practice to replace the file.

Adding a New JS or CSS File

Create a new file within the Clip and enqueue it via the Clip‘s custom-functions.php file. For example, if including both new-script.js and new-style.css files, you would add the following –

add_action( 'wp_enqueue_scripts', 'clip_new_scripts_styles' );
function clip_new_scripts_styles() {
    wp_enqueue_script( 'clip-new-script', content_url( 'clips/clip-custom/new-script.js' ), array( 'jquery' ), '', true );
    wp_enqueue_style( 'clip-new-style', content_url( 'clips/clip-custom/new-style.css' ), array(), '' );
}

The above code assumes that the new files are added direct to the custom Clip’s root folder.

Customizing / Replacing an Existing JS or CSS File

Copy the original file to the Clip folder and apply the required customizations, then dequeue the original file (via its $handle) and enqueue the new file via custom-functions.php. For example, if customizing a theme’s responsive-menu.js and responsive-menu.css files, you would add the following –

add_action( 'wp_enqueue_scripts', 'clip_new_scripts_styles' );
function clip_new_scripts_styles() {
    wp_dequeue_script( 'responsive-menu-script' );
    wp_enqueue_script( 'clip-new-scripts', content_url( 'clips/clip-custom/js/responsive-menu-copy.js' ), array( 'jquery' ), '', true );
    wp_dequeue_style( 'responsive-menu-style' );
    wp_enqueue_style( 'clip-new-styles', content_url( 'clips/clip-custom/css/responsive-menu-style.css' ), array(), '' );
}

The above code assumes the $handles for the original theme files are responsive-menu-script and responsive-menu-style; and that the new files are added to new or existing /js and /css folders within the custom Clip.

Refer to the links below for  wp_enqueue_script() and wp_enqueue_style() function parameters and syntax –

https://developer.wordpress.org/reference/functions/wp_enqueue_script/
https://developer.wordpress.org/reference/functions/wp_enqueue_style/

Note: If you are building a Precoded Clip, use the clip-functions.php file instead of custom-functions.php and adjust file paths accordingly.