Manuel Sailer

Oh no, I am sorry to read this.

I think the new problem has something to do with the only_show_in_main_post option that I do not use. But I did some testing now and found out that it does not work as expected – at least with yesterday’s changes.

To make only_show_in_main_post work and display the secondary title only when the post is displayed as single page I changed the code to:

/** Validate secondary title */
if ( ! $secondary_title || 
     get_option( "secondary_title_auto_show" ) === "off" || 
     is_admin() || 
     empty( $secondary_title ) || 
     ( get_option( "secondary_title_only_show_in_main_post" ) === "on" &&
       !is_single() ) ) {
  return $standard_title;
}

$secondary_title = wptexturize( $secondary_title );

It seems the later Only display if title is within the main loop part that also uses the only_show_in_main_post option and which I expected to provide this functionality does not do anything.

@thaikolja I’ve had a look at the code, downloaded the dev version once again, installed and tested it. And all test cases work as expected. So my thumbs up for pushing the changes to the next version.

Thank you very much!

You are absolutely right! ??

The reduction I suggested does not change important code and validations.
It leaves the conditions as you already changed them but removes code that you added as special handling for wp-Typography. This code is not required as there is no condition anymore that compares the outputs of htmlspecialchars_decode and wptexturize.

Hi again @thaikolja ,

my test cases also work if I reduce the validation to

/** Validate secondary title */
if ( ! $secondary_title || get_option( "secondary_title_auto_show" ) === "off" || is_admin() ) {
  if ( empty($secondary_title) ) {
    return $standard_title;
  }

  $secondary_title = wptexturize( $secondary_title );
}

