Situation report for Textpattern 4.6 and beyond

etc · 2014-03-08 20:15:13

gaekwad wrote #279577:

Oleg, have you ever thought of applying to the Textpattern development team?

Sure I had (not you?), I also dreamed to be a rock star. :) Thanks, but, seriously, an enthusiastic amateur without any computer science background that I am, couldn’t contribute to txp any more that I currently do. Know what? I still don’t know how to submit a patch on google code! The devs are smart to consider my proposals, but most of time they (proposals) are not realistic or simply naive. But this will not stop me from making new ones. :)

Bloke · 2014-03-08 23:11:50

etc wrote #279567:

representing content_type by a number yields a high degree of coordination between plugin authors to avoid collisions. Maybe article,image,smd_user and so on is more practical.

You may be right. I toyed with both, and to be honest can’t remember why I chose a number over a string. Think it might have been speed, but I’m a little hazy on how well MySQL performs in that arena. My gut feel is that numbers are gonna be faster to lookup and more efficient to index than strings, but I might be wrong.

That said, you’re probably right. The simple function with callback that presents this to the world and allows you to add your own content types would find it pretty hard to stop people stomping on each other’s numbers, regardless that having more than one plugin altering custom fields might result in unpredictable behaviour. So perhaps it’s safer all round (and less obfuscation) to just have it as a string so there’s no ambiguity. In terms of 4NF, it’s no worse than a number in the current schema! Perhaps if I had a mapping table that mapped the numbers to their content types instead of just some constants in the code, it’d make sense, but that’s another join for no apparent gain, since they’re not gonna change all that often.

I think you convinced me to convince myself to change it, thanks :-)

etc · 2014-03-09 21:49:29

Bloke wrote #279600:

My gut feel is that numbers are gonna be faster to lookup and more efficient to index than strings

Might be, but now, what is the group role? Isn’t it intended to be used for filtering, on the core or plugin level? If so, we are already running at a string speed. Or are they only pertinent on the admin side, and the core tries to extract every meta for a given content type on the public side? I’m a bit lost here.

Actually, I can’t stop thinking that merging txp_image, txp_file, txp_etc tables in one txp_content table containing just an id and some group (image, file, etc) fields, would unify all these content types and reduce the number of functions both admin and public sidewise. Please stop me with some killer argument. :)

Bloke · 2014-03-09 22:32:27

etc wrote #279610:

what is the group role? Isn’t it intended to be used for filtering

Just arbitrary subdivisions, per content type. We’ll probably skim over the core using it at all for now, and leave it up to plugins to use. That means they can decide if the event names are for public side, admin side or both. There’s no implied taxonomy here. It’s just:

You create a custom field.
You assign it to a content type (which is now a string).
You can give it an event name of your choosing. It could be used to group them within that content type, or add some kind of label, or be used to tie custom fields across content types.

That last one about tying fields to multiple types is a stretch. But in the absence of being able to create one custom field that can be used for more than one content type, it might enable a plugin to offer that facility by, for example, hooking into the rendering portion of the code and displaying the same field on the Images and Write panels if they had the same event name assigned.

Of course, that brings up a good point. If you do want to share fields across content types, what’s the best way to do it:

The core shouldn’t allow it out of the box. So, just like categories, if you want the same field for more than one content type, you create a second field. Neat, clean, isolated, no dependencies, less likely to break other content types if someone modifies a field, but an admin hassle for users to maintain multiple fields if they want this facility.
Permit the content_type field to hold multiple, delimited items, e.g. article, image. Feels messy and non-SQLish.
Add a table or two (which therefore adds one or two joins) that maps a field to N content types. In which case, going back to using an ID for the content_type field makes sense, with the types defined in a separate table (of which the core has a handful pre-defined). Collisions would be avoided by making that ID an auto-increment so you have to ‘register’ your content type first if you wish to extend the core types, and making sure that all custom types start at, say, 100+ in case we ever need to extend the core ones in future.

I guess it comes down to whether we think that sharing custom fields is worthy of the coding and/or potential retrieval overhead. If it’s perceived that only a fraction of people would use such a feature then option (1) is the way to go, with the fallback that people (a.k.a. plugins) could use the event field to simulate cross-type fields. If we think that the ability to assign the same field to multiple types is important, then (2) or (3) (or any other?) implementation should be investigated, with increased code complexity, but increased flexibility.

At the end of the day, the actual value data is stored in the same table anyway, regardless of which content_type the particular field is assigned — if it’s defined as a yesnoradio then it’s stored as a boolean/int value no matter what content_type it is assigned. So as far as the public side is concerned, it extracts the values and presents them as part of the content type’s tags. It only really affects admin side management of fields.

Anyone got any gut feelings on whether multiple fields across types is desirable, or a waste of effort?

Gocom · 2014-03-10 11:47:13

Bloke wrote #279613:

Anyone got any gut feelings on whether multiple fields across types is desirable, or a waste of effort?

Could be. It wouldn’t have any performance impact either — it’s just for the admin UI. That said, if you don’t have content registry, how do you register content types…? By having to keep plugins loaded for that type and the value is created on runtime, but is that ideal.

If you want to limit the content-types to events, you can merge content-type definitions with permissions table (event idx). That said, also permissions will require few tables, unless you identify privileges with a lowest/highest user-level integers.

