[33]Content - Merge "Readmore" and "Pagebreak"

[Hackwar]

1. Introduction
1.1 Scope
This document should describe a change to com_content to merge the readmore and pagebreak feature.
1.2 Objective of the document
This document is aimed at providing a basis for a discussion about a change to com_content to merge the readmore and pagebreak feature.
1.3 General remarks
1.4 Definitions
1.5 License
GNU GPL
2. What is the current issue?
The pagebreak and readmore feature currently are implemented very differently, even though they provide very similar functionality. Then again, when using the pagebreak feature and creating a table of content, the first entry, made by the readmore button, can not be properly named. Alltogether it seems strange that one and the same feature has two buttons, which act differently, but do the same thing in the end.
Besides this similar functionality, the concept of a fixed readmore in the text is not always working correctly with the layout. For example a blog layout with two columns might look very strange when a one page intro text is displayed in a very narrow column, while the text in the next column is only a few lines long. A different layout here needs coding skills.
3. What are the proposed improvements?
The system of readmore and pagebreak should be unified and merged. Instead of two buttons below the text, we should only have the one pagebreak button. This opens a popup with the settings „Title“ and „Table of Content Alias“. The first of these pagebreaks replaces the old readmore feature, the readmore text can be used from the title or TOC alias.
Besides this, a setting should be introduced that allows to switch between using the first pagebreak as a readmore or cutting the text after a fixed number of characters. This would have to be set individually for leading- and intro-articles.
4. Technical realisation
The differentiation between readmore and pagebreak is not state of the art anymore, as we have seen in the previous paragraph. To reflect this, the differentiation into introtext and fulltext should be dropped and instead of that, a field named „text“ or „article“ should be used. (It seems to be better to use the term „article“, since it better reflects the content of the field and it is not a reserved word from MySQL.) To keep backwards compatibility, the old fields are still populated, but in the Joomla! core the new way is used. Instead of using a plugin for the pagebreak, this functionality should be implemented as a ContentHelper-function into com_content.
To ensure valid HTML after splitting the text, even when using the break at a pagebreak, JHTML should be extended with a tidy class. This class by default closes all open tags in a string and can be set to strip tags like <img>, <form> and <object>. This is implemented with the tidy class (http://tidy.sourceforge.net/) and if that is not available, a simpler php function is used, available from here: http://textsnippets.com/posts/show/959
5. Possible uses
This would simplify the interface, create more valid HTML and allow new layouts.
6. Effects on ...
6.1 Users
The users will have to learn a slightly new interface, but I think the benefits outweight the problems that will arise.
6.2 3P extensions
There is no negative effect to be expected on 3P extensions due to the backwards compatible usage of the old tablefields.
6.3 Performance
There is no negative effect to be expected on performance.

readmore_pagebreak_0_1_hannes.zip

[newart]

I agree with you as "when using the pagebreak feature and creating a table of content, the first entry, made by the readmore button, can not be properly named. Alltogether it seems strange that one and the same feature has two buttons, which act differently, but do the same thing in the end."

I know this issue as I've considered about 1 year ago to post a request for "avoiding" the readmore button via a simple fixed number of characters to be chosen by an admin option. So you have only 1 option, the pagebreak viewable in that page.

But the problem is that not everybody agrees with my idea and not every site has the same needs, well, following your idea I think you can do all together, the need for a fixed readmore, a "chosen" readmore, and the pagebreak utility...

So you can have an option for enabling a fixed readmore (so you don't insert anything in your content), if not you have to see in your content if inserted a code for "flexyble" readmore and / or pagebreak!

[JasynL1977]

PROBLEM

I agree that the whole intro paragraph concept needs to be re-worked. However, I disagree that the HTML break is a good solution, nor should it be integrated with the page break (better left alone). It assumes that all content managers know HTML or will use templates to make sure that intro paragraphs will appear correctly (defeating the purpose of a content management system, which Joomla started out as).


The first implementation was to have two separate WYSIWYG editors, one for the intro paragraph and the other for the rest of the article. The problem was that it was confusing, and people did not understand why there were two editors.

The second implementation was to have one WYSIWYG editor, and to use markup, instead, to indicate where the break in the article should occur. On the back-end, the content is automatically split into two separate database columns: introtext and fulltext. There are several problems with that:

1) Content managers may not always remember to insert the break.

2) Some tags may not be properly closed before where the break is inserted (which requires the content manager to go into the HTML code to fix it).

