The Joomla! Forum ™



Forum rules


Forum Rules
Absolute Beginner's Guide to Joomla! <-- please read before posting, this means YOU.
Forum Post Assistant - If you are serious about wanting help, you will use this tool to help you post.



Post new topic Reply to topic  [ 21 posts ] 
Author Message
PostPosted: Tue Nov 23, 2010 9:42 pm 
Joomla! Apprentice
Joomla! Apprentice

Joined: Tue Jan 24, 2006 10:05 pm
Posts: 19
After I upgraded a Joomla 1.5.9 site to Joomla 1.5.22, some pages in the site are blank. I also upgraded Community Builder 1.2.2 to 1.2.3, and AEC 0.12.x to 0.14.2 to at the same time, but I saw (and documented) the same blank page problem previously when I attempted upgrading from Joomla 1.5.9 to 1.5.10, so I'm certain part of the problem is the Joomla upgrade.

Can anyone recommend good next steps to try to resolve this problem? I'm also willing to pay someone as skilled as the Joomla core devs to help resolve this problem. I have written Joomla components, modules, and plugins, as well as CB plugins & AEC microintegrations, but I don't know Joomla, CB, or AEC internals. I'd prefer to pay someone with more knowledge than myself, but then again, all free advice is welcome and sometimes the solution to a frustrating problem is very simple. Thanks in advance for any help you can offer!

== Background ==

There were two problems with the site:
* AEC sometimes did NOT add new time to members' accounts when they made payments that DID clear through Authorize.net. To save money I didn't buy an AEC upgrade until recently. AEC's previous version hacked Joomla core files, so Joomla couldn't be upgraded until we upgraded AEC.
* Community Builder's member search results displayed the search form at the top of the list of results.

I didn't want to mix my changes with a subcontractor's changes in the development site, so I upgraded AEC, then Joomla, then Community Builder directly on the live site without testing them first. That was a mistake, because after the upgrades the following problems appeared. I did make a backup of the database before the upgrades, and the files are under version control, so initially it was possible to roll back the upgrade, but not desirable because the upgrades were needed and now it's been about 2 weeks since the upgrade (so members have added new content.) Next time I'll take the site down for maintenance when doing a major upgrade to prevent users from adding content during the upgrade.

At about the same time as I did these upgrades, Webfaction, our server host, switched the frontend server on web8 (where the live site is hosted) from apache to nginx serving apache serving sovereigngracesingles.com. I thought they had made that change before, but perhaps they had not yet done it on web8. I opened a support ticket, thinking nginx's way of handling .htaccess files might be the problem, and they said the problems below appear to them to be inside the Joomla application and not due to the server architecture change.

== Current Problems ==

The main problem is that some pages in the site are blank. In general, that problem has two main parts:

* When you're logged into the frontend as some users, http://sovereigngracesingles.com/j15t2/my-profile returns a blank page (but should show your user profile). Profiles have tabs containing different kinds of content (my photos, my forum posts, my videos, etc.) Those tabs are served by Community Builder plugins. Maybe one or more plugins aren't working correctly with this version of Joomla or Community Builder.
* Other pages in the site that display lists of members are also blank. The lists of members on other pages are served by Joomla modules; maybe those modules don't work in the current versions of Joomla & Community Builder.

Here is a list of all the URLs that display a blank page (j15t2 is a test copy of the site with its own separate database, and j15a is the live site):