The important thing was that you removed this comparison: $title !== wptexturize( $post->post_title )`. If there is no such condition there is no need for special handling when wp-Typography is active.

Hi @thaikolja ,

I tested the dev version you provided and had to make some little changes to make it work. This code is working for me:

/** Validate secondary title */
if ( ! $secondary_title || get_option( "secondary_title_auto_show" ) === "off" || is_admin() ) {
  if ( empty($secondary_title) ) {
    return $standard_title;
  }

  $secondary_title = wptexturize( $secondary_title );

  if ( class_exists( "WP_Typography" ) ) {
    $secondary_title = htmlspecialchars_decode( $secondary_title );
  }
}

The check for empty secondary title is necessary as non filled secondary titles on posts are stored as empty _secondary_title entries in the postmeta database table.
In the dev version secondary_title_auto_show generates HTML markup for these also. So content added by CSS :before and :after the empty secondary title gets rendered. Returning $standard_title in this case (as in the previous official version) solves the problem.

And of course secondary titles work on posts with & in the title and wp-Typography enabled. Thank you very much! ??

Hi @thaikolja ,

thank you very much for your quick reply.
But don’t be so hard on yourself. The dumbness might be on the other side. ??

To give you a working step-by-step guide I did some more investigation and found out that the problem only occurs when the output is processed by the wp-Typography plugin.
Without having wp-Typography installed the problem does not occur but can be easily switched on/off by enabling/disabling this plugin.

So this is the step-by-step guide to reproduce the error:

1. Install wp-Typography plugin and enable it.
2. Create a new post with an & in the title (e. g. Main & Title) and any Secondary Title and publish it.
3. Watch the post in your browser.
   Secondary Title should not be visible.
4. Disable wp-Typography plugin and reload the post in the browser.
   Secondary Title should be visible.

Of course I would be happy if Secondary Title and wp-Typography could be used together. But if you tell me that I have to solve this compatibility problem myself, I will accept that and apologize for blaming your plugin and stealing your time.

Have a nice evening.

Installed MLA 2.95 and verified that anchors in mla_link_href work as expected.
Thanks again!

Hi @pputzer,

thank you for your quick reply and your suggestion how to work around this problem.

As you found out yourself, @msaari was also very fast in providing a new version of the Relevanssi plugin that fixes the problem by ignoring the soft hyphens injected by wp-Typography. I think you’ll agree that taking this solution is the better choice as highlighting and hyphenation will both be there in the result.

In the topic Highlighting works only in some search results you gave some interesting insights into wp-Typography and the problems that might occur regarding content filter hooks and priority or when doing everything later on the whole document – what would be my favorite solution.
Maybe toying a little more with that idea and ongoing improvements in standard conformity of libraries and browsers may give the chance to implement it that way some time in future. ??

So big thanks again from me to both of you!

@msaari
Great thing! Highlighting is working now – even with hyphenation enabled in wp-Typography. Thanks for the quick fix and new release of Relevanssi.

@pputzer
In Relevanssi highlighting is done in PHP.
I absolutely agree Mikko that wp-Typography’s hyphenation should be done after Relevanssi’s highlighting. From my point of view it would be best if hyphenation could be the last step before the generated HTML will be send to the browser. This would reduce impact not just on Relevanssi but any plugin that needs the content in its original state and would behave similar as if hyphenation would be done on the browser side using CSS.
But as you wrote in our Disable hyphenation for tag or class topic hyphenation is done even before the content is filled into to the template. So maybe “priority juggling” might help.

Hi Mikko,

thank you very much for investigating this for me!

What you write sounds absolutely logical. I just wonder, why I cannot see these soft hyphens even in source code view in Firefox, Chromium and Vivaldi.
But I found the reason for them, it’s the wp-Typography plugin I mainly use to auto correct English quotation marks (“…”) and dashes (-) entered when typing to the correct alternatives in German ?…“ and —, but there is also auto-hyphenation that leads to all these soft hyphens. Will see whether I’ll test CSS hyphenation instead.

I tried to apply the changes you suggested in excerpt-highlights.php but could not find the line to change – event with ­ as the first parameter that is only visible (to me) when inspecting the source code of your answer above. The only ­ I found in the Relevanssi code is in common.php where a $replacement_array is defined.
But while searching for anything regarding hyphens I found your note in the changelog of version 2.4 telling that soft hyphens “still confuse the highlighting” and no later note telling that this was solved. ??

So for the moment I will disable highlighting in search results and wait for the next version of Relevansssi. Of course I will try highlighting again and tell you when I still experience problems with that functionality.

Thanks again and I hope solving this problem could help improving Relevanssi a little.

Edit:
Disabled hyphenation in wp-Typography and highlighting in search results works for all posts and pages without changing or saving them again.
That means hyphenation takes place when the HTML output is generated, not while saving the post. Might it be possible to reorder the processing steps and execute Relevanssi’s highlighting before wp-Typography’s hyphenation?

• This reply was modified 3 years, 8 months ago by Manuel Sailer. Reason: Further testing after disabling hyphenation in wp-Typography

The word “Stiftskeller” in the “Waiblinger Kreiszeitung” search result is not part of this posts content. It is in the excerpt of the “April – Mai 2016” post (first search result) which is a related article.

This is what is in the post_excerpt field of that post’s database entry:
Bereits zum zweiten Mal hat der KUNSTRAUM WEINSTADT die M?glichkeit, Werke seiner Künsterinnen und Künstler im historischen Stiftskeller in Weinstadt-Beutelsbach auszustellen. Das Motto dieses Mal: ?Farbe leben“. Und bunt wird sie sein, diese Ausstellung, nicht nur an Farben, sondern auch an dadurch transportierten Emotionen und Stimmungen. Werke in Aquarell, Acryl, ?l und Mischtechnik h?ngen an rohen Mauern oder Stellw?nden, Encaustic, auch in Verbindung mit Schellack, und Fotodruck sind ausgestellt.

And this is the source code of the Relevanssi excerpt:
<p><span class="excerpt_part">? ZVW – Waib-lin-ger Kreis-zei-tung Aus-stel-lung Mehr Infor-ma-tio-nen zu und Impres-sio-nen von der im Pres-se-be-richt beschrie-be-nen Aus-stel-lung fin-den Sie&nbsp;hier:&nbsp; M?rz – April 2016: ?Far-be leben“ im Stifts-kel-ler Beu-tels-bach Bereits zum zwei-ten Mal hat der KUNSTRAUM WEINSTADT die M?g-lich-keit, Wer-ke sei-ner Küns-ter-in-nen und Künst-ler im his-to-ri-schen Stifts-kel-ler in Wein---stadt-Beu---tel-s---bach aus-zu-stel-len. Das Mot-to die-ses Mal: ?Far-be leben“. Und bunt wird&nbsp;sie…</span></p>

There is absolutely nothing special in the database or the Relevanssi excerpt that might break a
$content = str_replace('Stiftskeller', '<span style="color: #ff0000">Stiftskeller</span>', $content);
or whatever you might be doing to highlight keywords.

For a short moment I thought it might be a problem whether the keyword is in the title or the excerpt of a related article. But this is not true.

I proved that with another example here. The search phrase in this example is erleben and only the last occurrence is highlighted correctly. The first occurrence (first row of the Relevanssi excerpt) is in the title of a related article and the second occurrence (last row of the Relevanssi excerpt) is in the excerpt of the related article – exactly as the correctly highlighted keyword at the end of the Relevanssi excerpt.

This is the source code of the Relevanssi excerpt:
<p><span class="excerpt_part">…zu und Impres-sio-nen von der im Pres-se-be-richt beschrie-be-nen Aus-stel-lung fin-den Sie&nbsp;hier:&nbsp; Febru-ar – M?rz 2019: ?Grün erle-ben“ im Rat-haus Beu-tels-bach Die-se Aus-stel-lung ist unse-re Auf-takt-ver-an-stal-tung im Jahr der Rem-s---tal-Gar---ten---schau und unse-re drit-te Aus-stel-lung im Rat-haus in Wein---stadt-Beu---tel-s---bach. Die herr-lich grü-ne Land-schaft des Rems-tals und das Gar---ten---schau-Mot---to ?unend-lich erle-ben” neh-men wir auf und ver-bin-den die-se zum The-ma unse-rer Aus-stel-lung ?Grün <span style="color: #ff0000">erle-ben</span>”.…</span></p>

Hi Mikko,

thank you for your quick reply. Sorry that I did not provide enough information but I did not expect that the context could be relevant for highlighting a keyword.

I prepared some more screenshots without pixelization now. I did separate searches for keywords in the surrounding context of Stiftskeller and focussed on two search results by removing all other ones.

You can find the screenshots here (keyword Stiftskeller), here (keyword historischen) and here (keyword Beutelsbach).

I also tried enabling “Expand highlights to cover full words” but it makes no difference. Highlighting stays exactly the same as in the screenshots provided.

Installed it as described and works like a charm. ??
Thank you very much!

I think we should wait to set the topic status to “resolved” until your fix is released in the next none development version of MLA.