The fundamental functionality of WordPress is expanded by code packages known as plugins. WordPress plugins can also contain assets like photos, CSS, and JavaScript in addition to PHP code.
You are extending WordPress, i.e. adding new functionality on top of what WordPress already provides, by creating your own plugin. You could, for instance, create a plugin that connects to the ten most recent blog entries on your website.
Introduction to Plugin Development
This is the Plugin Developer Handbook, so welcome. We believe that this guide will enable you to create the greatest plugin possible, whether it’s your first or fifty-first.
The Plugin Developer Handbook discusses a wide range of subjects, including what should go in the plugin header, recommended practices for security, and the tools you can use to create your plugin. It’s still a work in progress, so if you spot any errors or omissions, please let the documentation team know in slack so we can fix them.
Don’t touch the WordPress core is the unbreakable first rule of WordPress development. This implies that you cannot add functionality to your website by editing core WordPress files. This is because every time WordPress is updated, core files are overwritten. The best way to add or change functionality is to use plugins.
Depending on what you want to do, WordPress plugins can be as basic or as complex as you need them to be. A single PHP file serves as the most basic plugin. An illustration of one of these plugins is the Hello Dolly plugin. A Plugin Header, a few PHP functions, and some hooks to attach your functions to are all that are required for the plugin PHP file.
How do plug-ins function?
Plug-ins fulfill a well-defined function. They specialize in handling particular kinds of content, processing it, and integrating it into the platform, frequently merging it with the user experience. Even though plug-ins can give the impression that they are a part of the website itself, the platform nevertheless functions without them.
As a result, webmasters can update plug-ins without worrying about making modifications to their preferred hosting platform. Application programming interfaces (APIs) are used by developers to enable plug-ins to communicate with websites. If an API is reliable, a plug-in will continue to function even after its original version has been changed.
Pros Plugin Systems
- Granularity-
There is a wonderful modular granularity to a plugin bundle; there is no other way to explain it but to state that the components and bundles feel “right-sized.” Consider the OSGi-based Spring Dynamic Modules as an example. Compared to implementation wire, which places no actual packaging or builds constraints, bundles offer a stronger functional abstraction that can result in strong modular cohesion and sound codebase organization.
When compared to acceptance tests, BDD, requirements, or even simple things like release notes, they also appear to give a more cohesive framework for organizing code than objects.
- Partial improvements-
In order to accommodate partial upgrades, monolithic systems typically require monolithic upgrades or workarounds to the build process and version model. In very formal release processes for even small updates in critical operating contexts. Plugins enable precise improvements. Additionally, they significantly lower the price of regression testing. As long as the plugin properly handles its related data (see “Data contracts and trust” below), undeployment is simple.
- Concurrent engineering-
This is connected to the idea of partial upgrades. The ability to enable numerous simultaneous work streams and, consequently, many parallel release streams during development is a desirable side consequence of a plugin design. It’s difficult to understand how effective it can be unless you’ve worked on a codebase that enables it; it’s the kind of thing release managers fantasize about but almost never get to witness.
The purpose here is to be able to treat system S.1.0.0 as a version umbrella for a group of plugins, P.1.0.0… Pn.1.0.0, even though concurrent engineering is probably the most effective process technique for reducing failure risk in product design. When only one or two plugins are upgraded while the others are kept in place, S.1.1.0 is the outcome. Minor and feature upgrades can then be managed as release configurations. Metadata can be used to configure this (nearly) totally. I should probably write another post specifically explaining how that operates as a follow-up.
- Contracts-
Strong contracts must be exposed to hosted services by good plugin systems, which tends to strengthen the software architecture overall.
- Democratization-
Developers that use your product or service don’t need to be particularly familiar with the inside workings of your code to code to it. This enables independent evolution and innovation. It can occasionally be used to scale back development initiatives. This is especially crucial if your architecture is database-centric (extending domains driven by table designs is notoriously difficult and messy).
- Configuration-
Though rarely mentioned in connection with plugins, this is a crucial point. A big-ball-of-mud. conf sounds insignificant, but it can complicate everything after the green bar, including build, packaging, deployment, and regression. Configuration in a plugin architecture will typically be split out along functional lines to avoid systems that are functionally cohesive but exhibit no cohesion around configuration. Take a look at how apache2 httpd.conf is divided up into separate files as opposed to the one file method used by apache, for instance.
- They’re cool-
Actually, no. It is nearly impossible to comprehend complexity, incohesion, and the propensity of software systems to evolve toward entropy unless you are a software engineer. Therefore, businesspeople adore plugins. They immediately understand how the majority of the rest of the industrial world operates when you say something like, “Appearingly trivial feature X will take 3d to implement but require a mass restructuring that will take 10d.” A stakeholder’s perception of the program is completely changed after being shown a web page with a list of deployed and available plugins.
Cons of Plugin Systems
- Abstraction and everything’s “metaness”-
Service provider and callback interfaces, manifest formats, registries, dependency chains, and plugin lifecycles are just a few of the additional abstractions needed for plugins. Even with architectures that enable dependency inversion techniques, many aspects that are implicit in monolithic architectures need to be made explicit and consistent.
- Platform and plugin decay-
P.1 supports plugins A.1 and B.1. Because, you upgrade to P.2. However, B.1 won’t operate on P.2. Even worse, the rest of the product ecosystem is migrating to P.3, leaving you at risk of being abandoned and/or without support on P.1, and you are unable to upgrade to B.2 since A.1 won’t work on P.2.
When the plugin itself becomes just as significant as the underlying platform, the latter is more likely to occur. With Zope2/Plone, which has a highly complex product plugin architecture (Plone is a Zope plugin), I experienced this a lot, and to a much lesser extent, with Jira and Firefox. It may be argued that waiting for customers to pay you to upgrade the plugin is a form of business model.
- Testing and creation-
Unless significant care has been taken to abstract away the runtime, plugins must be plugged into something, which requires deployment.
- Isolation-
In shared environments like runtimes and virtual machines, it is challenging for plugins to avoid shared states and uncontrolled interactions. I believe that OSGi represents the future of Java plugin architectures more than anything else. If Sun doesn’t decide to include Isolates in a subsequent JDK, OSGi is the only tested solution for classpath isolation. The kind of “multihoming” plugins that go beyond simple handler classes are not supported by Java’s classloader design.
In this aspect, the browser is a nightmare as a platform for javascript “plugins” (more appropriately, code-on-demand). Global variables, xhr hijacking, and the crazy crap prototype all need to be eliminated. Even then, limiting access to shared resources like memory, cycles, or IO is far more difficult. As an example, consider how Google App Engine, a grandiose plugin system (really!? ), limits access to external resources.
- Data agreements and faith-
In my opinion, a bigger issue than API breakage is plugins that produce data and then violate the data contract upon upgrade. Code that doesn’t respect data can’t be trusted, so perhaps the market weeds these out, but for some people, it may be too late.
