As the title says, I have a huge question to ask. One that really needs your input and will dictate the direction of the next release.
What I need it feedback on use case examples of DBT. I built DBT to be extremely versatile however I don’t think that I manage to get it right. While it can be worked to do some pretty cool stuff, it takes way to much energy to do.
So, I want to narrow down its feature set to be inline with what the majority of users are actually doing with it. There’s no point in maintaining features sets that will never be used so rather spend my time developing it around what most people will find useful.
So please, tell me in the comments what your main need for DBT is and help me out.
I have been working on cleaning up DBT 0.4 to get it up to scratch for the current and future versions of WordPress over the last few weeks. It have been a real eyeopener with regards to how much has changed in both WordPress and my development styles since I first released DBT.
It in this that I find it a near impossible task with my limited time and the amount of work to do, to convert it.
So I have decided to stop development of Db-Toolkit in the 0.x track. This doesn’t mean that DB-Toolkit will cease to exist. It merely means there won’t be a v0.5. I will still do minor bug fixes though or at least guide you in finding the problems.
I have started working on and with the Pods Framework and I’ll be shifting my attention there. I have big plans to bring much of what DB-Toolkit has to offer to Pods and much of what Pods has to offer to DB-Toolkit v1.0. Yes. I’m still going to work on v1.0 so DB-Toolkit is not dead! just the 0.x track.
V1 is to be a merger of what Pods offers in terms of working with and extending custom post types and taxonomies, and what DB-Toolkit does wit working on separate data sources (see post types vs tables). The thing here is that v1 will not be compatible with 0.x since the whole fieldtype structures and configurations are different. It will be a new product. merging the power of Pods and the flexibility of DB-Toolkit.
Please feel free to comment or ask questions in the comments.
I have started on the reduction of field type. It’s not a loss of functionality though. It more a merger of categories.
For example, the single line text, paragraph, URL and email are now a single type with a selector for function.
This makes the selecting of types much faster and easier to manage.
You may have noticed that the forms in DBT use Bootstrap, but most of the other components like tables and dialogs still use jQueryUI.
The intention for v0.4 is to have all these converted to bootstrap. There sill be a configurable option to disable bootstrap inclusion so that you can pull in your own style so you wont be bound by the default theme.
And, speaking of themes, DBT will have its own customised bootstrap theme. I despise the default bootstrap theme, not because its bad, (it’s great) but because WAY to many people stick to the default and I don’t want DBT to be yet another generic bootstrap thing. I’ll be going a little more towards the “flat” craze with less roundyness (but not square)
The bootstrap styles will be for frontend embeded interface, not wp-admin interfaces as I want to confirm just a bit to WordPress styling… just a little.
The benefits here is that there are many more themes coming out based on bootstrap, and this would allow your interfaces to integrate into your themes perfectly. (provided the theme designer didn’t change to much)
I was hoping for the official release of bootstrap v3 (https://github.com/twitter/bootstrap/pull/6342) but I’m not sure how much longer that will take and I can really change when its out.
I’ll post some screen of interface examples when I get time.
One of my continuing concerns with DBT is ajax. When I initially wrote DBT, I didn’t know much about how WordPress did ajax. Since then, I have learned much and realize just how messed up it is.
DBT was initially built as a plugin to my own CMS called Dais. I wrote it in 2001 since I couldn’t find anything I liked (WordPress was still b2 back then). After many years of great performance, Dais started showing its age and maintaining it to stay with the times required way to much work. So I ported it to WordPress. Continue reading
A sort of sneak peek at the UI changes coming in v0.4
I have been asked a few times why don’t I use Post Types for storing data or why don’t integrate them in to DBT.
To answer the question take a little bit of explaining the purpose of DB-Toolkit. So here goes my attempt to do just that.
DB-Toolkit is a way to add database abilities to WordPress, not extend it’s current structures. Post-types have a set structure and fields. To extend these fields, you would use postmeta data or taxonomies (tags, categories etc..). These a little bits of information with a key value structure stored in a separate table. Continue reading