* some member profiles don't output anything to the page (e.g., http://www.sovereigngracesingles.com/j1 ... ofile/Lexi - at least when you're logged in as her. When you're logged in as someone else you can view her profile.
* the member search page, according to some users (I can't replicate it yet),
* the http://www.sovereigngracesingles.com/j15t2/my-profile My Profile link when you're logged in as Lexi.
* While logged in as Lexi I got a debugging message that mentioned the problem was that some code was looking for 'dbname.jos_eventlist_dates' in the database. So I upgraded EventList (thinking it might create the jos_eventlist_dates table, but it didn't), then GroupJive (where the offending code was found, in the hope the newest version wouldn't contain that offending code). I don't get the error anymore, but the blank page persists.
* incoming emails like this one http://www.sovereigngracesingles.com/j1 ... geid=44371 when you're logged in as AWelcomeGuest/AWelcomeGuest. This also happened when I tried upgrading Joomla alone to 1.5.10, so it's an issue with the interaction between UddeIM and the Joomla core - maybe a change in Joomla's SEF URLs or database schema?
* http://www.sovereigngracesingles.com/j1 ... se-members
* http://www.sovereigngracesingles.com/j1 ... ll-members
* http://www.sovereigngracesingles.com/j1 ... browse-men
* http://www.sovereigngracesingles.com/j1 ... owse-women
* http://www.sovereigngracesingles.com/j1 ... aunch_chat - when you're logged in, the popup window launched by that page should load a Java chat room

So to avoid making the problems worse, I started working on fixing these problems in a copy of the site I have running locally. I also created a second test/development copy of the site in webapps/j15t2 (http://www.sovereigngracesingles.com/j15t2) for me and my contractors to work in (either directly or by pushing changes to it from our local Bazaar branches) so as to be on the same page.

I figure if I can fix one blank page, that will likely give me the clue to fix the other blank pages quickly. So it's probably wise to focus on troubleshooting just one URL in as many ways as I can.

== Things to Try ==

I have tried the following without success so far:

* Turn on debugging & set Error Reporting to "Maximum" in Joomla's configuration
* Read apache's error logs: tail -f error.log. This returned this traceback and several others summarized below. These errors only appear when I set Error Reporting to "Maximum."
Code:
[Mon Nov 22 22:05:53 2010] [error] [client 127.0.0.1] PHP Notice:  Undefined variable: content in /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/modules/mod_liveuserspro/mod_liveuserspro.php on line 264
[Mon Nov 22 22:05:53 2010] [error] [client 127.0.0.1] PHP Stack trace:
[Mon Nov 22 22:05:53 2010] [error] [client 127.0.0.1] PHP   1. {main}() /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/index.php:0
[Mon Nov 22 22:05:53 2010] [error] [client 127.0.0.1] PHP   2. JSite->render() /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/index.php:84
[Mon Nov 22 22:05:53 2010] [error] [client 127.0.0.1] PHP   3. JDocumentHTML->render() /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/includes/application.php:168
[Mon Nov 22 22:05:53 2010] [error] [client 127.0.0.1] PHP   4. JDocumentHTML->_parseTemplate() /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/libraries/joomla/document/html/html.php:249
[Mon Nov 22 22:05:53 2010] [error] [client 127.0.0.1] PHP   5. JDocumentHTML->getBuffer() /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/libraries/joomla/document/html/html.php:386
[Mon Nov 22 22:05:53 2010] [error] [client 127.0.0.1] PHP   6. JDocumentRendererModules->render() /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/libraries/joomla/document/html/html.php:190
[Mon Nov 22 22:05:53 2010] [error] [client 127.0.0.1] PHP   7. JDocumentRendererModule->render() /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/libraries/joomla/document/html/renderer/modules.php:41
[Mon Nov 22 22:05:53 2010] [error] [client 127.0.0.1] PHP   8. JModuleHelper->renderModule() /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/libraries/joomla/document/html/renderer/module.php:84
[Mon Nov 22 22:05:53 2010] [error] [client 127.0.0.1] PHP   9. require() /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/libraries/joomla/application/module/helper.php:173
[Mon Nov 22 22:05:53 2010] [error] [client 127.0.0.1] PHP  10. lvuMain() /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/modules/mod_liveuserspro/mod_liveuserspro.php:40


Most of the PHP notices returned have to do with configuration parameters:
Code:
PHP Notice:  Undefined variable: cbItemid in /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/modules/mod_cb12_search/mod_cb12_search.php on line 95
mod_s4jnewusers/helper.php:648: ereg() deprecated
Undefined index: googleTranslateElementInit /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/modules/mod_MultiTrans15v41/tmpl/default.php on line 97
gallerySelectList() /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/components/com_temprsgallery/listing.php :37
Undefined variable: usepublicgalleries in /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/components/com_temprsgallery/listing.php on line 185
PHP Notice:  Use of undefined constant _UE_fb_CONFIRMUNSUBSCRIBEALL - assumed '_UE_fb_CONFIRMUNSUBSCRIBEALL' in /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/components/com_comprofiler/plugin/user/plug_cbfireboardplugin/cb.fireboard.php on line 247
PHP Notice:  Undefined index: rank6txt in /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/components/com_comprofiler/plugin/user/plug_cbfireboardplugin/cb.fireboard.php on line 86
PHP Deprecated:  Function eregi_replace() is deprecated in /home/tim/Documents/MyWebPages/sovereigngracesingles.com/home/j15t/components/com_jcomments/jcomments.class.php on line 688, referer: http://localhost/sovereigngracesingles.com/home/j15t/


Did Joomla's configuration parameter reader code change from Joomla 1.5.9 to 1.5.10?

* Uncomment require_once('debugging.php'); ini_set( 'display_errors', true ); and error_reporting(E_ALL); in index.php
* Turn off Joomla's SEF URLs
* Turn off Joomla's SEF URLs AND rename .htaccess
* Create new menu items for the top-level/parent menu items that display blank pages; that is sometimes necessary after upgrading a component (and I did upgrade Community Builder's component.)
* Reinstall CB and Joomla on a local copy
* Hook up a PHP debugger to step through the code or catch where it throws an error (but the debugger (xdebug + Aptana) didn't work very well--it wouldn't break on any errors, and seemed to run through index.php repeatedly in a loop, though maybe that was due to unit tests running automatically under nosy.py).
* Roll back the code to Joomla 1.5.9 in the version control system in a local copy. This fixed the blank pages, so confirms that the problem is likely due to something in Joomla 1.5.10.

I haven't tried the following yet:

* Disable all profile tabs one by one (noting which ones were enabled originally), until there is no longer a blank page. Maybe save time by disabling all profile tabs first, and see if the page is still blank.
* Trace the execution from the URL through the code with echo() statements for key variables.
* Reinstall AEC on a local copy
* Upgrade UddeIM - UddeIM can't be the cause of some of the problems above, so I'm leaving this for last.


Last edited by timblack1 on Wed Nov 24, 2010 5:24 am, edited 3 times in total.

Top
 Profile  
 
PostPosted: Tue Nov 23, 2010 10:09 pm 
User avatar
Joomla! Champion
Joomla! Champion

Joined: Sat Aug 16, 2008 1:46 pm
Posts: 5737
Location: the Bat Cave
What php version is the site running, 5.3.3 seems to be a problem for some? Have you tried running the Post Assistant on the site to see if it finds anything?
You could try the Version Verification Tool to see if it finds any missing or corrupt Joomla files, it still has not been updated to 1.5.22 but you could dif the 1.5.20 to 1.5.22 patch to eliminate any files that have been updated since 1.5.20. Have you tried the CB tools to see if it is a user sync problem or database problem?
Have you tried flushing Joomla's cache and done a check-in, it is under the Tools button?


Top
 Profile  
 
PostPosted: Wed Nov 24, 2010 4:31 am 
Joomla! Apprentice
Joomla! Apprentice

Joined: Tue Jan 24, 2006 10:05 pm
Posts: 19
Thanks for the help.

dpacadmin wrote:
What php version is the site running, 5.3.3 seems to be a problem for some?

The problem occurs under both PHP 5.2.11 (MySQL 5.0.77, Apache 2.0.52) on the live site, and PHP 5.3.3-1ubuntu9.1 (MySQL 5.1.49-1ubuntu8.1, Apache 2.2.16) locally.
dpacadmin wrote:
Have you tried running the Post Assistant on the site to see if it finds anything?

Here is its output:


JTS-post Diagnostic Information wrote:
Joomla! Version:
configuration.php: Writable (Mode: 770 ) | RG_EMULATION:
Architecture/Platform: Linux 2.6.9-89.0.28.ELsmp ( i686) | Web Server: Apache | PHP Version: 5.2.11
PHP Requirements: register_globals: Disabled | magic_quotes_gpc: Enabled | safe_mode: Disabled | MySQL Support: Yes | XML Support: Yes | zlib Support: Yes
mbstring Support (1.5 or above): Yes | iconv Support (1.5 or above): Yes | save.session_path: Writable | Max.Execution Time: 30 seconds | File Uploads: Enabled
MySQL Version: ( )

JTS-post Extended Information wrote:
SEF: Disabled | Legacy Mode: N/A | FTP Layer: N/A | htaccess: Implemented
PHP/suExec: User and Web Server accounts are the same. (PHP/suExec probably installed)
PHP Environment: API: apache2handler | MySQLi: Yes | Max. Memory: 128M | Max. Upload Size: 200M | Max. Post Size: 200M | Max. Input Time: -1 | Zend Version: 2.2.0
Disabled Functions:
MySQL Client: 5.0.77 ( )


I don't see anything out of the ordinary in that. Do you?

dpacadmin wrote:
You could try the Version Verification Tool to see if it finds any missing or corrupt Joomla files, it still has not been updated to 1.5.22 but you could dif the 1.5.20 to 1.5.22 patch to eliminate any files that have been updated since 1.5.20.


Good idea. I already diffed the files with a clean copy of the Joomla 1.5.22 installer and didn't find any differences. I made a little script called md5xml.py to create an XML file for Joomla 1.5.22. Using that XML file, the Version Verification Tool in my local test site says there are no modified and no missing files, but the blank pages are still there.

dpacadmin wrote:
Have you tried the CB tools to see if it is a user sync problem or database problem?


Yes. CB tools don't report any problems.

dpacadmin wrote:
Have you tried flushing Joomla's cache and done a check-in, it is under the Tools button?


I just tried both and the blank pages still persist.


Top
 Profile  
 
PostPosted: Wed Nov 24, 2010 7:59 am 
Joomla! Master
Joomla! Master

Joined: Mon Oct 27, 2008 9:27 pm
Posts: 17181
Location: Akershus, Norway
Get the full 1.5.22 package. Unzip it and upload all except installation folder. Use a ftp client with logging and make sure all files are overwritten.


Top
 Profile  
 
PostPosted: Wed Nov 24, 2010 6:31 pm 
Joomla! Apprentice
Joomla! Apprentice

Joined: Tue Jan 24, 2006 10:05 pm
Posts: 19
Per Yngve Berg wrote:
Get the full 1.5.22 package. Unzip it and upload all except installation folder. Use a ftp client with logging and make sure all files are overwritten.


Thanks for the idea. I've already tried that twice as noted above:

timblack1 wrote:
* Reinstall CB and Joomla on a local copy


Top
 Profile  
 
PostPosted: Wed Nov 24, 2010 9:18 pm 
User avatar
Joomla! Champion
Joomla! Champion

Joined: Sat Aug 16, 2008 1:46 pm
Posts: 5737
Location: the Bat Cave
Have you tried a Repair on the database, all tables? Have you tried disabling plugins/components to see if one of them is the cause? Have you tried deleting the Lexi account and recreating it to see if that fixes it? Are you using any other extension for SEF urls, like sh404SEF, if so see if you can flush its cache of urls so it rebuilds them.


Top
 Profile  
 
PostPosted: Tue Mar 15, 2011 6:39 am 
Joomla! Apprentice
Joomla! Apprentice

Joined: Tue Jan 24, 2006 10:05 pm
Posts: 19
I found a workaround: delete HTML style attributes in TD and IMG elements. An example:

Code:
// This causes the blank page
//$html .= '<td width="' . $colWidth . '%" align="center" valign="bottom" style="overflow:clip;">';

// This makes it so the page displays properly
$html .= '<td width="' . $colWidth . '%" align="center" valign="bottom" >';


This makes me think that something in Joomla is processing the page's HTML before the output buffer is flushed to the page, and for some reason that processing has a silent and fatal PHP error when it hits a style attribute in TD & IMG tags.

I tried unpublishing the REReplacer Joomla plugin, but that didn't fix the problem. I'll look through other plugins to see if something else could be the cause.


Top
 Profile  
 
PostPosted: Tue Mar 15, 2011 7:41 am 
Joomla! Apprentice
Joomla! Apprentice

Joined: Tue Jan 24, 2006 10:05 pm
Posts: 19
If I disable the System - SEF plugin, that fixes the blank pages! So the problem is in Joomla's core SEF files - in plugins/system/sef.php. I see two new regular expressions were added to it in Joomla 1.5.10, one of which is:

Code:
// Background image
$regex       = '#style\s*=\s*[\'\"](.*):\s*url\s*\([\'\"]?(?!/|'.$protocols.'|\#)([^\)\'\"]+)[\'\"]?\)#m';
$buffer    = preg_replace($regex, 'style="$1: url(\''. $base .'$2$3\')', $buffer);


This regular expression remains in Joomla 1.5.22, which is what I'm running right now. If I comment out the lines above, my blank page goes away.

I wish I could figure out what change needs to be made to the regular expression to allow it to function correctly. It looks like it's looking for style="url(non/sef/path)" and then it tries to rewrite that as style="url(corrected/sef/path)". If that is the case, it appears the regular expression is failing on HTML which it is not intended to match--specifically, on style="overflow:clip;". Here are two guesses about what is going wrong:

1. I have a hunch that it's using a greedy modifier where it should be using a non-greedy (PHP docs call this "lazy") modifier. (.*) is greedy, so it matches the HTML beginning with THIS style attribute all the way to the LAST HTML in the page that matches the rest of the regular expression. Writing it as (.*?) makes it non-greedy, but it doesn't fix my blank page.

2. It is possible (maybe in combination with the greedy modifier above) that some other modifier in the regular expression is causing too much recursion in the matching process, and this causes PHP to have a silent fatal error.

However, when I insert a preg_match() call into the code in sef.php and write the matches and the count() of the matches to a file, there are zero matches from that regular expression. So far I'm stumped.

I guess I'll just comment out the problematic code in sef.php and hope Joomla devs fix this in future versions.


Top
 Profile  
 
PostPosted: Tue Mar 15, 2011 8:00 am 
Joomla! Master
Joomla! Master

Joined: Mon Oct 27, 2008 9:27 pm
Posts: 17181
Location: Akershus, Norway
timblack1 wrote:
I found a workaround: delete HTML style attributes in TD and IMG elements. An example:

Code:
// This causes the blank page
//$html .= '<td width="' . $colWidth . '%" align="center" valign="bottom" style="overflow:clip;">';

// This makes it so the page displays properly
$html .= '<td width="' . $colWidth . '%" align="center" valign="bottom" >';


Where is this code? Have you checked that your template do not need an upgrade? Code in a template output override may need some update.


Top
 Profile  
 
PostPosted: Tue Mar 15, 2011 8:12 am 
Joomla! Apprentice
Joomla! Apprentice

Joined: Tue Jan 24, 2006 10:05 pm
Posts: 19
That code is in a third-party Community Builder plugin:

components/com_comprofiler/plugin/user/plug_profilevisitors/profile.visitors.php

But because it produces valid HTML, it is surprising that Joomla's SEF plugin fails on that HTML.


Top
 Profile  
 
PostPosted: Wed Apr 06, 2011 10:17 pm 
User avatar
Joomla! Apprentice
Joomla! Apprentice

Joined: Thu Jan 25, 2007 9:24 am
Posts: 40
Location: San Luis Obispo
Ditto with the same problem on J1.5.22. Blank page; disabling sef plugin works. I do not and did not have sef enabled in config.

A little background to my issue. I was writing a custom function that can return a very long output based on a selected date range. Short queries were fine, but eventually I hit a limit on longer queries; larger output. Just a blank page with very limited debug information.

You saved a ton of time on this one timblack1. Much appreciation for your detailed post. Any hopes on solutions anyone?

I found this for 1.6 with same issues:
http://joomlacode.org/gf/project/joomla ... m_id=24865

Upon altering the code, I can now see it producing a 500 error when enabled:
500 - PHP regular expression limit reached (pcre.backtrack_limit)


Top
 Profile  
 
PostPosted: Wed Apr 06, 2011 11:35 pm 
Joomla! Apprentice
Joomla! Apprentice

Joined: Tue Jan 24, 2006 10:05 pm
Posts: 19
Since you got a regex error message, I'm pretty sure this paragraph will point you in the right direction toward finding a solution. I've done a little more reading about regular expressions here and on related pages about catastrophic backtracking. The essential point is that nested or chained quantifiers (+ or *) easily cause catastrophic backtracking not when there IS ALREADY, but when there ISN'T YET, a match. The solution is to use possessive quantifiers, atomic groups, or, if PHP doesn't support those first two regex features, use groups specific enough they can't be ambiguous. When I get some time I'll try to think through the existing regex to see if it can be improved in these ways.

Because I haven't been able to get a regex error message, another thing I intend to try is to disable other plugins that run AFTER my SEF plugin runs, because it remains possible something in a subsequent plugin is causing the blank page.


Last edited by timblack1 on Thu Apr 07, 2011 7:02 pm, edited 2 times in total.

Top
 Profile  
 
PostPosted: Thu Apr 07, 2011 2:56 am 
User avatar
Joomla! Apprentice
Joomla! Apprentice

Joined: Thu Jan 25, 2007 9:24 am
Posts: 40
Location: San Luis Obispo
I moved SEF to the end of the plugin list to have it execute last. Enabled = problems. Disabled fine.


Top
 Profile  
 
PostPosted: Thu Apr 07, 2011 7:01 pm 
Joomla! Apprentice
Joomla! Apprentice

Joined: Tue Jan 24, 2006 10:05 pm
Posts: 19
You just saved me some work, TechGump! Thank you!


Top
 Profile  
 
PostPosted: Mon May 23, 2011 10:23 pm 
Joomla! Apprentice
Joomla! Apprentice

Joined: Tue Jan 24, 2006 10:05 pm
Posts: 19
This patch fixes the problem for me:
Code:
=== modified file 'plugins/system/sef.php'
--- plugins/system/sef.php   2011-03-15 07:49:22 +0000
+++ plugins/system/sef.php   2011-05-23 22:14:44 +0000
@@ -84,10 +84,31 @@
       
       // Background image
       $regex       = '#style\s*=\s*[\'\"](.*):\s*url\s*\([\'\"]?(?!/|'.$protocols.'|\#)([^\)\'\"]+)[\'\"]?\)#m';
-      $buffer    = preg_replace($regex, 'style="$1: url(\''. $base .'$2$3\')', $buffer);
+        // Code taken from a comment in the online PHP manual's page on preg_replace()
+        // On default PHP installations you will run into problems when using preg_xxx() functions on strings with a length of more than 100,000 characters. To workaround rare occasions you can use this:
+        // However, be careful: 1.) ini_set() may be forbidden on your server; 2.) preg_last_error() doest not exist prior to PHP 5.2.0; 3.) setting a backtrack limit too high may crash PHP (not only the script currently executed). So if you work a lot with long strings you definitely have to look for a better solution!
+
+        // So, check to see if ini_set() and preg_last_error() are enabled on your server.
+        // Note we may have to use a more sophisticated way to discover if functions exist but are disabled, like this:  http://www.php.net/manual/en/function.function-exists.php#77980
+        if ( function_exists('ini_set') &&
+             function_exists('preg_last_error') ){
+
+            $times_to_increase_limit = 0;  // Count how many times we increase the limit
+            while( $times_to_increase_limit < 10 ) {  // If the default limit is 100,000 characters the highest new limit will be 250,000 characters
+                $new_buffer = preg_replace($regex, 'style="$1: url(\''. $base .'$2$3\')', $buffer);  // Try to use PREG
+                if( preg_last_error() == PREG_BACKTRACK_LIMIT_ERROR ) {  // Only check on backtrack limit failure
+                    ini_set( 'pcre.backtrack_limit', (int)ini_get( 'pcre.backtrack_limit' )+ 15000 );  // Get current limit and increase
+                    $times_to_increase_limit++;  // Do not overkill the server
+                } else {  // No fail
+                    $buffer = $new_buffer;  // On failure $new_buffer would be NULL
+                    break;  // Exit loop
+                }
+            }
+
+        }else{
+            $buffer = preg_replace($regex, 'style="$1: url(\''. $base .'$2$3\')', $buffer);
+        }
       
       // OBJECT <param name="xx", value="yy"> -- fix it only inside the <param> tag
       $regex       = '#(<param\s+)name\s*=\s*"(movie|src|url)"[^>]\s*value\s*=\s*"(?!/|'.$protocols.'|\#|\')([^"]*)"#m';



The attached files demonstrate and solve the problem with the regular expression in sef.php.


You do not have the required permissions to view the files attached to this post.


Top
 Profile  
 
PostPosted: Tue May 24, 2011 3:04 pm 
User avatar
Joomla! Master
Joomla! Master

Joined: Mon Aug 29, 2005 10:17 am
Posts: 13601
Location: Netherlands/ UK/ S'pore/Jakarta/ North America
Regex errors should NOT be addressed by hacking Joomla core files.....Have you seen other posts related? None or little so without wanting to sound dictating or pompous (since you did a good job itself) I strongly suggest that you reconsider this "solution" due to compatibility with future upgrades

Without looking in detail I am pretty sure that the issue is caused by faulty .htaccess rules and/or by server settings. sef.php works well especially in Joomla 1.5.23 (why did not you upgrade to latest secured Joomla which has a new htaccess.txt file?)

Leo 8)

_________________
-- Joomla Professional Support Services : http://gws-desk.com --
-- Good & Cheap Joomla Sites Ready To Roll : http://gws-deals.today --
-- Joomla Specialized Hosting Solutions : www.gws-host.com --
-- Member Joomla Bug Squad --


Top
 Profile  
 
PostPosted: Tue May 24, 2011 5:36 pm 
Joomla! Apprentice
Joomla! Apprentice

Joined: Tue Jan 24, 2006 10:05 pm
Posts: 19
leolam wrote:
Regex errors should NOT be addressed by hacking Joomla core files.....I strongly suggest that you reconsider this "solution" due to compatibility with future upgrades


You're right that Joomla end-users should not hack core files, because those hacks will be lost when upgrading to a more recent version of Joomla. But Joomla core files should be hacked by developers if there is a bug. My "test*" files demonstrate there is a bug in sef.php. Did you try running those test files to see whether they prove that the bug exists? After proving that a bug exists, I also created and submitted a patch both here for discussion by all, and contributed it to the Joomla project on Joomla's bug tracker so the core developers can integrate that patch into future Joomla releases. So far as I understand, this is the right procedure to follow in fixing bugs.

leolam wrote:
Have you seen other posts related? None or little


I did search for and read related posts, and with TechGump's help earlier in this thread, I found this bug tracker item to be the most relevant one: http://joomlacode.org/gf/project/joomla ... m_id=24865.

leolam wrote:
Without looking in detail I am pretty sure that the issue is caused by faulty .htaccess rules and/or by server settings.


I tried renaming the .htaccess file so as to disable any problematic rules, as I mentioned above. You are right that one server setting is involved: pcre.backtrack_limit.

leolam wrote:
sef.php works well especially in Joomla 1.5.23


It does work well on when $buffer is less than 100,000 characters, but when $buffer is over 100,000 characters, as it is in my tests, the preg_replace() call in sef.php returns null rather than the modified buffer, because preg_replace() backtracks more than the 100,000 backtrack limit set as the default in pcre.backtrack_limit. So on that point you are correct to believe that changing a server setting would fix the problem for me. But it would be better for Joomla to be able to handle pages larger than 100,000 characters without errors by either dynamically increasing pcre.backtrack_limit as necessary, which is what my patch does, or by modifying the regular expression to reduce backtracking, which would be the best solution. I tried modifying the regular expression by changing the greedy quantifiers to non-greedy quantifiers, but that did not bring the backtracking under the configured pcre.backtrack_limit, so I decided not to continue modifying the regular expression. There might be other ways to modify the regular expression to reduce the backtracking, but I can't think of any yet, and I don't own a copy of RegexBuddy, so am not able to quickly debug the regular expression.

leolam wrote:
(why did not you upgrade to latest secured Joomla which has a new htaccess.txt file?)


I tried upgrading to the most recent version available in Nov. 2010, which was 1.5.22, as mentioned above. Since then I've upgraded to 1.5.23, and seen that the bug still remains in 1.5.23. I did not try upgrading the .htaccess file using 1.5.23's htaccess.txt, however, so I appreciate your pointing out to me that I should do so. However, because my "test*" files prove the bug is in sef.php, and after a cursory review of the differences between Joomla 1.5.22's and 1.5.23's htaccess.txt files, I have no reason to expect upgrading the .htaccess file will fix the bug.

I do appreciate your and everyone's recommendations, because this has been a particularly difficult problem to solve for me. Every recommendation that ultimately proves unfruitful is nevertheless useful, because it helps eliminate more possible sources of the problem. So, thank you for your help!


Top
 Profile  
 
PostPosted: Tue May 24, 2011 5:45 pm 
User avatar
Joomla! Master
Joomla! Master

Joined: Mon Aug 29, 2005 10:17 am
Posts: 13601
Location: Netherlands/ UK/ S'pore/Jakarta/ North America
timblack1 wrote:
My "test*" files demonstrate there is a bug in sef.php.
We run Joomla 1.5.23 on over 850 developed Joomla sites and we maintain over 5.350 Joomla websites (Mods: no self promotion just clarification as stated on our websites) on a daily basis. We have resolved over 18.500 technical support requests and we have never seen your issue.

In other words: This is not a sef.php issue and if the core developers turn this upside down I grant you a year full free support on your website by our techs

Leo 8)

_________________
-- Joomla Professional Support Services : http://gws-desk.com --
-- Good & Cheap Joomla Sites Ready To Roll : http://gws-deals.today --
-- Joomla Specialized Hosting Solutions : www.gws-host.com --
-- Member Joomla Bug Squad --


Top
 Profile  
 
PostPosted: Tue May 24, 2011 6:21 pm 
Joomla! Apprentice
Joomla! Apprentice

Joined: Tue Jan 24, 2006 10:05 pm
Posts: 19
leolam wrote:
This is not a sef.php issue and if the core developers turn this upside down


Mark Dexter already committed revision 20879, which addresses tracker issue 24865. In my opinion, the patch he committed leaves the responsibility on the site owner to increase pcre.backtrack_limit in the server's configuration, so they haven't "turn[ed] this upside down" yet. But I'll let you know here if the core developers implement a patch that dynamically increases pcre.backtrack_limit, or reduces the backtracking by modifying the regular expression.


Top
 Profile  
 
PostPosted: Thu Sep 22, 2011 1:46 pm 
Joomla! Fledgling
Joomla! Fledgling

Joined: Thu Sep 22, 2011 1:35 pm
Posts: 2
(joomla 1.5.23)

Hello Folks,
i've had a similar problem:
when i created a module of a large size (above 200Kb of html), i've got a blank screen. It was very strange as i did not get any error in the php logs and die('ok'); still worked at the end of main index.php file. I somehow got to this thread when searching for "module maximum buffer length, html size" and similarly and after two days i've reached your post.

What i found out is that when having too large module's html, my output buffer gets deleted onAfterRender plugin call. After investigating the issue it was the sef.php plugin which really did this.

I disabled this plugin for now and will insvestigate how to tune regex queries on my linux installation. What was really annoying is that it deleted whole buffer instead of throwing an error: which i believe is really a joomla bug.

The site with this problem had more than 500 virtuemart categories and more than 7000 products, which is not a classical site.

How I found this:
i found a varialbe of $GLOBALS['_JRESPONSE'] which holds page data. When moving var_dump(.. on this variable in index.php i found that it is the plugin section onAfterRender which does this.


Top
 Profile  
 
PostPosted: Thu Sep 22, 2011 6:59 pm 
Joomla! Apprentice
Joomla! Apprentice

Joined: Tue Jan 24, 2006 10:05 pm
Posts: 19
stAn_rupostel,

I believe what leolan was implying, but unwilling to say because it would give away his business, is you should try putting this in your .htaccess file:

php_value pcre.backtrack_limit 100000

...and try increasing the 100000 until the blank page goes away. 100000 is the default value; try tripling it, and if the blank page goes away, try 200000 to see if you really needed to triple it, etc.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ] 



Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group