This is the bug tracking and feature request tracking system for the Mambo open source CMS project. To add a new task, or comment or vote on an existing task, please register, preferably by using the same username that you use on the forums.
Please do not open tasks for bugs in versions earlier than Mambo 4.6.5.
FS#233 - Application halts on CR/LF in textarea textfield in Global Configuration
Opened by Robert (rkalitta) - Thursday, 24 May 2007, 15:15 GMT-4
Last edited by Andres Felipe Vargas valencia (andphe) - Saturday, 17 May 2008, 10:23 GMT-4
|
DetailsIn Global Configuration under the tab Site and Metadata exists on each two textfields (textarea); config_offline_message, config_error_message, config_metadesc, config_metakeys. If ENTER-key is pressed durring editing these textfilds the configuration.php-file end up corrupt when saving/applaying and the whole application halts - the public site as well as the current adminpage in Global Configuration. Edit and save the configuration.php-file externaly and the whole application runs again as nothing happened. Proposal to solution: str_ireplace any \n to <br />. |
File /administrator/components/com_config/admin.config.php line 230:
change it to:
$txt .= "\$$v = '".addslashes( str_replace(array("\r\n", "\n", "\r"), '', $this->$k) )."';\n";I can confirm the problem. I'm not sure I would call it a bug though because using any line break in metadata can cause browser errors. Metadata should not have returns or breaks.
Andres, your change works as expected. Mambo site does not freeze anymore.
But I have this suggestion. Instead of
$txt .= "\$$v = '".addslashes( str_replace(array("\r\n", "\n", "\r"), '', $this->$k) )."';\n";Replace the \r \n with a space. This way we can keep META tags still usable.
$txt .= "\$$v = '".addslashes( str_replace(array("\r\n", "\n", "\r"), ' ', $this->$k) )."';\n";Andres; the problem is not resolved in 4.7. Please take a look at that one too.
Cem I just put the code on the 4.7 branch to handle the issue of the registration disclaimer with the «< Operator
this goes to you Dean :)
Guys, as far as I can tell this prevents line breaks created through the admin interface - which is fine as far as it
- users editing the config file manually can enter a line break which kills Mambo dead - and it shouldn't.
Here's what's
I manually insert the carriage return via a text editor - the script hangs. On Apache on Windows I get a connection reset by server error.
I'm curious because the following line of PHP code itself is NOT invalid.
So - it must be something that we do with the code once it is read in.
These three lines:
become this once read in and the '$this' substitution is done:
Note the missing line - the single quote and semi-colon that were on teh middle of the three
is the dropping of the unaltered line with the '; that cause it to die.
When read in getConfig in core.classes.php why do we read in the file line by line We read in single lines, do the $this substitution and ONLY concatenate altered lines.
This will KILL any settings spread over multiple lines.
FIX: remove the if - add the line to the '$code' variable whether it was altered or not.
I'd propose this function be reviewed. Any reason we don't output the config file with $this→ notation for new installs - or switch to a standard ini file that can be read in and parsed with a PHP one liner.
Alternatively why don't we just read in the whole file and search and replace $ for $this→ over the whole block of text (the whole
in case anyone puts a dollar on the right hand side of the equals we can leave the regex anchored on the start of the line (if necessary).
Incidentally - we already had a couple of these in the forum.
Dean (verbose) Marshall
Okay - I solved one problem the other day by concatenating the lines regardless of whether they start with a
I caused myself another error because eval ing code with the <?php and ?> tags causes the eval to
we still have to strip those lines out while allowing other lines which don't start with $mosConfig_
showed up another flaw - the result of the eval aren't tested - so a corrupt config file returned false and execution continued, the process cycling around trying to instantiate mamboCore. Try printlining in mamboCore() you can currently get it to cycle hundreds of times when the configuration.php file is invalid.
Here's my suggested
function getConfig () { global $adminside; $code = ''; $f = @fopen($this->rootPath.'/configuration.php','rb'); if ($f) { while ($f AND !feof($f)) { $line = fgets($f);// skip lines starting with < ? php or ? > if( substr($line,0,5) == '<?php' || substr($line,0,2)=='?>'){continue;}$altered = preg_replace('/^\$/', '$this->', $line); //if ($altered != $line) // not neaded anymore. $code .= $altered; } } else { //header( 'Location: installation/index.php' ); exit(); } fclose($f);// test the result of the eval - just in case if( eval($code) === false){die("configuration.php is invalid");}</code>
Good cath Dean, I didn't think when the user edit the file manually, but I think probably we are taking a too complicated way when PHP already can parse a file better than us, if we include configuration.php in the scope of a function an assign the mosConfig variables to the mamboCore members then we already did the trick, and support each metohd of assigment that PHP supports.
I digged a bit, looking for places when the use of the configuration.php file is used and in any place the file allways is parsed, I think we can take advantage of this oportunity to make a clase that encapsulate the read and write of the file and reuse the class in anywhere.
What do you think?
I defer to your superior knowledge Andres - I've pointed out the problem and suggested the function be revisited - I'll leave the actual implementation to real programmers. If you can require or include the config file and then loop through the vars adding them to a class then that sounds like a reasonable suggestion to me.
Dean
If we do this will it be possible to also add a feature so that the path to configuration.php can be changed? In Mambo 4.5 it was possible to copy all the content of configuration.php and put it in a file under a different name, outside the site root. Then in configuration.php we just included that file.
Like this- configuration.php has only this
?>
The "real" configuration data is in mambo.conf (or whatever name the user calls it) outside the site root.
This works in Mambo 4.5 but does not work in Mambo 4.6.
If you intend to create a new class perhaps this functionality can come back in?
Put the code for 4.7 branch but no way out at all. What next ........? 020-222
hi
I am still very new to .htaccess files so what I have is grabbed from online help sites. The problem that I am having is that when I turn the RewriteEngine on it makes it so that my awstats page is forbidden (403 error).
Here is the code
<Files .htaccess>
order allow,deny
deny from all
</Files>
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www.mysite.com$ [NC]
RewriteRule ^(.*)$ http://www.mysite.com/$1 [R=301,L,NC]
ServerSignature EMail
SetEnv SERVER_ADMIN mailto:myemail@hotmail.com
Options -Indexes
000-901 ! 000-897 ! 000-889