Trunk vs Tags? Which is Better? (Answer: Tags)

tl;dr – We strongly recommend you use tagged folders for your releases of your plugins. Future you will thank you.

While we have always advocated for people to use a tag folder with their plugins instead of trunk, it persists that a number of developers like using the “Stable TagTag Tag is one of the pre-defined taxonomies in WordPress. Users can add tags to their WordPress posts along with categories. However, while a category may cover a broad range of topics, tags are smaller in scope and focused to specific topics. Think of them as keywords used for topics discussed in a particular post.” of trunk. There are logical reasons for this. Having your stable tag be trunk feels like it’s one less thing to keep in mind when you update your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party for a new release.

The problem with that setup is that you suddenly made it harder for everyone else to keep tabs on your plugin, to make sure they downloaded the correct version, and worst of all … you made it nearly impossible to roll back to a previous release. And with the advent of automated plugin updates, that last one is going to be damaging to you in the long run.

In fact, here’s what you’re making worse:

  • No easy way to download older versions to debug compatibility issues
  • Translators cannot work in ‘advance’ of a release, meaning as soon as you push your code, the translations are out of date until volunteers can work on it
  • You increase your risk of an accidental release
  • No way to allow people to download the ‘pre-release’ version from official WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ sources
  • No ability to ‘roll back’ versions

So what’s the right way?

  1. Make sure your readme.txt has the stable tag to your stable version in the main plugin file (those need to match)
  2. Put everything into your trunk folder on your local checkout (use svn add and so on as needed)
  3. Run svn cp trunk tags/1.2.3 — this will copy from trunk to the tag folder
  4. Run svn ci -m "Releasing new version" — this will push both trunk and tag

That’s it. You’re done. Now you can upload and edit trunk all you want, for a dev version, and as long as the readme points to the proper stable tag, your users won’t get any updates.

Okay, but what if you want to have a trunk version for testing? Do not edit the stable tag in the trunk readme! It’s that value that tells WordPress which version is ‘stable’ and if you’re working on 1.2.3, keep stable as 1.2.2 in trunk and no one will get the new code until you’re ready.

#release, #svn, #tags

Reminder: Forked Premium Plugins Are Not Permitted

tl;dr: We do not permit copies or forks of premium (pay for) plugins to be hosted on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/.

Caveat: While this topic always brings up people arguing that the GPLGPL GPL is an acronym for GNU Public License. It is the standard license WordPress uses for Open Source licensing https://wordpress.org/about/license/. The GPL is a ‘copyleft’ license https://www.gnu.org/licenses/copyleft.en.html. This means that derivative work can only be distributed under the same license terms. This is in distinction to permissive free software licenses, of which the BSD license and the MIT License are widely used examples. means they can (and yes, you can copy GPL plugins and do whatever you want with them), we wish to remind developers that just because the GPL allows something doesn’t mean we will host it here. Our guidelines are considered above and beyond the GPL. After all, the GPL doesn’t say you can’t punch someone, but if you get into a fistfight at a WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more., we’re not going to host your plugins.

Taking someone’s pay-for code and re-releasing it as free-of-charge is considered (by us — the PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Review Team) to be a form of piracy and is not welcome here. It doesn’t matter if the code is GPL, it matters that When you do that, when you copy and re-release someone’s code without any changes, you’re stealing the opportunity of the original developers to make a living, and we feel that is detrimental to the community. In addition, it’s often in violation of the terms you agreed to when you downloaded the plugin from the developer in the first place.

By you doing that, and rehosting here, you put the entire directory in peril. Arguably we become responsible for your actions. As such, we do not permit plugins that are sold off WordPress.org to be re-hosted here.

The only exception to this (besides it being your own plugin) is if you have made a significant fork, properly credited in the readme and inline code, and everything was 100% GPL compatible, including the terms from where you bought the plugin. If you pirated a plugin, or if you violated the license purchasing terms (which may say things like you cannot resell it), then we cannot host the code.

