What features would you take from ExpressionEngine

Zanza · 2012-08-10 11:32:22

Really interesting reading linked from Destry, here, thanks.

From what i see, both Karen McGrane and the Allen Tan’s Contents Magazine article are saying: manage your content at a more granular level, in one place/one UI, and decouple it from the viewing format. I agree. But I can’t avoid noting myself that this is exactly the work TXP is doing right and good. Of course, you need custom fields to do that. But we have a great plugin that is working fine for that.

Both articles say that you need to work with content strategists to figure out how to break the content in components, and how to set a proper workflow. The breaking up part should then reflect in a custom UI in the CMS, in the context of what we call “articles”. In the past, for the sake of proofing the concept, I tried to have in the backend some variables and custom fields set to make different layouts for my posts depending on some author’s choices. It was rather convoluted on the “form” part of textpattern, because you had to put a lot of conditional about variables and custom field, but you could definitely build a good “semi-automatic” system that change layout based on some choices made on some custom fields on the UI.

(I agree that something could be improved on the workflow part of the concept, though, especially if you’re a full editorial enterprise).

Finally, a thought about content types. We miss them. But, with the help of bot_ plugins, we could have different sections with different UI on the write page, that could mimic content types. Not explored too long this way, and maybe it is a bit too “workaround-y”, but could be done.

I agree that all of this requires a lot of work on planning, designing and coding on the back-end part. But it seems to me that this is exactly what both Karen and Allen point to, at the end. You can’t avoid it, because no out-of-the-box system fits all.

Last edited by Zanza (2012-08-10 17:27:02)

Destry · 2012-08-10 17:18:29

Zanza,

I completely agree with all of your observations. Although it may seem like I’m not a happy camper, the opposite is true. Textpattern is in a good position with the chunking stuff, and if advancements with the custom fields are implemented, that will be huge. But that doesn’t mean development should be complacent and not improve handling of what exists. There’s room for it. I’m happy to see signs that it’s happening.

This topic—granular content and Txp’s reasonably good ability to handle it—needs communicated outward, and now is the time, because people out there are tuned-in to anything “adaptive” and “responsive” with respect to CMSs. Up to now, nobody has really demonstrated that very well, though there was never really the focus on adaptative content before like now either. I think we’ll be seeing an article in the magazine on Txp’s chunking abilities, eventually.

Btw, Zanza, when are you writing something for the magazine? Maybe something on those content type work-arounds? ;)

Last edited by Destry (2012-08-10 17:21:18)

maniqui · 2012-08-10 17:33:34

On topic: there is always some micro-copy content that may not fit in the article model, or better said, the article model may be a bit overkill to handle it. Like contact information, or copy for success/warning/error messages, or other micro-copy used across a website.

I’ve written a few times about the idea of having a “Content -> Snippets”. I thought them as new form type (like “misc”, “article”, etc, “snippet”) that would make the form to be listed under that tab.

We currently have mck_snippet that may fit the bill pretty well. And there are also adi_variables and smd_macro, that may be helpful on the task of managing chunks of content that does’t fit the article model.

wet · 2012-08-10 17:43:16

maniqui wrote:

On topic: there is always some micro-copy content that may not fit in the article model, or better said, the article model may be a bit overkill to handle it.

I disagree. Define overkill. The Write panel provides the best user interface for writing by definition. Why would one deliberately author content elsewhere?

maniqui · 2012-08-10 18:05:22

Wet, you have a point there about being the Write panel the obvious & best place for writing/updating content.
But then, there could be some separation of concerns regarding content authoring. Not all content/copy is equally or of the “same nature” in a website.

Yes, the Write tab provides the best user interface for writing content that is tied to sections. But there is some copy (particularly, micro-copy) that may not belong to a particular section or category. Let’s call it site-wide, section-less content.

There you have a feature request (I think I’ve published it in the past): the possibility of publishing content without having to select a particular section in the dropdown menu.
That little (little?) change will allow us to manage content not tied to any section.
Of course, simple creating a “static-content” section where to publish these kind of content could be an (hackish? unnecessarily cumbersome?) alternative.
This section-less content could be easily fetched via id attribute in article_custom.

Bottom line: don’t make it mandatory to select a section for publishing content. I think it could improve the workflow for creating/drafting/publishing/managing content.

Gocom · 2012-08-10 19:20:07

Everyone spouting about core plugins. Who exactly develops and maintains these core plugins? Any particular suggestions? Or are just trying to get your loved tool supported for price of nothing. That’s cute. What if you all started by asking, who wants to take X and keep it updated. There’s a thought.

Really, there is no difference who maintains the code, whether it’s the core team or someone else. Trying to throw everything on a small group of people isn’t exactly the best idea, and isn’t going to bring you plugins that are supported for the foreseeable future. Modules directory is often found as a core component’s graveyard, and as a support and a compatibility hell. Not to mention these plugins would increase work, which then takes even more time from the people that do the product.

Let’s also bring that small detail up. Most of those big projects you are suggesting to be part of the core plugins, are not up to the quality standards. For instance MLP is pretty rough and foremost a hack that sits on top more of than extends. And these bigger projects are, well, big.