Add a table or two (which therefore adds one or two joins) that maps a field to N content types. In which case, going back to using an ID for the content_type field makes sense, with the types defined in a separate table (of which the core has a handful pre-defined).

If implemented, it should be done with this. It would require the definition of content-type and then the mapping of content-type and the field; two tables.

Collisions would be avoided by making that ID an auto-increment so you have to ‘register’ your content type first if you wish to extend the core types, and making sure that all custom types start at, say, 100+ in case we ever need to extend the core ones in future.

There is no need. We would just insert new rows to the ‘content_types’ table and mark the owner as ‘core’ making them not deletable.

We aren’t going to create fields itself to existing sites of course, and if we are, we are going to use the same code as everyone else instead of hard-coded constants and we don’t need persistent IDs. We will also use the content_types registry as everyone else.

etc · 2014-03-10 13:05:02

Bloke wrote #279613:

Permit the content_type field to hold multiple, delimited items, e.g. article, image. Feels messy and non-SQLish.

Gocom wrote #279620:

It wouldn’t have any performance impact either — it’s just for the admin UI.

Don’t we have to check content_type (through meta_id) when retrieving value from txp_meta_value_ tables public-side for, say, an image with a given content_id?

Destry · 2014-03-21 11:03:56

Now we’re talking. Well, you guys are talking. And that’s great.

I’d like to just add this…

Whatever happens, please don’t use the term “prototype” or “silo” in any official capacity — Txp semantics, UI dialogue, etc. They are less than ideal.

“Prototype” is not a bad word, per se, but it’s very indicative of something unfinished. Not live. Not production. And it gives a completely different notion of what is being talked about, because most people already have an idea of what a prototype is (and it’s not an article model). If what you are talking about is content types, then use “content types” — plain as day, and everybody knows what that means — and the world will understand you. If that’s technically impossible (e.g., because it’s two words), then use “model”, which is the next best thing because a model can represent something both in development and in production, unlike “prototype”.

“Silo” is a negative word, a stigma word, and about the worst word you can mention in the content strategy world, for many reasons. It’s the de facto word to mean content or information that is penned-up and cut-off from everything else, and thus not as valuable as it could be. You do not want to say “silo” about anything, anywhere, if you want more Textpattern adoption.

Let’s remember how long we’ve suffered with semantic flub-ups like “Forms”. Don’t make the same mistakes. Always use the most straight-forward, logical, and positive labels you can, if you want to help improve the UX.

philwareham · 2014-03-21 11:11:21

Textpattern ‘custom field kittens’. The internet loves kittens, right? :)

gaekwad · 2014-03-21 12:33:10

Destry wrote #279872:

Whatever happens, please don’t use the term “prototype” or “silo” in any official capacity — Txp semantics, UI dialogue, etc. They are less than ideal.

+1.

gaekwad · 2014-05-15 08:41:36

Rather than start a new thread for this, I’m going to throw this out for consideration/discussion: is the release of 4.6 a good time to turn development to GitHub instead of Google Code?

Genuine question, not trolling or antagonising.

Edit: missed a word.

Last edited by gaekwad (2014-05-15 13:29:40)

dos · 2014-05-18 12:42:07

gaekwad wrote #280822:

Rather than start a new thread for this, I’m going to throw this out for consideration/discussion: is the release of 4.6 a good time to turn development to GitHub instead of Google Code?

Genuine question, not trolling or antagonising.

Edit: missed a word.

I am not a coder. But from the user perspective Github is quite easy to understand and very common as well. So it might make it easier to submit bug reports for the average user…

Last edited by dos (2014-05-18 12:42:32)

philwareham · 2014-05-18 19:03:46

GitHub will happen eventually, I probably need help from Jukka to do this though, as he’s more of an expert on all things git.

Textpattern CMS

Textpattern CMS support forum

#73 2014-03-08 20:15:13

Re: Situation report for Textpattern 4.6 and beyond

gaekwad wrote #279577:

#74 2014-03-08 23:11:50

Re: Situation report for Textpattern 4.6 and beyond

etc wrote #279567:

#75 2014-03-09 21:49:29

Re: Situation report for Textpattern 4.6 and beyond

Bloke wrote #279600:

#76 2014-03-09 22:32:27

Re: Situation report for Textpattern 4.6 and beyond

etc wrote #279610:

#77 2014-03-10 11:47:13

Re: Situation report for Textpattern 4.6 and beyond

Bloke wrote #279613:

#78 2014-03-10 13:05:02

Re: Situation report for Textpattern 4.6 and beyond

Bloke wrote #279613:

Gocom wrote #279620:

#79 2014-03-21 11:03:56

Re: Situation report for Textpattern 4.6 and beyond

#80 2014-03-21 11:11:21

Re: Situation report for Textpattern 4.6 and beyond

#81 2014-03-21 12:33:10

Re: Situation report for Textpattern 4.6 and beyond

Destry wrote #279872:

#82 2014-05-15 08:41:36

Re: Situation report for Textpattern 4.6 and beyond

#83 2014-05-18 12:42:07

Re: Situation report for Textpattern 4.6 and beyond

gaekwad wrote #280822:

#84 2014-05-18 19:03:46

Re: Situation report for Textpattern 4.6 and beyond

Board footer