When I enabled this module and go to any page with different language other than default language. I got the error message of "htmlspecialchars() expects parameter 1 to be string." Any Idea?

CommentFileSizeAuthor
#2 page_title-reset_before_current.patch1.06 KBeffulgentsia

Comments

guysung’s picture

guysung commented

Trough the review, I found where the error comes out.

In page_title_page_get_title() function, I just commented out the calling of token_replace_multiple() function for testing purpose then the error was gone.

The line I commented out in the pate_title.module file is below for your information. 

564     $title = token_replace_multiple($page_title_pattern, $types);

It seems somehow it passes an array as an argument to htmlspecialchars() function in somewhere.

Is this token module issue? Any idea would be much appreciated.

Thanks.

effulgentsia’s picture

effulgentsia commented
Version: 6.x-2.5 » 6.x-2.x-dev
Status: Active » Needs review
StatusFileSize
new page_title-reset_before_current.patch1.06 KB

What's happening is that $types['taxonomy'] is being set to FALSE rather than a taxonomy term object, and that's unexpected by the i18n module's i18ntaxonomy_token_values() function, causing it to end up passing an array instead of a string to check_plain().

The reason $types['taxonomy'] is being set to FALSE rather than a term object is that PHP's current() function reads the array from wherever it was last left off from, which after a foreach() loop, is at the end of the array, at which point current() returns FALSE. The intent in this module is to get the first item in the array, so a reset() is needed before current().

Here's a patch for 6.x-2.x. In 7.x-2.x, node_page_title_pattern_alter() was refactored to not use current(), so doesn't have this bug. However, 7.x-2x seems to have 6.x style taxonomy logic within comment_page_title_pattern_alter() that may need refactoring, but that's a separate issue.

effulgentsia’s picture

effulgentsia commented

Adding a note here for discoverability: as per check_plain(), the error message is either "htmlspecialchars() expects parameter 1 to be string" or "preg_match() expects parameter 2 to be string", depending on your PHP version.

nicholasthompson’s picture

nicholasthompson
Primary language English
commented
Status: Needs review » Fixed

Cheers for the patch - nicely debugged!

Patch applied to D6: http://drupalcode.org/project/page_title.git/commit/7d54a91805510ea6fc7d...
It also partly applies to D7 too... http://drupalcode.org/project/page_title.git/commit/acbfd07d3a72bfc6d5a4...

stevenovy’s picture

stevenovy commented

She's a beaut! We were suffering from the "preg_match() expects parameter 2 to be string" errors on a multi-lingual site and the patch @ #2 worked nicely! Thanks!

nicholasthompson’s picture

nicholasthompson
Primary language English
commented

@az100sun - have you tried the dev release?

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.