Edit: It’s important to note that adding non-GPL compliant terms to a license may in fact invalidate the license, which means we can’t host it here anyway. The above comment is not in support of people violating licenses nor are we attempting to protect and help those people in any way. We are trying to point out that even if a license says it’s GPL, if it’s sold with terms that violate the GPL, it cannot be hosted here either. tl;dr? If the license or terms are sus, we can’t host it.

If the plugin is your own plugin and you just want to re-host here, we will do our best to validate that claim, and may pend your plugin while this is researched. We appreciate your patience when that happens.

If you feel someone took your plugin and hosted a copy of it here, please email plugins@wordpress.org with a link to the plugin as it’s hosted here, a link to your original plugin, and (if the plugin is hosted outside WordPress.org) attach a zip of the plugin so that we may compare the two.

Edited to add: This post is not about the GPL. This is only about the existing WordPress.org Plugin Developer Guidelines. You should not, under any circumstances, use this post to frame your understanding or interpretation of the GPL as it is not intended as such. Again, this post is about the plugin guidelines, the ones all plugin devs already committed to following, which have long since stated that immoral or ethical practices are not permitted here.

#reminder, #theft

Why the Plugin Emails are ‘Anonymous’

In 2019, we transitioned to a new email service which has allowed us to make all emails anonymous. This decision was not initially well received by all, especially when people feel they are unfairly targeted for guideline violations, though over time it’s settled down.

I wanted to take a minute to explain the backstory about why this had to happen.

Backstory

Over the last four years, there has been a disturbing escalation in behavior with regards to plugins. Reviewers have found themselves targeted in rather terrifying ways, including:

  • emailing someone’s employers to complain
  • making credible threats against safety at an upcoming WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more.
  • doxxing a reviewer by publishing their address
  • publicizing information about their families
  • death threats
  • sending physical packages/mail to them

All those things happened from people who were censured for not complying with the guidelines. Some of them even chose to quit, asking us to pull their plugins, and then retaliated in that manner.

Their reactions are always rather odd to look at in the community because the PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Team does not publicize these issues. That is to say, we generally will not explain, to the general public, the full details on why something was closed or a developer banned. We don’t do this to hide anything for our own benefit, though that appears to be a common misconception. The reason we keep those issues private is that we feel it gives developers a chance to walk back from a very bad day.

We know we’re sending out some pretty devastating emails to people. Being told “Your plugins have been closed” is a gut-punch, and it’s one we really try to avoid. When people are hurt, they have a tendency to lash out, and in doing so they can cause irreparable harm to their own standing in society. The Internet never forgets anything, and the words said in anger and frustration will haunt us to our dying day and beyond.

By keeping the conversations private, we are allowing developers to have the ability to survive their bad day. You can think of it as giving people a second chance. Of course, you can’t help everyone, and we do know to cut our losses. Not everyone will come back, and some people will burn bridges so badly that it would be detrimental to the community at large to allow it, no matter how much they apologize.

The Decision

2019 was the worst year on record for categorical abuse of the members of the team. It’s difficult to express without violating confidence (and in some situations, legal cases still pending) exactly how bad. When we say ‘Someone mailed things to a reviewer’ we literally do mean that unasked for items were sent via physical mail. And when we say that someone’s home address was leaked, it was absolutely done with intent to harm.

All this leads to the great cost we bear, willingly, as we shoulder the outrage quietly. When we had people’s real names attached to the emails, we had them targeted specifically and personally. They were clear attacks on people, many times misguided and misdirected, that prompted us to change the emails to anonymous.

Because of the attacks on people’s safety and out of a desire to protect their health and well being, we have chosen to make all emails from the Plugin Review Team anonymous.

Failures

This choice has not really gone over as well as we’d hoped.

It’s no secret that people get very passionate about their plugins. They’ve created something out of their heart and minds, and getting emails from us telling them that there are issues with their work is disheartening. It’s worse when those are clearly a form email.

When we moved to form replies years ago, in order to expedite the review process, they were generally understood to be the cost of the high volume of reviews. Having impersonal emails sent from a real human was annoying, but acceptable. Having impersonal emails sent from an anonymous account makes us feel like we’re not valued as humans.

That’s why we’ve worked hard to rewrite a lot of the emails to be more clear about what the problem is and what you need to do to resolve it. We’ve tried to make our dreaded ‘Final Warning’ email even more clear.

