Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Situation report for Textpattern 4.6 and beyond
philwareham wrote #279469:
I’ve got to put the new grid layout into the trunk soon, I’ve got it on my local development build at the moment.
That’ll allow us more flexibility in how fields are arranged on the various columns. Maybe we can work something out using jQuery UI sortable to allow users (with certain permission levels) to re-arrange fields and panels. I need to play around with some structural stuff once I’ve put the new grid in, and see if it’s feasible.
I’m snowboarding next week but it’s on my list of to-do stuff after that. There’s a substantial Hive theme update waiting to be rolled into the CMS too. Plus minor updates to Remora/Classic so they fit our latest design patterns.
I’ve had four months working solid on a Drupal site so I need a weeks break first to regain some sanity.
Being able to allocate different custom fields to different sections and have order of fields on the Write page fully customisable would bring ExpressionEngine levels of flexibility to Textpattern which would be amazing.
It would make custom data modelling for more complex sites possible, as well as making the creation of properly marked up schemas much easier as each element of the schema could be separated out into it’s own custom field, without worrying about running out of CFs for more complex schemas.
It would make Textpattern a much more content focussed CMS and take it leaps and bounds above WordPress in terms of out-of-the-box core functionality.
Offline
Re: Situation report for Textpattern 4.6 and beyond
Yep. It’s gonna be hard work but that’s the hope I have.
Offline
Re: Situation report for Textpattern 4.6 and beyond
springworks wrote #279473:
Being able to allocate different custom fields to different sections and have order of fields on the Write page fully customisable would bring ExpressionEngine levels of flexibility to Textpattern which would be amazing.
wow!. sweet.
+1
…. texted postive
Offline
Re: Situation report for Textpattern 4.6 and beyond
etc wrote #279471:
Sections are already overcharged, wouldn’t introducing some
Prototypeentity be a better choice?
Please explain. I’m all ears.
My original, albeit sketchy, plan was to allow you to arbitrarily assign custom fields to a ‘group’ with a name of your choosing. It’s nothing more than a varchar field at the moment to avoid yet another join, albeit not very 4NF. That gives you the ability to decide to output the fields in any grouping you see fit. You could even make your own delimited names up if you like and put fields in some/arbitrary/hierarchy which you could split/play with, or put fields in more than one group. Again, not ‘proper’ database stuff with link tables and all that, but doing it properly could limit your creativity :-)
The thing I hadn’t quite figured was how to sensibly make use of it in core. One option is that if you give a CF a group name that matches a Section in your site, that field automatically gets displayed on the Write panel when that section is selected. Perhaps an option to turn that off, too. But I wonder if that’s a step too far. Especially given that a few lines of plugin code hooked into the article_ui.section callback will be able to do that and give you more flexibility (e.g. you might want to link them to categories too: a plugin would be able to do that far more effectively than adding a static option in the core Prefs). Plus, snice CFs are planed to work across content types, where does that leave File or Image CFs? Link them to category by default? Or not?
It starts to get a bit messy and, perhaps, limiting. So I’m wondering if there should just be a way to arrange/group the fields in some arbitrary way that core does not use but plugin authors could. A single group field achieves that, albeit inelegantly, and leaves implementation and imagination to plugin authors without tying us down to prescribed functionality that might not be to everyone’s tastes.
But, as I say, that was just a rough idea. If you have a better notion, then please share it.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Situation report for Textpattern 4.6 and beyond
Bloke wrote #279486:
One option is that if you give a CF a group name that matches a Section in your site, that field automatically gets displayed on the Write panel when that section is selected.
I like your ‘group’ idea very much, but wouldn’t use Sections for what you describe above, since they play already many other roles (page, style, front page, search, syndication, …). I would rather create another mandatory entity (call it Prototype) that would be assigned to each content unit (article, image, …). So, a typical article could be derived from a prototype containing Title, Body, Excerpt and so on. Another article could have another structure (prototype), for example no Excerpt, or multiple Titles (e.g. for multilingualism). An image has yet another prototype (source, dimensions, …), a video another one, and so on. Prototypes could be extended by the usual inheritance mechanism.
Of course, this is to much change for 4.6, but you could start with CF for articles. Actually, your CF ‘groups’ seem to be extensions of the default article (image, …) prototype, but I may tell nonsense as well. Great move, anyway!
Offline
Re: Situation report for Textpattern 4.6 and beyond
I may not be understanding the issue (especially the more complex tech stuff). But in my simplistic experience I would want Custom Fields to be available at the Article publishing stage, and as part of a Section. So Home, About, Movies, Default etc could all have different custom fields or could share a default set.
Does this make sense? Is this the direction being planned?
…. texted postive
Offline
Re: Situation report for Textpattern 4.6 and beyond
bici wrote #279488:
I would want Custom Fields to be available at the Article publishing stage, and as part of a Section. So Home, About, Movies, Default etc could all have different custom fields or could share a default set.
Does this make sense? Is this the direction being planned?
Sure, it makes sense (for me), but images, files, users and other units are not organized in sections.
Offline
Re: Situation report for Textpattern 4.6 and beyond
bici wrote #279488:
I would want Custom Fields to be available at the Article publishing stage, and as part of a Section. So Home, About, Movies, Default etc could all have different custom fields or could share a default set.
That was my thinking. Whether the CF’s automatically link to a Section or whether that is something we leave up to plugin authors is a decision we can make later.
I think what etc seems to be referring to is approaching things from another angle, i.e. custom content types. So for example you might create a ‘Movies’ content type by combining an article body (which you might label ‘review’), a Title, an Excerpt, three Image fields, a custom field called Trailer which can contain a YouTube link, and a ‘Star rating’ custom field. So when you want to write a review, you (somehow?) specify that’s the type of content you’re going to create and your Write panel shows only those fields. Please correct me if I’m wrong here, etc.
The ‘somehow’ in the above paragraph is the bit I don’t quite get because you still have to tie the output to a URL and you still need to be able to choose which Prototype you want to create content for. With such varied content and no commonality, things like article lists become interesting to render as you need lots of conditionals on the public side, and some clever mechanisms on the admin side to be able to manage the content. As it stands, with current adopted conventions, you know there’s going to be one body field and one title for every article at minimum, which makes your templates easier (if less flexible) to manage, and makes the admin side simpler.
It usually comes down to convention. If we can come up with a suitable convention that appeals to the majority of users who publish content, then a lot of the complexity can be taken out of the UI. That can make the code simpler, or lower the learning curve, or offer power for advanced content creation, but not usually all three at once.
Making a CMS infinitely flexible can become a chore to maintain because you need to spend days configuring everything up front. Having a few pre-defined conventions (e.g articles are the centre of the Textpattern universe) limits flexibility to some degree but gets you out of the blocks faster. Striking the balance is what we need, as ever.
And, as etc. says, Sections are article specific, which is kind of a spanner in the works, and why I’m on the fence about allowing CFs to link to Sections out of the box — it breaks convention across the content types.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Situation report for Textpattern 4.6 and beyond
etc wrote #279489:
Sure, it makes sense (for me), but images, files, users and other units are not organized in sections.
I can see file types being added as options to Custom Fields : Files , Images, Select Dropdowns, Radio buttons etc.much as EE does. But I don’t see how users applies in Custom Fields
…. texted postive
Offline
Re: Situation report for Textpattern 4.6 and beyond
bici wrote #279491:
I don’t see how users applies in Custom Fields
Profile pages? Like smd_bio. you might define User custom fields this way:
- address-line-1
- address-line-2
- city
- state
- postal-code
- phone
- …
Or:
- Department
- Role / Job title
- Manager
- …
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Situation report for Textpattern 4.6 and beyond
bici wrote #279491:
I don’t see how users applies in Custom Fields
Currently, txp users have a very limited fields collection (login, real name, etc) that you might want to extend with date of birth, address, other info à la smd_bio. These would be CF for users.
Offline
Re: Situation report for Textpattern 4.6 and beyond
Bloke wrote #279490:
That was my thinking. Whether the CF’s automatically link to a Section or whether that is something we leave up to plugin authors is a decision we can make later.
Gee I hope there would be no need for plugins for CFs. They should stand on their own. The user creates the CFs for each Section and can assign CF types: Images, Files etc. This should make CFs infinitely useful across Sections. And shared across Sections. But yes if a plugin author wants to engineer the plugin’s to extend Cfs …well sure.
…. texted postive
Offline
Re: Situation report for Textpattern 4.6 and beyond
etc wrote #279493:
Currently, txp users have a very limited fields collection (login, real name, etc) that you might want to extend with date of birth, address, other info à la
smd_bio. These would be CF for users.
I understand. I agree. It’s not a CF type but another list of CFs for the Admin area: i this case USERS. In this case permissions levels could also be baked in at the USER level without the need to have the bot_privs plugin.
…. texted postive
Offline
Re: Situation report for Textpattern 4.6 and beyond
bici wrote #279494:
Gee I hope there would be no need for plugins for CFs.
Why not? Allowing plugins to jump in and alter things is the spirit of Textpattern. At the moment, the CFs would work exactly as they do now, it’s just that instead of only text fields limited to 255 chars, you can choose different types of input. Selects, radios, textareas, blah blah.
Until we figure out how this’ll work at a UI level, I don’t want to think about enforcing a custom field lodged against an article to have an implicit link to a particular Section. You might want the same field (e.g. “YouTube link”) to be applicable across a few Sections, for example. Plus, it complicates the interface for configuring them because no other content type has the concept of a Section, so you need a special type of UI workflow for articles, which is something I’d like to try and avoid. Hence my notion of a freely editable ‘group’ for each field. No implied structure. No implied meaning. You can do with it what you like and apply your own meaning.
If you want to make that link between sections as a site admin, you can do that with five or ten lines of code. We might even offer some officially sanctioned scripts that do this kind of thing, who knows. The point is, if you as a content creator want to link the CFs to Section AND category, we shouldn’t limit you by enforcing the Section-CF link for articles.
I’ll just share an example of the kind of convention I mentioned in my previous post. The way CFs are defined in the database at the moment, they have a data-type which is the field type in the database. But to expose that level of control to most users is unrealistic: who knows whether it’s better to store something as a Text field vs a Varchar(511)?
So, while Textpattern deals with this kind of thing as its currency, you, the site designer won’t. In the code is a function call with a simple map that links a ‘widget’ with a suitable representation for that type’s values. For example:
- Radio button -> boolean
- Select list -> varchar
- Text input -> varchar
- Radio set -> boolean
- Text area -> Text
Textpattern manages the tables for you under the hood and stuffs the content in the most appropriate table for you, based on the type of content you want to store, without being wasteful. There are only 3 types of content in the above list — boolean, varchar and text — so you’d have three tables storing relevant content for each field.
So, out of the box, I’ve abstracted away the decision making process into a set of reasonable UI choices. Of course, that won’t suit everyone which is why before this list is rendered to the screen, plugins get to play. A plugin could alter one of the types. Maybe you want text areas to be stored as varchar(511) instead of the relatively expensive Text field type. No problem: three lines of code to make the change and Txp does the rest on your behalf. Or if you wanted to add a new type of field entirely, so be it. You add the widget type to the list via the callback, tell it the database field type to store it in, and write a couple of functions to tell it how to a) render it to screen, and b) what to do with the data prior to storage (if it’s significantly different from the routines present in core), then Txp does the rest.
I’ve got the primary callbacks in place for the mappings. The ones regarding rendering UI widgets, validation and pre-processing will come when the UI parts are realised. But the point is, I’ve chosen to adopt a convention which not only simplifies administrator’s lives and simplifies the code (and database) somewhat by taking away some of the decision-making process, it allows plugins to take it to whatever level you need.
P.S. Whether all this works in practice remains to be seen. It might just all be hot air :-)
Last edited by Bloke (2014-03-05 23:00:46)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Situation report for Textpattern 4.6 and beyond
Bloke wrote #279490:
I think what etc seems to be referring to is approaching things from another angle, i.e. custom content types. So for example you might create a ‘Movies’ content type by combining an article body (which you might label ‘review’), a Title, an Excerpt, three Image fields, a custom field called Trailer which can contain a YouTube link, and a ‘Star rating’ custom field. So when you want to write a review, you (somehow?
) specify that’s the type of content you’re going to create and your Write panel shows only those fields. Please correct me if I’m wrong here, etc.
You are absolutely right. The site admin creates a ‘Movie’ prototype, and authors create instances of it. Specifying the content type could be just a matter of clicking on ‘Movie’ in ‘Content’ tab.
The ‘somehow’ in the above paragraph is the bit I don’t quite get because you still have to tie the output to a URL and you still need to be able to choose which Prototype you want to create content for. With such varied content and no commonality, things like article lists become interesting to render as you need lots of conditionals on the public side, and some clever mechanisms on the admin side to be able to manage the content. As it stands, with current adopted conventions, you know there’s going to be one body field and one title for every article at minimum, which makes your templates easier (if less flexible) to manage, and makes the admin side simpler.
Well, no body field — no body output, caveat emptor. We have already this problem with <txp:custom_field name="not_existing" />. Basically, everything (body, excerpt) becomes a custom field. But every content instance needs some url identifier, of course. Well, let’s sleep on it.
Offline