Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: What features would you take from ExpressionEngine
This reminds me that in a future release perhaps the images can be freed up from being in the DB. Is this being considered?
I keep all site specific images relating to design in my /assets/images/ directory. But end-users cannot upload/delete images from such a sub-directory e.g.. a assets/usrimages/ dir. One reason is that if during an update or new installation … if the TxP images/ folder gets over-ridden…poof!
…. texted postive
Offline
Re: What features would you take from ExpressionEngine
bici wrote:
This reminds me that in a future release perhaps the images can be freed up from being in the DB. Is this being considered?
No. We need a place an image’s meta data like alt text, dimensions.
One reason is that if during an update or new installation … if the TxP images/ folder gets over-ridden…poof!
I cannot image how this would occur. The update procedure never touches existing preferences in an incompatible way.
Offline
Re: What features would you take from ExpressionEngine
Destry wrote:
If you’ve ever done much reading about enterprise content management
I’ve built a bit with TYPO3. Please stop ;)
Offline
Re: What features would you take from ExpressionEngine
bici,
I don’t know about slideshows, but maybe there’s two levels of additional structure being talked about here:
- content types
- content chunks
Types are like what have been talked about by others before, where they would be defined at the article level in some way and then use in the publishing flow in that context. Content types might be FAQs, book reviews, newsletters, product descriptions… to give a few examples.
Chunks, as I mean them, are atomic parts of a single article. Just like we already have author, publish date, title, excerpt, article image… etc. We could theoretically extend these components for longer text blurbs through better use of custom boxes. Again, example are meta descriptions, pull-quotes, teasers… you name it.
With these two kinds of content structure abilities, happening at two different structural levels, things could get really interesting.
wet:,
I haven’t had the displeasure of Typo3, but I’ll stop beating the dog since I know I’ve been heard, and hope for the best. ;)
Sam,
+1 on core plugins
+1 on multi-use forms
Other plugins I think should be core (or core plugins), since it was asked…
- sed_default_article_status (though I really think this plugin works in reverse of what it should if core was that way: draft by default then change to live)
- wet_article_info (or something similar)
Just off the top of my head.
Last edited by Destry (2012-08-09 15:01:40)
Offline
Re: What features would you take from ExpressionEngine
I think that default plugins might be the wrong term. I would go for “preferences” (features which we could switch on or off).
- zcr is a plugin which most people are using
- mlp to bring txp to the international market
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: What features would you take from ExpressionEngine
More relevant reading about why types and chunks are so useful. (And why any CMS that provides for this going forward will have a big leg up on the competition.)
Offline
Re: What features would you take from ExpressionEngine
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)
Offline
Re: What features would you take from ExpressionEngine
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)
Offline
Re: What features would you take from ExpressionEngine
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.
Offline
Re: What features would you take from ExpressionEngine
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?
Offline
Re: What features would you take from ExpressionEngine
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.
Offline
Re: What features would you take from ExpressionEngine
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.
Offline