We Want You To Do Well

We want nothing more than the continued success of the Plugin Ecosystem, hosted on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ and not. When we’re reviewing your code, we want the code to be safe and to be well documented so that you have every possible opportunity to be a success.

We can no longer sacrifice ourselves in doing so.

Our emails are always sent by a real human being, who is just as flawed as you are. They’re never personal attacks. While we always do our best to make sure we’re in the right before we send a warning, we are humans, like you, and we make mistakes.

We Will Continue to Be (Mostly) Anonymous

With rare exceptions, emails from plugins will remain anonymous. In some cases, the person replying may divulge who they are, but that is their personal choice to do so. No one on the team will ever be required to reveal their identity in an email.

We hope you can understand this frustrating, but needed, action.

#abuse, #explanation, #privacy

Reminder: Plugins Must Not Interfere with Updates

While we do look for plugins that touch the update services on submission, we do not monitor existing plugins, which is where this reminder stems from.

Unless your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party has the purpose of managing updates, you must not change the defaults of WordPress’ update settings.

You may offer a feature to auto-update, but it has to honor the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. settings. This means if someone has set their site to “Never update any of my plugins or themes” you are not to change those for them unless they opt-in and request it.

The reason for this is that plugins should not over-reach their authority. When a plugin is made, it is self-defined by the developers as what it will do and why. There are some logical reasons to expand that of course (an anti-spam comment plugin may grow to also handle feedback forms), but for most plugins, the arbitrary management of plugin updates is outside their stated goals.

Plugins crossing over purposes, overriding settings that are unrelated to the function of their specific goal, can and will cause unexpected outcomes. It also destroys the faith users have in you to not break their sites. Sadly, this happened recently to a well used plugin, and the fallout has been pretty bad.

We do understand that many plugins want to take advantage of the new features within WordPress. But if your plugin is a custom blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience., you really don’t have a need to be changing how the uploader works, or even setting your plugin to default-auto-update.

At this time, we have no plans to spell this out in a guideline. We do currently, regularly flag plugins that go outside their dictated (self defined) boundaries, and this is not a change. Please, respect your users.

#reminder, #updates

2020 Roundup

Well. It’s been a year…

Overview

Between December 31 2019 and December 28 2020, we have:

  • 8486 plugins submitted (up from 8048)
  • 1338 plugins rejected (up from 1221)
  • 3317 plugins closed (down from 6038)
  • 676 plugins pending review on average week to week (up from 623)

It’s not a huge increase in workload, and unlike last year, we have only three spikes of massive closures.

Here’s an overview in table format:

RequestedRejectedClosedApprovedPending
Most in a week221111600132790
Least in a week12821041560
Average169286569676
YEAR TOTAL8486133833173451595

Overall, the load was slightly up but nothing to phone homePhone home A plugin that “phones home” sends back tracking information to the plugin developer once it’s installed on a site. This may include IP addresses, usernames, or other data. about.

The number one reason a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is closed is, still, bounced emails. The number two reason is security, followed by general guidelines and trademarks.

The number one reason a plugin is pended for approval is sanitization/validation related (remember you have to do both – sanitize and validate – because otherwise people will put ‘dog’ in for a value of how many hats they need).

Looking Back at 2020

We had some wins and some losses.

First, here’s what didn’t go great:

  • New Team Members — this was probably the worst year for that, seeing as real life kicked everyone around. Of the people onboarded, one remains semi-active.
  • Tools — I did not manage to convert my shell script to something mass-consumable, but I did make significant progress in improving it
  • Trademarks — Legal representatives from multiple companies have forced us to be harsher and more strict with trademark usage. There’s very little we can do here.

Now here’s what did go well!

  • HelpscoutHelp Scout A 3rd party service we use to process emails for plugin reviews. — This has been a godsend. We’ve managed to improve a lot of automation with it, speeding up everyone’s work.
  • .Org Tools
    • There are a lot more checks for trademarks in slugs and display names now, so people can’t even submit violations.
    • We added a lot of code to allow people to better manage their own plugins. For example, you can close your own plugin as well as change the primary owner.