3) You cannot set a limit to how much text will appear in the intro paragraph.

What is the whole purpose of the intro paragraph? It is one that is likely to be formatted uniquely for display on a separate page. The purpose of truncation is in order to set a limit on how much text to appear (a formatting issue). However, you cannot truncate the first paragraph without a whole lot of programming logic, which I have managed to implement on my own web site. (You have to make sure that you are not truncating before the closing tags of open HTML tag pairs. Plus, when you count the characters, you cannot distinguish easily between HTML or textual content.).

Neither implementation seems to work really well.

SOLUTION

Expected Result:
Personally, I think the following idea would give much greater flexibility for developers of site templates to control the final appearance of the article. Essentially, the following proposal takes some control of the intro paragraph's appearance away from the content manager and allows formatting to be enforced within a site template.

Implementation:
The original idea of having a separate box was a better idea; it just needed one change: Instead of two WYSIWYG editors, there should be one PLAIN textarea and one WYSIWYG editor. The textarea could even appear right above the WYSIWYG editor's IFRAME (to reduce confusion) with the default text of "Type intro paragraph here..." and it would have a configurable character limit. That way, the intro text will be a lot easier to format on the front-end and include in other pages, RSS feeds, etc. (Another possibility is to use this in place of the metadesc field, as it would probably get more use this way. That's another topic, however.)

It would be even better if the administrator can require the intro-text field for certain categories.

Using the image select tools like the ones that were available in Joomla 1.0.x, we can also enable the association of a picture with the article's intro paragraph, so that it can also be more easily formatted when included in another page or RSS feed. Otherwise, you are assuming that all of the content managers know HTML or will use templates to make sure that images appear correctly with the intro paragraphs.

This would also require an additional column: intro-image (the current images column does not appear to be in use).

Not only would these changes make it easier for developers of site templates to control how the article summaries appear, it would enable easier development of third-party modules.

[newart]

I use a No Editor by default as I've seen too many author users dirting articles... what I'd like to point out is to avoid problems for the "final" content manager. In your accurate description you don't take into account a simple easy character limit, so easy and powerful... maybe it isn't The Solution but part of a solution, do you agree with me?

[Hackwar]

I have to extremely disagree with JasynL1977 here. With your solution we would enforce people to always use a fixed number of characters for an intro paragraph and that would be something, that would keep me from using Joomla entirely. It could be argued that we should introduce an option in the menu parameters to limit the text shown to x characters, but thats not the only way to go. Besides that, there are some really easy options for you to implement the system that you are asking for. A simple template override does already the trick. I could hack this for you in 5 minutes. Read my proposal again and you will see, that with "tidy" I have the open HTML tags already "under control".

My goal in Joomla is providing the people with as little confusing screen options as possible while keeping the maximum of flexibility. If you need a special way of entering data in your system with a fixed form, you should take a look at a form manager or create your own component for this.

[JasynL1977]

...you don't take into account a simple easy character limit, so easy and powerful...

Actually, if you re-read my first post, you will see that I did say there should be a character limit. HTML textareas do not support character limits, you have to use Javascript. Still, I would support that.

I understand why you turn off the WYSIWYG editor, for the lower-level content administrator, but it should not have to be that way. Even the "final" content administrator will have a much easier time if the system enforces clean entry of data in the first place.

The entry of intro-text should not be integrated into the WYSIWYG editor; it has no place there. Rather, it should be a text field, that can be required for certain articles, and have a definable character limit. (It could be in the editor area, just below the row of buttons and above the IFRAME.)

I wish I could upload an image of this, but the site would not let me.

The changes required to implement this would be relatively small.

[Hackwar]

Another Editor, like for BBCode or the mediawiki syntax, and a plugin for the introtext would basically strip your editors down to a simple input field and allow you everything you want.

[newart]

I think of a setting configuration a # character limit option. If enabled you have no java, you use a "substr" format like this example:
substr($string,0,49) [for reader users in this thread, the couting usually starts at 0 so the first character is 0 the 50th is 49]

I'm not an expert in MySQL and sorry for my bad solution... and I know that if you have in your DB field some HTML tags, well, they are inside that counting... On my own I have no good solution for that problem...

[JasynL1977]

