Skip to content

Merging Symphony Extensions

Jump to bottom
eKoeS edited this page Jul 19, 2011 · 3 revisions

Reasons behind this writeboard:

  • Quality is better than quantity.
  • The purpose of most extensions is to add new features to existing ones, but in order to do that they often replicate everything that is already implemented in the existing extensions, thus causing incompatibilities.

The concept of extensions exists because it is easier to update them while being independent from Symphony itself. Nevertheless, most of the core extensions aren’t updated regularly and don’t receive enough love. They lack some important features and, as a consequence, people start developing clone-extensions that only differ in a couple of things.

Most of the time, it doesn’t feel safe to use an extension that does an important job but is developed by an user that occasionally update it. It would be much better if there was a list of “certified” extensions that are guaranteed to be updated and maintained over time.

The solution is: instead of inducing users to replicate an extension, let’s teach them to extend existing ones with pull requests and GitHub forks. This is the pillar of open-source communities. As a result, we’ll have less extensions, but better. Users won’t get confused by the large number of extensions doing more of less the same things and there will be some of them that, being certified, will hopefully take precedence over others.

The concept of certified extensions is really important in my opinion as users trust everything is developed and maintained by the team.

Moreover, the current backend interface isn’t build to accomodate a large number of different fields. Sometimes, this list grows too much and make selectbox extremely long and uncomfortable. Less fields means better categorization, which ultimately improves the user’s own experience.

Concerning libraries: we have things like “Cacheable Datasource”, “SymQuery”, etc. that should be made easier to import in your own extensions. I dream of a thing like:

require_once(LIBRARIES . '/util.symquery.php');

or

library_import("SymQuery", 1.0);

It shouldn’t be difficult to implement and will help think of these extensions as something “special”: libraries, of course.

So, below you can find a list of extensions that should be part of future versions of Symphony and support the reason I’ve explained above. Feel free to comment anything as always!

Note: “(?)” means “Not sure about it”

Section Associations Field

Incorporates the following existing extensions: Select Box Link, Reference Link field, Bi-Link Field

  • No more “Show the most $n recent entries” (thanks to the autocompletion and/or a search box like SubsectionManger’s one)
  • It’s not a select box anymore!

Text Box Field

Incorporates the following existing extensions: Text Box, Text Input (core field), Textarea (core field) Output Field, Truncated Textfield, Field: Character Counter Text Input, Field: Character Counter Textarea, Medium Textarea, Number Field, Unique Text Input Field, Email Field, Member Email Field

Date Field

Incorporates the following existing extensions: Flex Date Field, Date and Time, Repeating Date Field (?)

Media Field

Incorporates the following existing extensions: Upload Field (core field), Unique Upload Field, Advanced Upload Field, Image Index Preview, Field: Image Cropper (?)

  • Hide/show the preview of the uploaded file
  • Crop/Resize files of type “image”
  • "Make this field unique" (Unique Upload Field)

Choice Field

Incorporates the following existing extensions: Select Box (core field), Tag List Field (core field), Enhanced Tag List Field, XML Select Box (?), Check List Field (?), Unique Checkbox Field (?)

  • Choose between: radiobuttons or single selectbox (single choice), checkboxes, multi select-box or text-input+taglist (multiple choices).
  • Fetch from either a static or dynamic XML source
Clone this wiki locally