Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Fred K]

Has this been reported before? I can't find any such report anyway, which is ...sligthly... odd.
Inserting [break] inside a paragraph means that the ending

vanishes into thin air on the page where the short version is printed. Quite correctly, I might add, functionwise. But it breaks validation.

Example:

This is a test paragraph containing a string of stupid words and if you think you will read all the stupid words right up to the [break] mark, think twice, cut to the chase and skip right to the break mark.

Which on the home page (for example) will be output as: This is a test paragraph containing
a string of stupid words and if you think you will read all the stupid words right up to the (Read more)

That generated source code, which is what the validator looks at, will look like this:

This is a test paragraph containing a string of stupid words and if you think you will read all the stupid words right up to the (Read more)_

(date) · Comments (0) · Read more

(The red underscore represents the missing

which causes the validator to frown.)
This should be easy to fix, I think.

Forgot to say: This happens in 1.5.31.

[Keyrocks]

Hmmm... I've always made the break-point between paragraphs... never within a paragraph... hence the reason for not noticing this one before. I haven't checked into it yet, but the solution would seem to be manually close the paragraph before the break-point and re-open it again after it. Or, to do this automatically, one would need a second "break" insert button... for mid-paragraph use only... that would have the closing and opening p-tags wrapping the break-tag. Does this sound reasonable?

[codetwist]

May be it's possible to check if cutting at breakpoint doesn't leave unclosed

tag and if so add closing tag to brief version of text

Solution with extra

tags will require extra removal as well to avoid unnecessary paragraph division in full text display.

[piXelatedEmpire]

why would you use the break tag mid paragraph smitty? *tsk tsk*

[Patric Ahlqvist]

why would you use the break tag mid paragraph smitty? *tsk tsk*

A rascal remark, I'm sure, but I want to add some serious-ness into that remark... Why ? Why not just add the break between paragraph tags ? Ok, the newbie in us wouldn't know to do this, and would have an unvalidated site if ever putting it into a p tag, but still... Ah... You're right. Perhaps we should be able to put it anywhere and still get a validated site... As a service to the not so html coding dude/dudess's...

[Fred K]

why would you use the break tag mid paragraph smitty? *tsk tsk*

Why, you rascal you...
/*steam wisping out through ears, nose, eyes, whatever */

The question arose, so I tested it and shure enough, validation broke. I hadn't paid much attention to this befoe either for the same reason as everyone? else, I don't normally put [break] inside a paragraph.

I'd like to see an [excerpt] mod though. Or a [snippet] mod. A mod that lets me use a [snippet] on the front page, that is extracted to the RSS feed -- and text lines within a [snippet] [/snippet] pair are automagically wrapped in

tags. Now, that would be constructive ... pixie.

[philmoz]

perhaps modify the [break] to
1)check if last 4 char are

2)if so, then short text ends at the [break] insertion
3)if not, then short text ends as

There is no reason to reopen  the paragraph afterwards, as the rest doesn't get delivered anyway.

[4dd1ct]

This problem was even worse when sNews used to cut off after a character limit, because then even the middle of tags could be broken.

IMO a better solution would be to have an input for a snippet of text describing each article, limited to a certain volume of characters, restricted to text. This text could also be used as the meta description of the article. This would:

- Conform better to the standardized expectation for an HTML document
- Avoid all of the problems associated with [break] or with cutting at a certain character limit
- Be more foolproof, but also result in users creating more friendly documents, and using the snippet more effectively

Of course, the downside is that users would be more restricted in what they can use as the 'snippet'.

Other approaches (e.g. "perhaps modify the [break] to ...") are really striving towards validation of HTML in the code users enter, which is very difficult to achieve and very code heavy (I've tried it myself on other projects!)

[philmoz]

IMO a better solution would be to have an input for a snippet of text describing each article, limited to a certain volume of characters, restricted to text. This text could also be used as the meta description of the article. This would:

- Conform better to the standardized expectation for an HTML document
- Avoid all of the problems associated with [break] or with cutting at a certain character limit
- Be more foolproof, but also result in users creating more friendly documents, and using the snippet more effectively

Of course, the downside is that users would be more restricted in what they can use as the 'snippet'.

Other approaches (e.g. "perhaps modify the [break] to ...") are really striving towards validation of HTML in the code users enter, which is very difficult to achieve and very code heavy (I've tried it myself on other projects!)

Well, maybe not so difficult, to do... or code heavy...[edited] see next post [/edited]

As for a second input...
3 ways it's content has been used in cms's in the past, and now generally considered defunct...
1) a repeat of the first few lines of the main text, and ignored in full article display.
2) the first few lines of the original main, requiring user to ensure those lines are not in the main, else they will show up again, as the content is merged....
3) to provide a synopsis that is either displayed or not at the head of the article...

