Open Toflar opened 12 years ago
I want to offer another vision.
To my mind the main advantage of articles is that they can be placed in different columns (main, right, left). But to use them as articles list (as like blog items or news items) not convenient. And especially to control them in admin panel.
I like the idea to rework articles, however I'm not convenient with any idea mentioned above.
@qzminski you like the idea of reworking - none of the ideas above - but you don't have a solution yourself? Why do you want to rework anything then? :D
@Toflar, I think the article system need to be reworked and I agree with the reasons you have mentioned. I'm not sure about your or DyaGa's solution, though. I don't see anything strange here. I should have written "+1" only ;)
I have to say that I agree with @DyaGa on this one. I cannot think of a single instance where I said to myself "You know what could solve this problem? ARTICLES."
To me, articles are useful only as wrappers for other content and as the building blocks for page sections. I say strip out the teasers and add in a configurable template option. That would simplify and solve problems at the same time.
I guess what Yanick means is, articles should be real frontend modules, which can/must be included in the page layout. This was, we can have configuration options like for every other frontend module (e.g. Pagination).
OK. I think I see it more clearly now....If you throw in the ability to change article templates per article module I am sold.
Yes, that's what I meant and yes, additional templates for the module (in fact mod_*-template overriding should be possible in every module) should be configurable.
Actually the template thing is pretty easy to implement :) I could do a PR (after my vacation :D)...
Became a PoC PR before my vacation :) See https://github.com/contao/core/pull/4547 and especially my comments on it :)
@leofeyer Any thoughts on making the articles a front end module too? :)
I just read this again (due to your comment), and I'm not sure if it makes sense. Articles are not meant to have pagination etc. If you want to have paginated or any other special content, use a real module like news or your own.
Having pagination in your article will only mean people will try to misuse it for things like news. Have you ever had the need to paginate articles? Any example why?
Any example why?
Can't remember, but I had. Anyway, I think there's not point in treating articles differently than modules. No matter whether we add pagination features or not :)
Well it is a module after all, it's it? Not sure why some code is in Controller
and some in ModuleArticle
In my opinion we should make a larger discussion about a new concept of article structure including some wireframes or scribbles … maybe on Contao Camp? What do you think about it?
fg nicky
I'm in :-) Let's prepare a session :-)
+1 :-)
@Toflar can you tell me the difference between article
and news
after modification described above
Nothing. Just as there's no difference between events
and news
;) The difference is between the news archive
that has no structure and the articles
that do have a tree like structure related to the page tree :)
`If there is no difference we do not need it!
The difference between events
and news
is that events
are time based. An event
always has a duration. A news article
can not take two days or other duration.
That's right, but the structure is the same … just some properties are different.
If there is no difference we do not need it!
I told you the difference? It's in the way the parents are handled.
The difference between events and news is that events are time based. An event always has a duration. A news article can not take two days or other duration.
Yes, but the structure is the same. Everything that produces lists is the same as the news module :)
the structur is always the same id=pid=ppid, etc.
Which is the difference. The news_archive does not have a pid ;)
Which is the difference. The news_archive does not have a pid ;)
actually yes the page has a pid (root id) now: rootpage > page > article module > news_archive > news
after modification: module > news_archive > news module > article_archive > article
for me article are containers with the following functional tasks:
For SEO reasons article-pagination make usualy no sense.
Since we are talking about the next major version here, I just wanted to remind you that there is the "let's drop articles entirely" discussion (together with the feature/no-more-articles
branch). This idea is also worth discussing, however only if we decide to keep articles at all :)
Yes, good point. Is there still an ongoing discussion? I think I must have missed the switch to the new mailing list -.-
No, the discussion has come to a deadlock with 50% being pro and 50% being against it. We'll resume the discussion when we are actually talking about the next major version.
In my opinion, contao could make a next big step in being a future proof CMS by following the same filosofy as ExpressionEngine (and now Drupal, Modx and more). Contao is already very well organized and flexible (also in the way it is programmed). But every website has specific needs and you have to be lucky to find a module that can facilitate the desired options for you're hockey website, cake recipe website, or you're real estate website. More and more CMS systems take the Content Management Framework (CMF) approach and introduce channels that can be configured with the desired fields (much like the catalog module). A channel can be a webpage with fields for PageName, MetaTag, DescriptionTag and Content. Or a channel can be a hockey scoreboard containing an entirely different combination of fields for match scores. A field can be put in the template with a tag, much like the contao insert tags, opening endless possibilities. Because the data is still very abstract, it is easy to use the same content and insert tags to output the data in webpages but also in RSS feeds or any other type of document. This setup, takes away all the "unnecessary" parts of the system (articles, blogs, news) and creates a format that can facilitate all of them. The system becomes very flexible and can be used for any type of website straight out of the box without much effort and without the use of modules and plugins. Modules and plugins would only be needed for additional type of fields of very specific functionality, like a website with payment modules. I encourage you to take a look at the implementation as done by ExpressionEngine. http://analogue76.com/blog/entry/content_modelling_with_expressionengine
Hello,
Excuse me to come in without any invitation ;-) but I find this discussion very interesting even if I'm not a developer but a web designer not very comfortable with php etc… There are 4 ou 5 years ago, I was looking for a new cms because Wordpress (1.X) was to limited, Joomla (1.x) had an ugly BE, Dotclear was really just a blog… Then I discovered Cont… sorry Typolight and I immediately knew i wanted to work with it. I'm still loving it now.
There is only one problem : I'm not sure I understood exactly how to use articles. Each time on creates a page, it creates the first article inside with the same name. So, the article is the "content" of the page. Not only because there can be many articles under a same page… displayed in left, main or right column. Each one has a teaser which can be automatically displayed as a list in the page before we clic on "read more…". And so without having to create a list then reader module. Nor having to create a module at all because it is automatically displayed… Unlike news, events…
Second problem : in a template page, there is the front office modules section to design what to put where… Why isn't it the same in pages (or articles) to display ce and fe modules ?
I see a third problem : as switch7x wrote, native content elements are very handy but sometimes doesn't exactly match with specific datas. So we can use dma_elementgenerator but this absolutely should be a core module. With the ability to use each created CE manually or automatically using predefined requests (by date, categories, tags… with lists or reader modules). So this won't be no more necessary to have news or events module as we could create them. Or this could be created as an example to help people start with Contao.
I never used Typolight 1.0 ;-) but I understand articles + CE very useful for the static websites we designed at the time. But now, we need more flexibility…
This should go with completely "designable" BE templates to adapt to each user/group.
Hoping this could help if discussion is still open although you labelled it "incompatible"…
I was just thinking about changing the article concept as we know it today. I found that we have a lot of code in Contao specifically for articles which are in fact completely redundant. Some examples:
What about killing the articles like we know them today? Why aren't articles included like everything else? We just need to extend the article list module with some features we have in the news list module (pagination, skip first, show only x items etc.).
That would increase flexibility a lot. You could have an article list module with pagination and one without. You could use a list template to display teasers and use a jumpTo page just like for the news. To provide the existing behaviour is just as easy as
That's it :-)
I know that you could implement this as a third party extension and I have tried already. But the problem is that I have to copy&paste that much code that I don't like my own extension anymore :-D I would like to reuse existing code as much as possible and thus use
Controller::getArticle()
andModuleArticle
but there's just too much code in the core that is not flexible enough (like e.g. the multiMode and showTeaser settings etc.).I guess this should rather be tackled properly and in the core itself. If you like the idea, then this might be a super nice feature for 3.1 :-) I think it might even be possible to implement this feature backward compatible (runonce, add a default article list module, replace "Article" in every page layout by the new module or so) :-)
Looking forward to reading your feedback on this :-)