Replacing Plugins in Textpattern
2 September 2006, 06:31
Textpattern is a feature-rich tool for publishing on the web. It provides for a wealth of additional features using independently-developed plugins.
This site currently has a dozen plugins installed with eleven of them “active.” Once added to your Textpattern installation and made active, these plugins provide sets of tags and features that extend Textpattern’s features beyond the native capabilities.
In other cases, plugins simplify the way something might be done in Textpattern. However, as Textpattern’s own features have become richer, some plugins may not be required. Plugins used in 2004 may not be required when using Textpattern 4.0.4—which is on the horizon—in 2007. In other words, plugins that plugged feature gaps might be displaced when Textpattern’s own capabilities expand.
Hundreds of plugins have been written. Little has been said about what liberal use of plugins does to a Textpattern site’s performance. By the way, what is liberal use of plugins? Even less has been said about which plugins make serious impacts on a site’s web host! How many plugins is too many? Do they conflict with one another? Does a site become more fragile after exceeding a certain number of plugins?
Clearly, there are challenges—38 pages worth—associated with administering plugins as they are updated and as Textpattern changes versions. This is largely a manual process completely dependent upon a user’s vigilance.
Textpattern’s developers are “doing everything they can” to prevent breakage as users upgrade. Plugins make this more difficult, even though specific rules exist for writing plugins that minimize the risk of problems.
But, here’s the real challenge: with eleven plugins installed and active, where are all the occurences of each plugin’s tags in the templates of the site? How does one locate all of the tags related to plugins and distinguish them from native Textpattern plugins? What if you are managing a dozen Textpattern-based web sites? Imagine how long it might take to “fix” the sites if plugins aren’t updated or compliant with the rules.
The work required to answer those questions is about to begin here. We mentioned a bit about some of the goals this week. Stay tuned for more information as we learn the secrets of applying plugins wisely.
Filed under: Technology
As a starting point for an educated guess on the persisting need for a certain plugin I’d recommend the Recent changes page in Textbook. You will notice that several tags have added capabilities/attributes which are designated by a [4.0.4] label. Some of those additions may reduce the need for a plugin.
I would not expect that a lot of plugins will break due to the upgrade besides those hooking into an admin page (upm_img_popper being among the more prominent ones). For front side plugins providing tag extensions the only notable difference is the newly added “late” parsing of article body and excerpt. As this change was announced in advance, I expect that all plugin programmers had enough time to catch up with that fact, although it only affected a very limited amount of plugins anyhow – extensions for multilingual sites come to mind.
— Robert Wetzlmayr 7 September 2006, 05:20 #