Helpscout

As mentioned last year, we make heavy use of Saved Replies to speed up reviews and processing. Here again, in order from most used to least, are the most commonly used replies:

Reviews

These are sent out during reviews to help identify issues:

  • Review: Please sanitize, escape, and validate your POST calls
  • Review: Generic function/class/define prefix names
  • Review: Invalid Tested Up To
  • Review: Incomplete Readme
  • Review: Not using wp_enqueue commands
  • Review: Calling remote files (js, css, images, etc)
  • Review: Undocumented use of a 3rd Party or external service
  • Review: Including Libraries Already In WP CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. (including jquery)
  • Review: Including out of date libraries
  • Review: Including your own CURL code
  • Review: Calling file locations poorly (also hardcoding in paths)
  • Review: Whole $_POST processing
  • Review: Including full vendor/demo/documentation folders
  • Review: Using esc_ to sanitize (not esc_url)
  • Review: Plugin uses Error Reporting in public
  • Review: Display Name infringes on trademarks (slug is fine)
  • Review: Including your own update checker
  • Review: Using file_get_contents on remote files
  • Review: Calling core loading files directly (wp-load etc)
  • Review: Poorly Chosen Plugin Name
  • Review: Including a zip file
  • Review: Using variables/defines for text-domains (this breaks glotpress)
  • Review: Allowing Direct File Access to plugin files
  • Review: Not using Nonces and/or checking permissions
  • Review: Plugin is still calling localhost
  • Review: Your admin dashboard has an iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser.

Rejected

These are the most common reasons a plugin was rejected:

  • Rejected: New/renamed version of their own plugin
  • Rejected: Not Your Plugin (Tried to upload vs host)

Pended

The top three reasons a plugin is pended before we even review it:

  • Pended: Name Infringes on Trademarks (slug and name need to be changed)
  • Pended: Not Official Owner
  • Pending: Website incomplete (coming soon/demo)

Replies

These are common replies to common issues.

  • Reply: Rescan (Plugins must be checked before being reopened)
  • Reply: You can remove your own plugin
  • Reply: Plugin Slug Renamed
  • Reply: Be More Patient
  • Reply: Not a Marketplace
#year-in-review

The WordPress 5.6 Email Has Been Sent

With the release of the 5.6 field guide comes the email.

WordPress 5.6 Field Guide

If you are a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party developer and did not receive the email, please double check the email address in the user account that has commit access to the plugin.

Also please keep in mind, if your email bounces or we receive auto-replies after previously warning you, your plugin will be closed until you resolve this issue.

#release

You can now add your own plugins to the Block Directory

Introducing the BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Directory in WordPress 5.5

The WordPress 5.5 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. release that’s now in testing includes Block Directory support enabled by default. In case you missed it, the Block Directory is a subset of plugins in the plugin directory that can be instantly and seamlessly installed from the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ editor with a single click. We call these new plugins “block plugins” and have worked hard to make it easier for people to contribute to this new feature coming to WordPress 5.5. This post is meant to help show how to get your very own block pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party added to the directory and share some helpful resources along the way.

Step 1: Create your own block plugin

If you haven’t yet had a chance to create a Block Plugin, don’t fear! There’s still some time until the August 5.5 release. Here’s a new and improved tutorial that walks you through the process of creating a block plugin. More documentation is on its way too and you can join the discussion about what would be helpful to have shared in this GitHub overview issue.

The guidelines for Block Plugins are still in the process of being finalized. Block Plugins need to be much more minimal than a regular WordPress plugin in order to be safely installed with a single click. That means as well as keeping to the regular plugin guidelines you’ll also need to follow some additional rules. In particular, you should stick to mostly JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. code and keep PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. to the bare minimum; and not add any UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. or other code outside of the Gutenberg editor.

Step 2: Run your block plugin through the checker tool

In order to help developers follow the guidelines and best practices, we’ve been working on some documentation and a new tool. It’s called the Block Plugin Checker. Give it a plugin repo URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, and it will examine the code to look for possible problems to resolve before your block plugin can be added to the directory:

This is still a work in progress so if you find any fun bugs or omissions, please let us know. We’d love the chance to fix them and to make the Checker a more useful tool.

Step 3: Add your block plugin directly to the Block Directory

If you’re a committer of a block plugin that does meet the criteria for adding it to the Block Directory as confirmed by the Checker tool, you can then add it yourself using the same tool:

Likewise you can remove it at any time using that same tool if you notice problems or would prefer it wasn’t included. 

Going Forward

We’ll be making improvements to the Block Plugin Checker, and doing additional testing of plugins that are added, so please expect some changes along the way. If you have any feedback or questions, please comment here or in #meta on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

#features #block-directory

Reminder: Compatibility with Core Matters

Over the years we’ve gone from always showing all plugins in searches to devaluing plugins that aren’t updated in a time span to devaluing them if they’re not compatible with the latest few releases of coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. All of this is done to improve the user experience and to ensure they only find plugins that are actively maintained and compatible with the versions of WordPress they use.

As part of this, when a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is closed we currently require the ‘tested up to’ value to be, at least, the latest stable version of WordPress core. We have updated our emails for closures and re-scans to reiterate that, but it’s for a slightly different reason than helping users.

We want to help you developers. If no one can find your plugin, because it’s not compatible with (say) WP 5.5, then no one uses your plugin. Presumably, if your code is hosted here, you want people to use it. To help you and ensure your plugins can be found and used, we are requiring you update that, should we have any reason to close your plugin.

Just like you have to bump the plugin version so people get notified of updates, you need to make sure that “tested up to” value is current 🙂

So! Please keep that up to date! It’ll help people find your plugin, give them confidence in your work, and help make you more successful! Wins all around 🙂

#guidelines #reminder

Proposed Block Directory guidelines

The proposed guidelines for submitting BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Plugins to the Block Directory have been revised, with many thanks for the feedback and suggestions from developers and the community. If you haven’t had a chance to see them yet, you can read the most current version of the guidelines here.

In case you missed it, the Block Directory is a new feature coming in WordPress 5.5 that allows specially-written Block Plugins to be instantly and seamlessly installed in the editor, without ever leaving the page. In order for blocks to install seamlessly, they need to meet certain expectations.

These guidelines will be added to the official WordPress Detailed Plugin Guidelines, as a special section that applies to plugins submitted to the Block Directory. This set of guidelines would not apply to general plugins that happen to include blocks — plugins in the main pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party directory need only follow the standard plugin guidelines.

If you are interested in developing a special Block Plugin that will work in the Block Directory, here’s some new documentation and tools to help:

If you have feedback, comments, or questions about the proposed Block Directory guidelines — or about the tools or tutorials — please share them in a comment on this post.

#features #block-directory

RESOLVED! Plugin Update Issues – 18 June 2020

As of 21:45 ET on 18 June, this SHOULD be resolved.

The original post remains below.


We are currently experiencing issues with pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party updates properly displaying on the front end.

Systems is looking into this. We will have this resolved as soon as possible, however we do not have an ETA at this time. We ask for your patience and understanding.

12:31 ET – The issue has been identified, and the people to address it are being brought in. At this time, we ask you NOT attempt to push your code again. It won’t help.

12:46 ET – While we’re working on a permanent fix, we are attempting to manually clear the backlog. You may see some plugins updating, but this does not mean the issue is resolved.

13:10 ET – We’ve cleared out as much of the backlog as possible, however the issue has not been resolved. No new commits will go through. Again, please don’t try to push code. It’s still down.

15:15 ET – Some preemptive patches have been applied for when the fix is finalized, however updates are still not functioning properly.

17:10 ET – The situation is still ongoing. Our attempted fixes did not correct the issue.

19:20 ET – No ETA, fix is still being worked on. In the meantime, we’re devising a way to let us manually run the jobs without the need for system intervention, in order to ensure security fixes are pushed in a timely fashion.

21:45 ET – A commit has been made to properly trigger the cron job that does the magic. We believe the situation to be resolved.

Please thank @otto42, @ocean90, and @dd32 for their hard work!

#systems #downtime