A second input may appear to make it easier, and in fact could be performed currently, by selecting text before [break], and displaying it in a leading box... then upon editing, enter it into the db with the [break] mark replacing it.... BUT, this is more coding, requires more discipline on user's part, and eventually, for some, becomes a right pain in the rear....

May as well look at making the current shortened output compliant, and maintaining a far more user friendly 'snippet' positioning method IMHO.

[philmoz]

a solution.. backup...
if it falls over itself, please let me know
grey is original code in file_include() function
brown is my comments, and can safely be stripped at your leisure
blue is new code

function file_include($text, $shorten) {
   $fulltext = substr($text, 0, $shorten);
   if ($shorten < 9999000 && preg_match('<p>',$fulltext)){
      // only operate on reduced text and check if there is any <p> tags,
      // just in case there isn't.
      // then, explode around <p> tags.
      $checktext = explode('<p>',$fulltext);$countarray=count($checktext)-1;  // get number of keys.
      // if paired before [break], then array elements will have </p> tags in them
      // so,  check last array element.. if no </p>, then it needs to be added.
      // but, not going to check if </p> is last in the string... if user isn't going
      // to put in <p> </p> pairs in full article, I'm not going to make it correct in short
      if (!preg_match('</p>',$checktext[$countarray])){
         $checktext[$countarray] = $checktext[$countarray]."</p>";
      }
      // then reassemble
   $fulltext = implode('<p>',$checktext);
   }
   $inc = strpos($fulltext, '[/include]');
   if ($inc > 0) {
      $text = str_replace('[include]', '|&|', $fulltext);

[codetwist]

May be something like this to avoid array, count, explode and implode as only last occurrences are looked for:

Code: [Select]

if ( ($shorten < 9999000) && ($openP = strripos( $fulltext, '<p>' )) >= 0 ) {
   if ( $closeP = strripos( $fulltext , '</p>' )) >= 0 ) {
      if ($openP > $closeP) {
         $fulltext .= '</p>';
      }
   }
   else {
      $fulltext .= '</p>';
   }
}

[philmoz]

This cat seems to have been skun twice

... and I had to look up strripos in the manual

that last $fulltext tho', I don't think should have the </p> appended??

Codetwist, I will have to play with this, as I can't seem to get it to work...

[codetwist]

That last was meant for case when there is <p> tag but </p> is nowhere in sight at all in shortened text. At least, I think so

And regarding problems - there might be some mismatch in parenthesis when I transfered code; but main problem that this function is of php5 :/ Didn't pay attention.

[philmoz]

no probs about php5...  and I already found the parenthesis mismatch....
from php.net --- strripos
This function may return Boolean FALSE, but may also return a non-Boolean value which evaluates to FALSE, such as 0 or "".


... I will play around with it some... see what Ican do with strripos... it looks intriguing

[codetwist]

OK, my version now needs small helper function to compensate for lack of strripos() on php4:

Code: [Select]

function last_strpos( $inText, $inKey ) {
   if (function_exists('strripos')) {
      return strripos( $inText, $inKey );
   }
   $offset = 0;
   while ( !(($curPos = strpos( $inText, $inKey, $offset )) === false) ) {
      $offset  = $curPos + 1;
      $lastPos = $curPos;
   }
   return isset($lastPos) ? $lastPos : false;
}And this code for adding </p>:

Code: [Select]

if ( ($shorten < 9999000) && !(($openP = last_strpos( $fulltext, '<p>' )) === false)  )  {
   if ( !(($closeP = last_strpos( $fulltext , '</p>' )) === false)  ) {
      if ($openP > $closeP) {
         $fulltext .= '</p>';
      }
   }
   else {
      $fulltext .= '</p>';
   }
}Works for me now (previously posted code wasn't run at all).