WordPress shortcodes provide a quick and easy way to perform tasks and include HTML code into post content.
According to the WordPress.com definition, a shortcode is a WordPress-specific code that lets you do nifty things with very little effort. Shortcodes can embed files or create objects that would normally require lots of complicated, ugly code in just one line. In other words, thanks to WordPress shortcodes there’s no need for users to manually add HTML code into post content and, in addition, it’s possible to dynamically change the output under specific conditions (i.e. the logged-in user, the current date, the user location, etc.). If you’ve ever used the [gallery] shortcode, you already know how WordPress shortcodes work:
[gallery ids="129,130,131,132" order="DESC" orderby="title" columns="4"]
In this example, gallery is the shortcode tag, while ids, order, orderby and colums are the shortcode attributes. These attributes determine the returned HTML code.
Shortcode Typologies and Structure
WordPress provides two shortcode typologies:
Self-closing shortcodes look like the [gallery] shortcode, and do not require a closing tag.
Enclosing shortcodes require a closing tag, and allow the manipulation of the enclosed content.
A long awaited feature of adding images to WordPress sidebars may be ready in time for WordPress 4.7.4
Adding images to sidebars in WordPress is a cumbersome task that requires users to upload an image to the Media Library, find the URL, copy it, and paste it into a Text widget along with additional HTML. Nearly two years ago, Mel Choyce opened a ticket on WordPress Trac proposing that a media widget be added to core. This widget would allow users to easily add images to sidebars. Throughout the discussion, the idea of creating a catch-all media widget was brought up that would allow users to add images, audio, or video to a sidebar. After developers spoke to Matt Mullenweg about the direction of the project, the team decided to create three separate widgets to handle each media type. Choyce outlined the benefits this approach provides:
We can focus on creating more tailored experiences for each widget.
We’ll be able to launch new widgets without having to worry about constantly updating one central widget, or potentially breaking anything.
It’ll be easier for people to discover new media types since they won’t be buried within one widget.
This will more closely mimic the approach we’re taking to content blocks in the future, which should provide an easier transition.
Dependency management is a problem for WordPress because there is no dependency management at all! In this week’s article I outline why that is such a big issue and go through a proposal I’ve put together for a Composer based solution.
‘Dependency hell’ is a problem faced by all software, and it has been rearing its ugly head in the WordPress space over the last few years with more and more plugins using third-party libraries of code. We come across this issue every couple of months with our Amazon S3 plugin WP Offload S3. It’s a very real problem for Delicious Brains and can serve as a good concrete example of the issue.
Our plugin transfers media to Amazon S3 when you upload to the WordPress media library, and to do that we make use of the AWS SDK (bundled as the Amazon Web Services plugin). The SDK went through some major changes between versions 2 and 3, resulting in the SDK bumping its minimum required version of PHP from 5.3 to 5.5. With 42.7% of all WordPress installs running on servers with PHP 5.2, 5.3 or 5.4, stipulating a minimum of PHP 5.5 just wouldn’t work for our plugin.
When customers use Offload S3 along with another plugin that relies on and bundles the AWS SDK, unless that plugin is using v2, we encounter an issue of incompatible libraries. WordPress loads plugins in the order they were activated, and PHP loads files as they are required and classes as they are
The hair-splitting things a plugin can and cannot do in regards to executing code and installing stuff. Basically, it comes down to if your plugin is doing it or if your service is doing it.
Since Jetpack announced it installs themes, a number of people have asked if this is a violation of the 8th guideline: The plugin may not send executable code via third-party systems.
And in specific, these two items:
Serving updates or otherwise installing plugins, themes, or add-ons from servers other than WordPress.org’s
Installing premium versions of the same plugin
The short answer is no, it’s not, and yes, you could do this too.
The longer answer involves understanding the intent of this guideline, which initially was to prevent nefarious developers from using your installs as a botnet. In addition, it’s used to disallow plugins that exist only to install products from other locations, without actually being of use themselves (ie. marketplace only plugins). Finally it’s there to prevent someone silly from making a plugin that installs a collection of ‘cool plugins’ they found from GitHub and want to make easier to install. Which actually did happen once.
Plugins are expected to do ‘something’ to your site. A plugin that exists only to check a license and install a product, while incredibly useful, is not something we currently allow
This company is thinking about how to combine the applicative advantages coming from different back-end and front-end technologies together with the market and ecosystem of WordPress.
compensated because of their well thought out architecture and enterprise features.
The slippery slope presents itself when you try to implement applicative features using Drupal or Wordpress subsystems.
Both CMS's present a challange to scale and when you compare their performance to a node/express serving content from mongo you move from the 2-3 seconds to subsecond page loads and a great customer experience.
The main force that drove us to develop mean.io was our recurring "sin of the applicative CMS" trying to solve any technological challange with Drupals or Wordpress subsystems which are always inherently inferior to a custom node api + js framework client.
So now we have achieved peformant and awesome fullstack js solutions but we lack the richness of the Wordpress or Drupal ecosystems.
So we started thinking how can we combine the applicative advantages coming
On pitfalls of big wp_options table and how to avoid that from happening.
When troubleshooting a slow WordPress site, an often overlooked culprit is the wp_options database table. This table houses a variety of crucial site data, including: permalinks
In fact, nearly every WordPress page—from the front end to the admin screens—executes the query SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'. If this query does not run efficiently, the results can be devastating to a site’s speed.
Why wp_options doesn’t scale
Not all WordPress database tables suffer as they grow. The wp_posts table, for instance, can be many times larger than the wp_options table without seriously impacting site performance thanks to an indexing strategy designed to accommodate very large datasets.
A database index is similar to a textbook index, which lists every mention of a term in its pages. With clearly marked page numbers, any term can be quickly found. Without this index, every page in the book would need to be flipped through to locate a specific term, every time.
If a database query doesn’t have an index on the requested field (as in our earlier example query on the options table, which
Daniel and I talk all about WP-CLI, contributing to Open Source projects, and the importance of automated testing.
In this episode, Daniel and I get pretty heavy into development tools and using WP CLI, automated testing, and the future of WP-CLI and Open Source. We go a little long, but it’s a great conversation no matter what your background is. Show Notes
Looks like a very interesting product. Good move by Flywheel.
I’ve been using Vagrant and VVV with VV (a site creation wizard) for a while now as the cornerstone of my development workflow. I have customized my VVV quite a bit over the years, and – while I was happy with it – I was always on the lookout for something better to see if it would fit my development workflow better. On a whim, I decided to check out a new app on a recommendation from a co-worker: Local by Flywheel. Flywheel is a fantastic WordPress host, and I’ve had the chance to meet a few of their reps at the last WordCamp – they’ve got a great service, and to see them focusing on the entire development process (from local development to the final production site) is refreshing.
Installation of Local is easy: simply visit https://local.getflywheel.com/ and click on the obvious “Free Download” button. It’ll ask for a few pieces of information, and whether or not you want to use the Mac OSX version (stable) or a beta version of their Windows client. Run through the install process and run the program. It’ll set up the initial run-through and will set a few variables and settings on your machine.
This is not WP-specific but it's exhaustive and highly valuable for anyone in the web development business.
This is a guide that anyone could use to learn about the practice of front-end development. It broadly outlines and discusses the practice of front-end engineering: how to learn it and what tools are used when practicing it in 2017. It is specifically written with the intention of being a professional resource for potential and currently practicing front-end developers to equip themselves with learning materials and development tools. Secondarily, it can be used by managers, CTOs, instructors, and head hunters to gain insights into the practice of front-end development.
The book should not be considered a comprehensive outline of all resources available to a front-end developer. The value of the book is tied up in a terse, focused, and timely curation of just enough categorical information so as not to overwhelm anyone on any one particular subject matter.
The intention is to release an update to the content yearly.
Data on how WP.org is improving the Plugin Directory search results with ElasticSearch. Cool stuff!
The WordPress.org plugin directory has been significantly rebuilt over the past year and should go live soon (test site). Many from across the WordPress community helped with this effort. I focused on improving plugin search relevancy. This was a great learning experience on how to build more relevant searches for a couple of reasons: There is a decent volume of search traffic (100,000 searches per day and over 500k unique search queries per month).
The repo is small enough to iterate easily (45k total plugins) and yet has enough users and use cases that it can be pretty complex. We went through five major iterations on how to index the data.
A lot of people care and have opinions about how plugin search can be better. This makes for a great opportunity to learn because it is easy to get lots of feedback.
Despite building search engines with Elasticsearch for many years, my opinion on how to structure an Elasticsearch query and index content changed a lot because of this project. This post describes my latest opinions.
Background on Plugin Search
In surveys about WordPress, the community regularly rates the plugin ecosystem as both a top strength and a top weakness of WordPress. Plugins
Ever hear of TimThumb, Aqua Resizer, or another on-the-fly image processing library? Well, we’re not fans of them here at Delicious Brains. As we’ve written already, they tend to cause more problems than they solve. In this article, Brad proposes a better solution and offers up an alternative library.
I’ve been bugging core contributors and plugin authors about background processing for a year and half now. To the point where Krogsgard even made fun of me for it at the WordCamp EU after party. “There goes Brad, talking about background processing again.” He was joking, but it’s true. Clearly I think it’s an important subject, but I was surprised to realize that I haven’t talked about it at all on this blog. Ash wrote about background processing just over a year ago. He presented an awesome library that he coded for WP Offload S3 and released it as a standalone library on GitHub for others to use. I wasn’t the only one who was impressed. WooCommerce and Ninja Forms are using it as well.
The library is great, but I realized there was a problem. If each theme/plugin implements their own background processing queue instead of sharing one queue, we could end up running a bunch of jobs at the same time and impacting server performance. As more and more themes/plugins start to do their own background processing (whether they use this library or do their own thing), the bigger this problem is going to get.
I think the best solution is to get background
Interesting: this is a new add-on that allows you write, edit, & collaborate in Google Docs. You then save it as a blog post on WordPress.com or Jetpack-connected WordPress site.
We are happy to announce WordPress.com for Google Docs, a new add-on that lets you write, edit, and collaborate in Google Docs, then save it as a blog post on any WordPress.com or Jetpack-connected WordPress site. Your images and most formatting will carry over too. No more copy-and-paste headaches! To get started, just go to the Google Web Store page and click to install it.
You will be prompted to give our plugin access to post on your behalf, and then you are ready to write.
When you’re ready to save a Google Docs draft as a blog post, go to the Add-ons menu and open WordPress.com for Google Docs. A sidebar will appear where you can add WordPress.com or Jetpack-connected sites.
Click the Save Draft button — when it’s saved, a preview link will appear so you can see how it looks on your site. Edit the post in WordPress.com to make any small tweaks, then hit publish when you’re ready to go live!
You can find the source code on GitHub if you want to take a closer look at how things work. And, of course, this post was composed in Google Docs and posted with the WordPress.com Add-on for Google Docs.
Missing out on the latest WordPress.com developments?
Matt Mullenweg, on Medium (!!!), talks about update signing and security in general.
Accessible WordPress Components Library from 10up is awesome! Check it out!
We’re proud to introduce the WordPress Component Library: a collection of front-end components constructed with WordPress and accessibility at the forefront. Many of the HTML and CSS components we build for our clients are structurally similar, particularly for prolific features like menus, search forms, posts, and blogrolls. A common starting point offers efficiencies to our clients while simultaneously raising the bar on polish and compliance with standards like accessibility. In evaluating existing libraries, we found that the industry was missing a good, open source project built with WordPress’s often opinionated markup (e.g. menus) and basic layout structure in mind.
Since accessibility is a top priority for many of our clients, and critical to our mission to make the web a better place, each component in the library is WCAG 2.0 accessible. We think that this project will help engineers and clients who value accessibility, but may struggle to budget for it, achieve a higher standard with little-to-no added cost.
We are actively adding to and improving the components. Hosted on GitHub, we welcome feedback, questions, and pull requests.
This is fairly exciting news if you know .NET developers: Peachpie is able to run WordPress as a fully managed application on .NET and .NET Core.
After months of implementing the required PHP functionality in Peachpie, our platform is now finally ready to run a larger real-world application: WordPress. Announcing WordPress on .NET
The popular Phalanger project already proved that running a virtually unmodified clone of WordPress on Microsoft .NET is possible. Still the solution had its issues and was not compatible with new WordPress releases. Now the successor to Phalanger, Peachpie, is also able to run WordPress as a fully managed application on .NET and .NET Core.
Please consider this a proof of concept and keep in mind that Peachpie is still a work in progress. We do not recommend using this in a production environment yet. Our primary objective with this announcement is to prove that Peachpie really is compatible with the standard PHP used in WordPress and to demonstrate its benefits.
There are several reasons why it is desirable to run WordPress on .NET:
Performance: compiled code is fast and also optimized by the .NET ‘Jitter’ for your actual system. Additionally, the .NET performance profiler may be used to resolve bottlenecks.
C# Extensibility: plugin functionality can be implemented in a separate
This is a security release so better get to updating. Three issues including WP_Query being vulnerable to a SQL injection and a cross-site scripting (XSS) vulnerability.
WordPress 4.7.2 is now available. This is a security release for all previous versions and we strongly encourage you to update your sites immediately. WordPress versions 4.7.1 and earlier are affected by three security issues:
The user interface for assigning taxonomy terms in Press This is shown to users who do not have permissions to use it. Reported by David Herrera of Alley Interactive.
WP_Query is vulnerable to a SQL injection (SQLi) when passing unsafe data. WordPress core is not directly vulnerable to this issue, but we’ve added hardening to prevent plugins and themes from accidentally causing a vulnerability. Reported by Mo Jangda (batmoo).
A cross-site scripting (XSS) vulnerability was discovered in the posts list table. Reported by Ian Dunn of the WordPress Security Team.
Thank you to the reporters of these issues for practicing responsible disclosure.
Download WordPress 4.7.2 or venture over to Dashboard → Updates and simply click “Update Now.” Sites that support automatic background updates are already beginning to update to WordPress 4.7.2.
Thanks to everyone who contributed to 4.7.2.
Locomotive is a batch processing library and plugin that untangles the complexity of querying and making changes to large datasets. Locomotive automatically breaks these queries into a number of steps, performing smaller queries one at a time, then running each individual result through a single callback function.
When it comes to batch processing WordPress data there aren’t a ton of options available. Yet, we often find ourselves needing to query large amounts of data, and perform simple and repetitive tasks on them. This might mean moving unapproved comments into an approved status, converting users from one role to another, or migrating posts from one content structure to another. Instances where manual effort won’t get the job done without some serious work.
Think about any time you’ve wanted to pull a large amount of posts and perform a simple action on them. Or maybe you want to manipulate users, comments, terms, or any of the other built-in WordPress post types. Writing a single function that performs a query and makes the data changes works…to a point.
But we often work with sites with thousands of posts. One query would be too much to load at once, so the query needs to be broken up. Then, it’s just a matter of setting the right offset, catching errors, performing the steps asynchronously, and pretty soon the complexity skyrockets.
In the last few years, WP-CLI has helped a lot with these kinds of tasks. But there are still hosting environments that don’t
Coen Jacobs has written a lot about Dependency Management with WordPress in the past, and this is his second attempt at solving dependency hell when including third party libraries via Composer.
A first proof of concept version of Mozart is now available for public testing. Mozart is a command line tool for wrapping PHP packages inside your own namespace. This is the least bad solution for solving most dependency management issues inside the WordPress ecosystem. The fundamental lack of dependency management support inside the WordPress ecosystem has lead to a number of issues. Wrapping (third party) PHP packages inside your own namespace is something some developers already started doing on their own. Mozart simplifies and automates this process.
Say you want to use the Pimple package in your WordPress plugin. This package runs from the Pimple namespace. What Mozart does, is convert the files from the Pimple package, to use your own namespace, CoenJacobs\TestPlugin\Pimple for example. Your plugin can then use this package, inside your own namespace, so you always use the exact version you want.
Dependency management issues
I’ve written a fair bit about dependency management when it comes to the WordPress ecosystem. Behind the scenes, I have been researching various ways to deal with the issue at hand. In case you missed it, WordPress offers no way to handle dependency
This is UI prototype for Editor. Very initial stage, but do test-around!
There is a UI prototype now for testing, this is a call for people to start that. If you want to test you can find Gutenberg here. How to test?
You can test in any way you want. You can test yourself and also test others. You can take images, audio or video. If you do create a video don’t forget to pull out those bugs, action points and do a summary. Cutting smaller videos out is also really useful.
Questions you can ask:
(on first look) Can you explain in words what each section does?
Can you write a paragraph of text? How does it feel? What are your thoughts?
Can you add an image? How does it feel? What are your thoughts?
If you find a bug please report it in this repo.
You can also leave results from your user testing either as a comment here, or you can link to a blog post.
As specific things need testing, further posts like this can be made.
Edit: as mentioned by @grappleulrich, this is very much in the early stages as a prototype. If you find an issue though please report it on the repo and also focus on how the flows work at this point.
It’s been awhile since Matt wrote part 2 of the Automating Local WordPress Setup series, so he thought he'd revisit the scripts to add the things that he's still been doing manually like setting up virtual hosts and prepping the WordPress install for development.
In my last post in the Automating Local WordPress Setup series, I created a WP-CLI package for quickly installing and uninstalling WordPress. I’ve been using this package for a while now, and have been itching to make it more useful for a typical development workflow. I recently switched from using a single virtual host to hold all of my development sites in subdirectories (i.e. http://localhost/example) to using a dedicated virtual host for each development site. There are several advantages to having it setup this way, but I had been using subdirectories to avoid having to manually manage each virtual host.
I also still catch myself doing things that I know should be automated. Things like deleting unnecessary data, removing the default themes/plugins, and installing new plugins, are things that can be automated to make development easier. In this post we’re going to take a look at some ways to make all that possible.
Working with Virtual Hosts
If you’re not using them already, there are two main reasons for switching to virtual hosts for local development:
You can have a different environment for each host, with each site running a different version of PHP
If you're a WordPress plugin developer with plugins in the repo, note these changes to two specific guidelines.
With the advent of the new directory being on the horizon, which allows us to easily hard-limit the number of plugin tags displayed, we have taken the time to change the guidelines. While minor updates to the guidelines (with regard to spelling, grammar, etc) are common, major changes are rare and we are striving to be more transparent about them. Hence this post
Guideline 12 (readme links) clarified to cover spam and tags.
The guideline now reads as follows:
12. Public facing pages on WordPress.org (readmes) may not spam.
Public facing pages, including readmes and translation files, may not be used to spam. Spammy behavior includes (but is not limited to) unnecessary affiliate links, tags to competitors plugins, use of over 12 tags total, blackhat SEO, and keyword stuffing.
Links to directly required products, such as themes or other plugins required for the plugin’s use, are permitted within moderation. Similarly, related products may be used in tags but not competitors. If a plugin is a WooCommerce extension, it may use the tag ‘woocommerce.’ However if the plugin is an alternative to Akismet, it may not use that term as a tag. Repetitive use of a tag or specific
Detailed walkthrough and report card style grading of Liquid Web's Managed WordPress offering
I make no bones about the fact that I use multiple web hosting companies. This experience gives me a baseline to compare different hosts and decide which is best for what situation. The newest host on my list is Liquid Web. They’re a long-time player in the web hosting space and more recently have added managed WordPress hosting to their lineup. In this post, I’ll specifically review Liquid Web’s Managed WordPress hosting. I’ll also share how it stacks up against my other favorite hosts and who I think would best benefit from their service.
Don’t be scared, but note that there are affiliate links in this post. I only recommend products I use and enjoy. You can read more here.
Liquid Web Review (report card style!)
Liquid Web hosting falls into five primary buckets: dedicated servers, VPS hosting, dedicated cloud, cloud sites, and managed WordPress. Note that they do not offer shared hosting services, so if you’re looking for something cheap, you can quit this article now.
They also offer custom solutions for enterprise-level clients. In short, Liquid Web is in the upper tier of web hosting.
The following is a managed WordPress hosting review since
The WordPress Theme Developer Handbook has finally been released. Congrats to the almost 100 involved. Feedback welcomed.
Weekly Meetings As well as discussing docs issues here on the blog, we use Slack for group communication.
Individual teams have their own regular meetings – you can find details of those in the sidebar.
Bottom line: when you uninstall a plugin, if it was well written, it removes the files and the data.
Someone asked me why WordPress always says it’s going to delete files and data when it only removes the files and not the database options. There are two parts of the answer to this, one being a little historical and the other being a bit unhelpful. The Message: Delete Files and Data
Once upon a time, when you uninstalled a WordPress plugin, it looked something like this:
That was a very simple screen. You were asked to delete the plugin files, you clicked that you were, done.
Now you see this thanks to Shiny Updates:
It’s a different message, telling you it’s deleting data!
What Is The Data?
The part you don’t see is that WordPress would also remove all the data as well as those files.
Any time WordPress showed you that message to delete files and data, it was saying that it found a file called uninstall.php which would, presumably, delete the data set by the plugin. By this I mean the options and settings you chose for your plugin. Some plugins have data and others don’t. For example, Hello Dolly has no data, just files. It doesn’t need an uninstall file. On the other hand, a plugin like Jetpack has a lot of settings it should remove from the database