Summary field in blog profile posts

[pogidude]

Hi,

I'm using the awesome Blog Profile and in site/templates/markup/post.php, there is this for displaying summary:
 

echo "<p>" . $page->summary . "… <a class='more' href='{$page->url}'>" . __('View More') . "</a></p>"

But when I edit the blog post or check the template used (post.php) I don't see any Summary field. is this field sort of automatic?

[pogidude]

never mind.. I found the reason inside `renderPosts()` function..

      if(empty($page->summary)) {
         // summary is blank so we auto-generate a summary from the body
         $summary = strip_tags(substr($page->body, 0, 450));
         $page->summary = substr($summary, 0, strrpos($summary, ' '));
      }

[kilax]

Hello.

I'm in trouble.

The program 'auto-generate a summary from the body' is not work on Japanese letters.

The program of this abstract works normally if I input an English sentence, but is totally useless in the Japanese sentence.

This program only slightly extracts only the alphabet of Japanese sentences, and other Japanese letters are deleted.

Is there the solution for even Japanese to operate normalcy?

ex.

English sentence,  work fine

ProcessWire is designed to have an approachable simplicity that is retained regardless of scale. Simplicity often implies reduced capability, and this is not the case with ProcessWire. From the surface, there is very little complexity and the application requires no training. Learn more about what makes ProcessWire unique.

While most of the code in this version of ProcessWire is less than a year old, the CMS is based on a system that the author has designed and developed over more than a decade of building CMSs. Also included is a discussion of how ProcessWire 2.0 compares to 1.0.

↓

ProcessWire is designed to have an approachable simplicity that is retained regardless of scale. Simplicity often implies reduced capability, and this is not the case with ProcessWire. From the surface, there is very little complexity and the application requires no training. Learn more about what makes ProcessWire unique.While most of the code in this version of ProcessWire is less than a year old, the CMS is based on a system that the

Japanese sentence, not work

手に取るまでは、ちょっと信じられないかもしれません。iPad Airは、わずか7.5ミリという薄さ。そして、469グラムという軽さ。目を奪う美しさのRetinaディスプレイを、より幅が狭い枠の中に収めたので、見たいコンテンツだけがあなたの目に飛び込みます。スリムなボディの内側には、圧倒的なパワーもつめ込みました。だから、より多くのことを、よりコンパクトなボディでできるのです。

↓

手に取るまでは、ちょっと信じられないかもしれません。iPad

This contribution uses a translation system.

[ryan]

I think it's because we're using a substr() there rather than an mb_substr(). You could try applying this change in /site/templates/blog.inc as I'm thinking that might fix it? (essentially replace "substr" with "mb_substr" and "strrpos" with "mb_strrpos"): 

diff --git a/templates/blog.inc b/templates/blog.inc
index b68abd5..e1096c2 100644
--- a/templates/blog.inc
+++ b/templates/blog.inc
@@ -118,8 +118,8 @@ function renderPosts($posts, $small = false) {

                if(empty($page->summary)) {
                        // summary is blank so we auto-generate a summary from the body
-                       $summary = strip_tags(substr($page->body, 0, 450));
-                       $page->summary = substr($summary, 0, strrpos($summary, ' '));
+                       $summary = strip_tags(mb_substr($page->body, 0, 450));
+                       $page->summary = mb_substr($summary, 0, mb_strrpos($summary, ' '));
                }

                // set a couple new fields that our output will use
 

Please let me know the result.

[kilax]

Thank you for your reply.

I tried , but there is no change at all in the results.

[kilax]

A problem was settled.

 

 

$summary = strip_tags($page->body);
$page->summary = mb_substr($summary, 0,100);
 

Japanese sentence

 

手に取るまでは、ちょっと信じられないかもしれません。iPad Airは、わずか7.5ミリという薄さ。そして、469グラムという軽さ。目を奪う美しさのRetinaディスプレイを、より幅が狭い枠の中に収めたので、見たいコンテンツだけがあなたの目に飛び込みます。スリムなボディの内側には、圧倒的なパワーもつめ込みました。だから、より多くのことを、よりコンパクトなボディでできるのです。

 

↓

 

手に取るまでは、ちょっと信じられないかもしれません。iPad Airは、わずか7.5ミリという薄さ。そして、469グラムという軽さ。目を奪う美しさのRetinaディスプレイを、より幅が狭い枠の中に収め

[ryan]

To prevent it from truncating in the middle of a word, you'd have to go back to the original bit of code. It first truncates to 450 characters. You can increase or decrease that number as needed, but it should represent the absolute maximum number of characters allowed in your summary. You may potentially need to remove the strip_tags(), as I'm not positive what that does with Japanese. 

$summary = strip_tags(mb_substr($page->body, 0, 450));

Next, you want to find the position of the last space within the 450 character block of text you just obtained, and then truncate to that. That's what the strrpos() or mb_strrpos() function does. I don't know Japanese, but if the word separation character is something other than a space, then you'd want to use that rather than the ' ' that appears below. 

$summary = mb_substr($summary, 0, mb_strrpos($summary, ' '));

Now that you've got $summary, try outputting it to see if it has what you want? I'm guessing it does, but don't know for sure. If it does, go ahead and populate it back to $page->summary and output it again:

$page->summary = $summary;
echo $page->summary; 

Has anything changed, or is it working the way you intend?

[kilax]

ryan, thank you for examining it in various ways.

In the case of Japanese, A blank is not put between a word and words, and,  the sentence is divided in "、", and "。" is put in the last of the sentence.

"、" is equivalent to an English comma, and "。" is used like a period.

In addition, the sentence may be over in "。" without being divided entirely in "、".

Therefore, the phenomenon that $summary is not generated at all is caused with the original cord.

In the case of Japanese. The process of "mb_strrpos" thinks whether one not to use goes well.

[ryan]

That's interesting about the language rules there and I probably should have realized a space was not universal. If there simply is no word separator, then I suppose there's no need for that 2nd mb_substr() that truncates to the last space ... I'm guessing you can remove that entirely. Depending on the length you need to truncate to, trying to locate the last "。" and truncate to that might sometimes result in a non-match, but otherwise seems like a safe bet (for reasonably long truncations).