Could we feasibly see unlimited CFs in 2017? :)

maverick · 2017-02-13 17:22:11

Destry wrote #303987:

We could argue some things should go without saying in this community, but neither should we assume, I guess.

I apologize Destry if I was stating an unspoken understanding. I just wanted to emphasize the long term for me outweighs the short term.

maverick · 2017-02-13 17:39:18

Bloke wrote #303990:

The groundwork has been laid. In terms of storage, the meta store can hold arbitrary meta data about any other table. The hard part is the other stuff: the UI and tags.

To borrow a phrase I hear now and again, Awesome sauce!

Bloke wrote #303990:

The hard part is the other stuff: the UI and tags.

Imagining aloud:

Given the current admin design and layout, perhaps a new CF tab in the presentation grouping of tabs, like sections, pages, css, etc.? A list of custom fields that have been added, with the ability to see and edit the details. Then a button/link to add a new custom field. Once in add mode, you can pick what tab the custom field shows up on – write, image, link, a smd_tabber page, etc. Then if possible, perhaps pick the specific pane/panel/section, to add it too. Then (and I presume now a CF plugin would take over from the core), the settings for the new CF – textbox, radio button, etc. Click save and you are good to go.

Whether that is workable or desirable . . .

Another, even more user friendly, option might be the ability to go to a tab – say the write tab. Click an “edit tab” button. This then gives a layout of the page with the various subgroupings. Then click on a group and have the option to “add new field”.

Then again, maybe neither option is doable or desirable. Just thinking.

bici · 2017-02-13 18:00:01

Would CFs be arranged/grouped by Sections? That is each Section would have CF unique to it. Would this help in the layout?

colak · 2017-02-13 18:04:23

bici wrote #304002:

Would CFs be arranged/grouped by Sections? That is each Section would have CF unique to it. Would this help in the layout?

Good idea but what happens to those CFs which are used in more than one section? Maybe an option would be to add a preference on a per CF basis to appear everywhere OR just in a section. Jquery could easily help with that.

bici · 2017-02-13 18:19:26

Would making each category unique help?
i.e. in an Events Section i would name the CFs event_date, event_image, event_subtitle, etc

And in another section say Menu i would name the CFs menu_date, menu_image, menu_subtitle, etc even having addition ones such as menu_recipes, menu_full etc

maverick · 2017-02-13 18:39:38

bici wrote #304005:

Would making each category unique help?
i.e. in an Events Section i would name the CFs event_date, event_image, event_subtitle, etc

And in another section say Menu i would name the CFs menu_date, menu_image, menu_subtitle, etc even having addition ones such as menu_recipes, menu_full etc

From a data entry stand point, when you go to the write tab, how would that work?

It definitely makes sense if CFs are only shown if relevant. From a work-flow stand point, if they are specifically tied to a section:

Wouldn’t you need to select your section first, before writing anything, and before saving it? Vs. the current just write. Worry about the details later.

And what if you want to change the section after you have saved it and perhaps added some section only CF data. Is that CF info deleted? orphaned?

bici · 2017-02-13 18:52:50

maverick wrote #304006:

From a data entry stand point, when you go to the write tab, how would that work?

It definitely makes sense if CFs are only shown if relevant. From a work-flow stand point, if they are specifically tied to a section:

Wouldn’t you need to select your section first, before writing anything, and before saving it? Vs. the current just write. Worry about the details later.

And what if you want to change the section after you have saved it and perhaps added some section only CF data. Is that CF info deleted? orphaned?

CFs show up as fields when one is editing/adding to a section

You would need to be in the section to write, don’t see that as a deal breaker, right now you need to be in section to edit.

changing Section name would cause CFs to disappear. too bad too sad.

i would suggest one take a look at the free EECore to see the way CFs are handled. it might provide some hints for TxP to proceed.

i am not a dev so I have no clue of the issues on the backend. just a user.

p.

phiw13 · 2017-02-13 22:50:32

jakob wrote #303999:

For tips, take a look at wet’s plugin template for adding fields to the user profile.

Thanks for the pointer! It is even easier than I thought it would be.

Bloke · 2017-02-13 23:20:57

maverick wrote #304001:

Imagining aloud

No need to imagine that bit! When I said ‘UI’ I should have been clearer, sorry. The (in need of merging with dev) custom-fields branch has a new panel Admin->Custom fields. In there you can add and edit any custom field for any content type that we permit out of the box. That includes articles, images, links, files, comments, sections, users, and categories. I think that’s it. But there are callbacks that allow plugins to alter or extend what content types are available.

Custom field data types are provided as a dropdown. Usual crew: textbox, integer, decimal, textarea, select list, radio set, blah blah. Again, callbacks allow plugins to augment or alter the available data types and map how they are represented in SQL. If there are options for people to choose from in radio/checkbox/select lists, you set them there. Unlike glz_custom_fields which mainly uses textbox (and occasionally text) fields, Textpattern figures out the most efficient storage methodology and creates the appropriate tables on the fly if you don’t currently have a table for the ‘type’ that best fits the intended data. That, by the way, was a bitch to write and get working!