As far as features go, they are easier to add if the maintainers actually benefit or themselves use the particular feature. If a developer X doesn’t use feature A, then it’s not going to get much love. It’s pretty hard to wake up at the morning thinking I want to develop this thing I’m never going to use.

maniqui wrote:

Of course, simple creating a “static-content” section where to publish these kind of content could be an (hackish? unnecessarily cumbersome?) alternative.

I find that to be a valid use case for sections. If anything, sections offer an excellent way to organize content.

Zanza · 2012-08-10 21:29:31

Destry wrote:

…Although it may seem like I’m not a happy camper, the opposite is true. (…) But that doesn’t mean development should be complacent and not improve handling of what exists. There’s room for it. (…)This topic—granular content and Txp’s reasonably good ability to handle it—needs communicated outward, and now is the time, because people out there are tuned-in to anything “adaptive” and “responsive” with respect to CMSs. Up to now, nobody has really demonstrated that very well, though there was never really the focus on adaptative content before like now either. I think we’ll be seeing an article in the magazine on Txp’s chunking abilities, eventually.

Yes, communicating the possibilities of txp is really a good point! And the right time. Looking forward for the article.

Btw, Zanza, when are you writing something for the magazine? Maybe something on those content type work-arounds? ;)

Honored by your proposal, Destry. I need to wait to have something useful to say, though. I’m having spare time for txp-playing, lately… But, who knows? Those articles are inspiring…

bici · 2012-08-10 21:42:46

Zanza wrote:

Destry wrote:
Btw, Zanza, when are you writing something for the magazine? Maybe something on those content type work-arounds? ;)

Zanza wrote: Honored by your proposal, Destry. I need to wait to have something useful to say, though. I’m having spare time for txp-playing, lately… But, who knows? Those articles are inspiring…

I second Destry’s proposal re article.

PS I think that with the imminent release of TxP 4.5 and certainly by 4.5.5, That it is timely for a updated book on Textpattern Solutions …
If there are any inspired authors out there.

philwareham · 2012-08-11 07:32:44

Thinking about it, the only two plugins I’d really ever want to see assimilated into core are custom fields and contact forms really (though it could be argued that forms can be more appropriately handled by wufoo or machform so even that isn’t essential)). Maybe some better multi languages support.

Everything else is best served by plugin authors themselves. Though I agree with gocom that orphaned plugins can be a problem sometimes, but that’s not unique to Textpattern.

bici · 2012-09-14 20:36:48

philwareham wrote:

Though I agree with gocom that orphaned plugins can be a problem sometimes, but that’s not unique to Textpattern.

I agree that all CMSes that rely on plugins can find themselves with orphans. But I think with ours there is a greater likelihood judging from the date that most plugins were last modified. It does cause me worry to rely on them.

Is there a possibility, or desire, to have plugins that work with 4.5 > be listed in a central repository? It would be on a voluntary basis by the plugin developer, but seeing theirs listed in such a repository would give greater confidence that there is a care and feeding regime on their part.

Furthermore: Should a crucial plugin go orphaned is said plugin free to be updated/modified by another developer?

wet · 2012-09-15 05:46:33

bici wrote:

Should a crucial plugin go orphaned is said plugin free to be updated/modified by another developer?

Plugins are licensed under the GPL as long as they are making function calls to and share data structures with Textpattern and therefore inherit its license. This precondition applies to almost any plugin.

Thus any user of these plugins has the “legal permission to copy, distribute and/or modify the software.”

masa · 2012-09-15 23:46:39

wet wrote:

There is no overkilll in Textpattern. Articles are where our user-editable content lives, that’s why we have permissions set up the way they are. Looks like a perfect fit.

I agree with Robert.
It’s what I’ve been doing for years. You just set aside some “invisible sections” such as client-quotes, footers, addresses etc. named accordingly, place snippets as separate ‘articles’ in there and pull them in where needed.

Think of ‘articles’ as any kind of content.

Textpattern CMS

Textpattern CMS support forum

#31 2012-08-10 11:32:22

Re: What features would you take from ExpressionEngine

#32 2012-08-10 17:18:29

Re: What features would you take from ExpressionEngine

#33 2012-08-10 17:33:34

Re: What features would you take from ExpressionEngine

#34 2012-08-10 17:43:16

Re: What features would you take from ExpressionEngine

#35 2012-08-10 18:05:22

Re: What features would you take from ExpressionEngine

#36 2012-08-10 19:20:07

Re: What features would you take from ExpressionEngine

#37 2012-08-10 21:29:31

Re: What features would you take from ExpressionEngine

#38 2012-08-10 21:42:46

Re: What features would you take from ExpressionEngine

#39 2012-08-11 07:32:44

Re: What features would you take from ExpressionEngine

#40 2012-09-14 20:36:48

Re: What features would you take from ExpressionEngine

#41 2012-09-15 05:46:33

Re: What features would you take from ExpressionEngine

#42 2012-09-15 23:46:39

Re: What features would you take from ExpressionEngine

Board footer