WordPress developers have been debating, for more than a decade now, how the core software can support plugins whose functionality depends on the presence of one or more additional plugins. The fact that developers currently have to devise their own solutions for this problem makes it clear why having a standardized method of managing plugin dependencies would be an advantageous and time-saving feature.
When introducing the concept of the feature plugin back in February, project lead Andy Fragen said that “the situation there is a lot like the relationship between parent and child themes.” “Those dependent plugins are unable to accomplish much on their own without the relationships they have with the larger plugin. Each individual plugin developer is responsible for independently coding a solution to the problem. The most typical example is WooCommerce, which serves as a prerequisite for hundreds or even thousands of add-on plugins for WooCommerce.
The Plugin Dependencies feature plugin has been the subject of debate and development for the past nine months, and it is finally ready to be tested. It grants the authors of plugins the ability to specify any WordPress.org-hosted plugin(s) that are necessary for the functionality of their plugins. By adding a “Requires Plugins” header to the docblock of the main plugin file, it is possible to determine whether or not a plugin has dependencies on other plugins. Authors of plugins have the ability to specify any number of dependencies that may be required in the form of a list of plugin slugs that is delimited by commas.
How does it work? If there are dependencies that the site owners need to install, an administrative notice will be sent to them. On the Plugins screen, the plugin card will be updated so that it displays the information about what it Requires and who it is Required by.
Fragen outlined the procedures that the community can follow in order to test the newly implemented support for handling plugin dependencies. Testing out this brand-new feature does not require you to have any prior experience in the development process. Installing test plugin files and ensuring that admin notices appear and disappear at the appropriate times are required to complete this step. Testers who are familiar with editing plugin files can try adding dependencies, adding a dependency for plugins that are not hosted on the WordPress.org repository, and performing other more advanced tests.
Because version control is not a component of this project, developers won’t have the ability to do things like specify a minimum required version, for instance.
In response to a question regarding the feature plugin, Fragen stated that “Version control is out of scope for the feature as described in the original Make post referenced above.” Because the majority of the dependencies are pulled from the repository at dot.org, the most recent versions will be installed.
In particular, “WordPress ought to automatically prompt the user to update to the most recent version, and it may also use auto-updates.”
The testing period will continue until the first of December in 2022. You can report problems to the repository for the WP Plugin Dependencies plugin if you want to take part in the process of getting this long-awaited feature considered for possible inclusion in the core.
The WordPress Security Update 6.0.3 Addresses 16 Known Flaws in the Software
This week marked the beginning of the rollout for WordPress 6.0.3. The most recent security update addresses 16 different vulnerabilities.
In version 6.0.3 of WordPress, vulnerabilities such as open redirect, data exposure, cross-site request forgery (CSRF), and SQL injection have been patched. These vulnerabilities include nine instances of stored and reflected cross-site scripting (XSS).
Defiant, a company that specializes in WordPress security, has provided a description of each vulnerability. Only four of them have a rating of ‘high severity,’ while the rest either have a rating of’medium severity’ or ‘low severity.’
The company issued a warning that stated “We have determined that these vulnerabilities are unlikely to be seen as mass exploits,” but that several of them could offer skilled attackers a way to exploit high-value sites using targeted attacks.
Another flaw with a high severity is a reflected cross-site scripting vulnerability, which can be exploited by an unauthenticated attacker to execute arbitrary code in the media library by using a search query that has been carefully crafted by the attacker. Defiant believes that this vulnerability could be the most exploitable in this release because the attacker does not need to be authenticated in order to take advantage of it. However, exploiting this vulnerability does require user interaction, and creating a payload can be challenging.
The third highly critical vulnerability is a SQL injection that could be exploited by a third-party plugin or theme, but the core of WordPress itself is not impacted by this vulnerability.
The most recent critical flaw is a cross-site request forgery (CSRF) flaw that can be exploited by an unauthenticated attacker to trigger a trackback on behalf of a legitimate user. However, social engineering is required for successful exploitation of this vulnerability.
Websites powered by WordPress and supporting automatic background updates will have their vulnerabilities patched automatically. The upcoming major release, version 6.1, is scheduled to go live on November 1.
According to the Website Threat Research Report for 2021 published by Sucuri, WordPress-powered websites were responsible for more than 95% of all CMS infections. Furthermore, approximately one-third of the websites on which the cybersecurity company found a credit card skimmer were powered by WordPress.