Through the past year I’ve been working on Ultimate Fields 2, the next version of Ultimate Fields, my plugin for custom fields throughout the WordPress backend. At this point there are many open tasks, but there is a lot that is already done, so I feel ready to share some if it with the world.
The decision to start developing a second version of the plugin after only getting to 1.0.3 of the first one was dictated by various factors. Some of them were ideas for the next version, others were things, which I was not too happy about.
The thing, which I dislike the most about version one is that in its beginning it was not supposed to be a plugin. It was not supposed to have an administration interface, as that interface was against my initial idea.
I had and still have major plans for the plugin, but with various things done in a better way, many new ones and some new technology beneath it.
Behind the curtains
I want to quickly explain to you, what is changed in the core of the plugin, both ideologically and technologically, as there are various things which are quite different.
The main culprit for the new version is this library. It wouldn’t be fair to say that the things that I did wouldn’t have been possible without it, but it gave me most of the ideas that you will find in the plugin.
Core vs. UI
As I would explain deeper in another article in the near future, I am a fan of code. My opinion is that many WordPress developers (no quotes here, this includes a lot of the good ones) are too spoiled. I guess the main reason I am still sticking to WordPress is its flexibility, which, sadly, is getting unintentionally abused by those developers. I will really focus on this in an another article, as it is quite a wide topic. For now, let’s just simply put it like this:
I don’t think that it’s good practice to have the definitions of meta data in the meta data of some other data.
Something doesn’t seem completely right about this, does it? When the post is published, I will link it here.
Anyway, this is about the fact that some plugins (yep, including mine) have a section in the administration area, where those custom fields get created. This is easy and allows people with limited experience/knowledge to create custom fields all around the place, allowing them to relatively easy accomplish what they need.
On the other hand, there are people like me – people who know what they are doing, people who have the needed knowledge and need to move their focus on efficiency. For that group, it’s important to have a tool for creating custom fields, but one that allows them to do it for 30 seconds with the keyboard, instead of 5 minutes with the mouse.
Ultimate Fields 2 will have two parts:
The core allows developers to create custom fields through code. It contains all needed containers, fields and helpers for that.
- Administration Interface/UI.
The administration interface allows creating those same things through a dedicated section in the administration area. It also contains the functionality that would allow the values of those fields to be processed before the user gets a hold of them.
I still have not decided if those would be two separate plugins or two distinctly separated items within a single plugin, but this doesn’t matter now.
What matters, and one of my primary goals, is to allow inexperienced and new users to use the administration interface in order to be able to get what the need done, whilst encouraging them to try it the recommended way – through code.
I am planning to continuously release articles, which would teach users how to do this.
Ultimate Fields 2 will initially support the same containers as the first version, allowing fields to be assigned as/to:
- Post meta for pages, posts and other custom post types.
- Term/Taxonomy meta for categories, tags and custom taxonomies.
- User meta for users
- Options Pages for global site settings
The interface of UF2 will also support virtual containers, which can be used as repeater groups, but within various repeaters.
Building upon all fields, which were available in version one, the second version will at least contain a few more fields like:
- Video field
- Relational fields
- Icon field
- Table field
- Nested repeaters (now in the UI too)
Most of the existing fields are getting a complete overhaul, the others – minor ones.
In the first version, I was using a single type of layout for all contaniners. In the second one, all containers will have various options:
- Boxed vs. Seamless: Based on the funcionality within the container and it’s placement, you will be able to select wether there is a box around the continer or not.
- Left vs. top-aligned labels. When the labels are left-aligned, I will be using the old, bult-in .form-table class. When the labels are on the top, I will switch to divs, allowing fields to be floated and have variable width, so that multiple fields can be placed on the same row.
- Description placement: By default, the description/instructions will be shown after the field. However, when the default, table lauout is used, the description will aso be able to be displayed underneath the label of the field.
The last two options are also availabe for repeater groups, as they are also a sort of a container.
Also, I will introduce some new location rules for displaying/hiding a container.
The repeaters will now have the option to include virtual groups, have nested tabs and one of the coolest features: multiple edit modes. This means, that in case there is too much to be edited within a certain repeater, it’s fields can be displayed in a popup.
The administration interface works in a whole new way now. It includes previews of the fields, dependencies, required fields and much more.
Also dubbed as Conditional Logic, this will allow fields to be shown or hidden based on the values of other fields.
Below you can see a video demo of the current state.
I will complete this post with more features and a roadmap in the next couple of days.