Now, there’s one major caveat here: if you change a type, your data will be modged to fit into the destination type. For some data, it’s no problem. For other types this will either mean it’ll be truncated or lost. So think before you assign or alter a type. Or take a backup beforehand, tweak the .sql file you download and reupload it into the new type’s table.

All that is done and working, as far as I can remember.

Now, there’s one other field that the core doesn’t use: family (think grouping). It’s a completely freeform field. A plugin could hijack that to group fields, or you can (out of the box) type whatever you want against each defined field. That means, for example, you can define a bunch of fields and “group” them by giving a bunch of related fields all the same name: say, a Txp Section. I stress again here, core doesn’t do anything with that information in terms of tweaking the UI, but a plugin could use that to hook into the Section dropdown on the Write panel so it alters the available fields on change. Up to the plugin. My thinking is that it’s out of scope for the core to dictate what you want to use the fields for — they’re just for you to store “stuff” in and associate that stuff with a core content type: that’s it. But the facility is there for some plugin to narrow it down and make a concrete implementation for using the ‘family’ feature.

With all that said, the next bit is the UI in terms of what you see on the individual panels: Write, Images, Files, Users, etc. Mainly I envisage that’s a drag ‘n’ drop feature, remembering what fields you dropped where on each panel. Again, nothing to stop a plugin going further (think about the above Section example) so the Write panel could have a different layout depending on the chosen Section, altering it on the fly. That’s not core functionality, though.

There’s also the behind-the-scenes SQL, which needs to start doing JOINs instead of just expecting all the data to be in the same table. That’s hardcore stuff that we need to manage carefully for backwards compatibility. Existing field content from the “main 10” is migrated on upgrade, that’s no problem. glz_cf data will need to be massaged first, but I’ll worry about that another day. But fashioning queries to efficiently get the data into our on-page globals is where the trick lies.

And then there’s tags. Expanding the <txp:custom_field> and associated conditional tag to be able to grab fields and display appropriate content. Even appropriate input widgets (maybe) based on the type of data expected. Who knows, maybe that’s plugin territory.

Bottom line is that the facility to define the CFs and store them is done (barring any bugs we find). How we allow people to enter data into those fields and then extract the info to display it is not. When I get round to merging dev with the custom-fields branch, I’m hoping that more people start to play with the back-end as it is now and we can then start to work out how to build core functionality to allow each panel to have access to the meta store, and how to efficiently expose that data to the website.

Last edited by Bloke (2017-02-13 23:26:22)

maverick · 2017-02-14 13:17:12

Bloke wrote #304010:

No need to imagine that bit!

Wow. I clearly did not realize how far along you were. This sounds great Bloke!

Last edited by maverick (2017-02-14 13:32:01)

bici · 2017-02-15 04:20:29

yabba dabba doo!

Destry · 2017-02-16 09:14:52

maverick wrote #304000:

I apologize Destry if I was stating an unspoken understanding.

No apology necessary. Always good to be sure. I certainly wouldn’t intend for anyone to do multiple developments of the same thing. I’d suspect Bloke would have that under control, and indeed he does. ;)

Textpattern CMS

Textpattern CMS support forum

#25 2017-02-13 17:22:11

Re: Could we feasibly see unlimited CFs in 2017? :)

Destry wrote #303987:

#26 2017-02-13 17:39:18

Re: Could we feasibly see unlimited CFs in 2017? :)

Bloke wrote #303990:

Bloke wrote #303990:

#27 2017-02-13 18:00:01

Re: Could we feasibly see unlimited CFs in 2017? :)

#28 2017-02-13 18:04:23

Re: Could we feasibly see unlimited CFs in 2017? :)

bici wrote #304002:

#29 2017-02-13 18:19:26

Re: Could we feasibly see unlimited CFs in 2017? :)

#30 2017-02-13 18:39:38

Re: Could we feasibly see unlimited CFs in 2017? :)

bici wrote #304005:

#31 2017-02-13 18:52:50

Re: Could we feasibly see unlimited CFs in 2017? :)

maverick wrote #304006:

#32 2017-02-13 22:50:32

Re: Could we feasibly see unlimited CFs in 2017? :)

jakob wrote #303999:

#33 2017-02-13 23:20:57

Re: Could we feasibly see unlimited CFs in 2017? :)

maverick wrote #304001:

#34 2017-02-14 13:17:12

Re: Could we feasibly see unlimited CFs in 2017? :)

Bloke wrote #304010:

#35 2017-02-15 04:20:29

Re: Could we feasibly see unlimited CFs in 2017? :)

#36 2017-02-16 09:14:52

Re: Could we feasibly see unlimited CFs in 2017? :)

maverick wrote #304000:

Board footer