Textpattern ‘Elements’

Just added to crockery (the Textpattern CMS 4.1 branch) is a new feature called ‘Elements’.

In a nutshell, Elements are like core plugins. They’re included as part of the Textpattern CMS distribution, and thus have no install or uninstall mechanism, but can be turned on or off like plugins.

The point is to distance certain code from the core, help make the code more modular, and make it easier for users to customize a Textpattern CMS installation by disabling features they don’t need.

Disabling an Element means less code is loaded each time a page is viewed. For site owners, that means lower memory overhead, faster runtime, and fewer potential bugs and security issues. For developers, it means more modular code that’s easier to test, and easier for plugins and elements alike to hook into core functions.

A few other details of note

  • Elements are always loaded from a file (in textpattern/elements), the code isn’t stored in the database
  • The list of elements is stored in a different table, and shown on a different panel (admin section, elements)
  • Elements can be enabled and disabled, but certain important elements might be marked as ‘required’, and thus always active.
  • Elements are only loaded when required (via the event/step fields)

The first Element off the block is the file download manager. All of the code relating to file downloads has been moved to textpattern/elements/". Though the Element UI isn’t working yet, it’s now possible to disable the file download code (front end, admin side and tag handlers).

The tentative naming convention for elements, beginning with the file download manager, is:

txp_* for things that would previously have lived in textpattern/include/

tag_* for code that would previously have lived in taghandlers.php

pub_* for things (other than taghandlers) that would previously have lived in publish.php or textpattern/publish/ (things like feed generation code, the comment POST handler, CSS, etc).

Comments

  1. A small step in mankind – a big one for TXP :)

    Not beeing a programmer i bleieve this a great solution and a very creative as well. THX!

  2. When I read this article’s title I would have never thought an “element” had anything to do with a plugin. Why not just call these “Core Plugins” instead of introducing this unintuitive moniker?

  3. They behave like plugins but they’re not. They’re actually Modules.

    If not elements, then maybe “modules” would be a better word. But definitely not plugins since it would be confused with user plugins.

  4. So, this means I can finally add the section/category/title hack to an element file instead of modding the TXP files after every upgrade?

    Thank you, thank you, thank you, thank you, thank you!!!

  5. I see plugins more as scripts. And this seems more like what I think of as a plugin.

    However you call it, it is a nice addition.

  6. I’m not quite clear on something from the description in this post. Will there be a way to add, remove, and turn on/off community-developed Elements? I could see this being very useful for major functional upgrades, such as forum and e-commerce scripts that plug right into the core but are maintained separately.

  7. The primary goal of Elements are described in the post:

    They’re included as part of the Textpattern distribution, and thus have no install or uninstall mechanism, but can be turned on or off like plugins.

    The point is to distance certain code from the core, help make the code more modular, and make it easier for users to customize a Textpattern installation by disabling features they don’t need.

    The way to go for extending Textpattern, is to go with plugins. Elements might be useful for developers who wish to maintain private branches of textpattern for their own projects, but the focus is not on providing an “end-user targetted” extenesibility mechanism, as that would result in duplicating the plugin-possibilities/-functionalities.

Commenting has expired for this article.