Actually, I think the point was missed in my first post. This is not a solution for just one person's application. The idea is to allow for enforcement from an administrator level the following:

1) A customizable character limit. This would be optional, but at least you can allow an administrator to have the option.

2) The ability to enforce tighter control over intro text. There is actually less flexibility with the current system. If you wanted the intro text to not have a WYSIWYG editor (typically for lower-level content manager), you could easily implement a solution in Joomla 1.0.x. That is not the case anymore, as it is now integrated in one editor.

I already built custom overrides, thank you very much. However, this should not have to be a requirement to do the above. Joomla started out as a content management sytem, which means managing content. If you cannot, as an administrator, manage the content being entered into the system, then you have limited functionality in terms of a CMS.

[Hackwar]

stripping all html tags from a text is just one function call. doing that in a plugin when saving the article is as easy as snipping your fingers. Using another editor, like one for bbcode is no problem either. I could go on and on here... This functionality is already possible in 1.5 with an override or a plugin. A nicer way will be possible with some new events in 1.6.

[JasynL1977]

The only other alternative, to go with what you are saying, is the following....

After inserting the readmore break, the application would close or remove all opened html tags that occur before it and then (again, optionally) check that the text (not counting HTML tags) does not exceed a maximum (definable) length.

You can also enable an administrator to prevent certain tags from being used in the intro paragraph.

Because you are dealing with HTML code and not PLAIN text, this solution seems to be far more error-prone than the idea I proposed, but it would satisfy what you are trying to accomplish.

Still, I don't think a content administrator should have to do any of this with extra plugins or third-party editors. As I said, Joomla started out as a content management system, so it should still allow administrators to maintain tighter control over how content appears on the Web site.

We have to remember what the ultimate function of the application is, not just think of all the bells-and-whistles. I am a developer, as well, but I am also a administrator of several Joomla web sites. Getting to use this on a regular basis has forced me to see where some of the pitfalls of Joomla lie. Until some of these issues are addressed (particularly, the management of content), Joomla will not be regarded as a serious CMS for large organizations. I say this because larger organizations tend to have multiple levels of content administrators, which any experienced Joomla developer will agree that it does not support effectively.

[JasynL1977]

I think the main issue I have is that, as the intro text is now integrated into one WYSIWYG text editor, you have less options for enforcing formatting. That's it. If we can somehow resolve that, then I would be happy.

[Hackwar]

Where do you have less options for formatting??

[JasynL1977]

I said "enforcing" formatting. And the reason for that is because there is no way to control user input for the intro paragraphs.

Why do I feel like I am repeating myself? This conversation is old.

[Hackwar]

you were not able to enforce a formating in 1.0 without modifying the core or using a plugin either. Thats why I don't understand your problem here. Especially in 1.0, even if you disabled the editor for the intro text, you could still just input HTML and joomla would have saved it. With the content editing events in 1.6 (as proposed in another whitepaper) you would have all the possibilities in the world. With the events currently in place in 1.5 (and before that in 1.0) you can do all this stuff, too, although its not as nice as with the editing events. In the end, it doesn't matter what the user inserts as introtext or text at all. Just strip all HTML tags from it and cut after x characters or use bbcode or all this nice stuff. Nothing is keeping you from creating such a plugin now.
I just don't see what having two or more editing windows is making it so much better than having just one window. Codewise it does not make a real difference and for the user it is one more field to take care of.

[newart]

thinking of what said in the first post: "The pagebreak and readmore feature currently are implemented very differently, even though they provide very similar functionality. Then again, when using the pagebreak feature and creating a table of content, the first entry, made by the readmore button, can not be properly named. Alltogether it seems strange that one and the same feature has two buttons, which act differently, but do the same thing in the end."

I hope to see this thread as approved! There's nothing to be added and I hope to see more "life" in our white-papers...

[gocareer]

Hi to the gurus,

Is there limit now for the input characters?

I tried both 1.0 and 1.5 versions, when there is about 100k characters long of the legal document. It is running for hours and cannot be saved nor error occured.

Thank you for your advices in advance.

[dianhariyadi]

i have problem with an article which has autonumber in it. how divide it into some pages. page1 (number 1-10), page 2 (11-20), etc. I tried using joomla pagebreak, but in the next page, the autonumber changed to list/bullet. what should i do? here is the link...
http://swateknik.swatama.co.id/index.ph ... &Itemid=93