Make WordPress Core

Opened 9 years ago

Closed 9 years ago

#14468 closed defect (bug) (duplicate)

Shortcode usage causes blog texts to not be output

Reported by: cymric Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Shortcodes Keywords:
Focuses: Cc:


System configuration: PHP 5.2.12 + Zend 2.2.0 running on SunOS 5.10; Wordpress 3.0 + Atahualpa 3.4.4 / 'STRATO Default' 1.5 (= based largely on Kubrick; STRATO is my webhost)

Problem: adding the following code to the theme's functions.php ('foto' is Dutch for 'photo', 'fout' = 'error')

function shortcode_foto($atts, $content, $code)
	return '<span style="color: red;"><strong>[FOTOFOUT]</strong></span>';
add_shortcode('foto', 'shortcode_foto');

and then using the shortcode [foto] in blogtext can result in the blog text itself disappearing completely from the screen. It is simply not output by Wordpress. The rest of the page looks normal, no missing content, no CSS errors, comments (if there are any) appear normal. After many trial and error I was able to create a text where the addition of a single letter to the last word in a very normal HTML-paragraph of text means the difference between visible text and non-visible text.

Switching themes: Switching to a different theme, taking care to code the same few lines in the appropriate functions.php file, made no difference. The test cases behaved identically: the post disappeared when asked to view the text with one letter extra.

Using a different method of introducing the shortcode to Wordpress: Originally I wanted to have the code wrapped as a plugin. This already caused the behaviour I reported above. Thinking the instantiation method was awry I coded it in a different way, which made no difference. The functions.php-approach is the third attempt to get the code working. At this point I believe the problem is not related to how I hook the shortcode into the system.

Using a different version of Wordpress: Originally I started out with WP 2.8.5 where the bug raised its head too. I upgraded to WP 3.0, noticing but one difference: I could make the text slightly longer before the problem was triggered.

Adding text before the first use of the shortcode: I can add as much text as I want to the texts before the moment I first use the shortcode without triggering the problem. It is only after the shortcodes are used that the issue appears.

Multiple uses of the shortcode: I have some documents where the shortcode is used more than the two times of the test cases (4 to 5 times), and those texts are rendered without problem.

Access to the test cases: Since I'm still working on a trial blog, copying over content from an older blog, I do not want to name the URL in public just yet; also I've added some simple HTTP Auth protection. Please contact me via email to get the necessary login information.

Possible causes: For the moment I am not sure whether the problem resides with WP or PHP. Unfortunately I cannot change the PHP interpreter.

Change History (4)

#1 follow-up: @nacin
9 years ago

It's probably your PCRE backtrack limit. The default is 100,000, you might need to go higher if you have a lot of content and a lot of shortcodes, but I'm betting your setting is much lower. See #8553.

#2 in reply to: ↑ 1 @cymric
9 years ago

  • Resolution set to fixed
  • Status changed from new to closed

Replying to nacin:

It's probably your PCRE backtrack limit. The default is 100,000, you might need to go higher if you have a lot of content and a lot of shortcodes, but I'm betting your setting is much lower. See #8553.

The setting was at the default of 1e5, but upping it to 1e6 most certainly did the job alright. Still, the actual testposts were under 1 kb of ASCII with just 2 active shortcodes (and a few dudcodes I haven't add_shortcode()'d yet. I'm hard pressed to believe that a setting of 1e5 then makes much sense as a good general setting...

Thanks for the hint; as far as I'm concerned this 'bug' is fixed / closed.

#3 @nacin
9 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

That seems like way too little content/shortcodes required to hit a backtracking limit of 105. I'm not really sure what's going on there. Nonetheless, probably duplicate of #8553.

#4 @dd32
9 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from reopened to closed

Closing as duplicate of #8553 - It's the same root cause, just a slight difference in level of settings which triggers it.

Note: See TracTickets for help on using tickets.