1

[Mon Oct 17 13:49:16 2011] [error] [client aaa.aaa.aaa.aaa] PHP Notice: Array to string conversion in aaa/libraries/joomla/html/parameter.php on line 83

One suggestion found online was:

Edit parameters.php and change the line 83 as follows:

Before:

1

if (trim( $data )) {

After:

1

if ($data) {

But modifying core joomla files isn’t such a hot idea as one user notices. So the solution is fixing the plugin causing the problem in the first place:

Edit plugins/system/JoomSEO.php at line 46

1

$this->params = new JParameter($params);

replace with

1

$this->params = new JParameter($params['params']);

Edit ./includes/Cache/Lite/Function.php, find the line reading

1

<strong>$arguments = func_get_args();</strong>

and replace with:

1
2
3
4
5

$arguments = func_get_args();
$numargs = func_num_args();
for($i=1; $i < $numargs; $i++){
$arguments[$i] = &$arguments[$i];
}

Check now, it should be working. Enjoy your new old site

Long storry short, I changed the DNS and expected the problem to go away. Next day I was happy to find out that it didn’t. I pinged akismet.com from the console, tried http connection to it with links everything was fine. For good measure I tried other DNS entries, tried a mtr to akismet.com but still everything was fine and the key in Akismet Configuration refused to work.

Than, after a slap on my forehead I remembered THIS. Right, after

1
2

# service httpd stop
# service httpd start

Everything went back to normal.

While working on a test environment I noticed that php code was not finding new hosts. The hosts were served by an internal, private dns server which was configured as default in resolv.conf

Warning: file_get_contents(http://www.testdomain.com/webapp/file.php) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 500 Internal Server Error in /var/www/htdocs/test.php on line 4

192.168.1.40

[root@jentlaibm01 manager]# cat test.php

1
2
3
4
5
6
7

<?php 
error_reporting(E_ALL); 
ini_set('display_errors','on'); 
echo file_get_contents("http://www.testdomain.com/webapp/file.php"); 
$ip = gethostbyname('www.testdomain.com'); 
echo $ip; 
?>

And this is where the fun started!

The folders and files appear correctly, I can navigate and I can download them. Only that the files, even if apparently having the same size are corrupted. I checked the FollowSymLinks and as expected was set as required. I tried wget in the command prompt to see if I could find some enlightment but I got the following errors:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# wget http://192.xxx.xxx.xxx/windowsshare/folder/file.jpg
 --09:18:00--  http://192.xxx.xxx.xxx/windowsshare/folder/file.jpg
 => `file.jpg'
 Connecting to 127.0.0.1:80... connected.
 HTTP request sent, awaiting response... 200 OK
 Length: 763,685 (746K) [image/jpeg]
 
 0%
 [                                                                  ]
 0             --.--K/s
 
 09:18:00 (0.00 B/s) - Connection closed at byte 0. Retrying.
 
 --09:18:01--  http://192.xxx.xxx.xxx/windowsshare/folder/file.jpg
 (try: 2) => `file.jpg'
 Connecting to 127.0.0.1:80... connected.
 HTTP request sent, awaiting response... 200 OK
 Length: 763,685 (746K) [image/jpeg]
 file.jpg has sprung into existence.
 Retrying.
 
 --09:18:03--  http://192.xxx.xxx.xxx/windowsshare/folder/file.jpg
 (try: 3) => `file.jpg.1'
 Connecting to 127.0.0.1:80... connected.
 HTTP request sent, awaiting response... 200 OK
 Length: 763,685 (746K) [image/jpeg]
 
 0%
 [                                                                  ]
 0             --.--K/s

and it will continue like this creating empty files.

Especial the has sprung into existence baffled me. Also note that symlinking any other folder, even mounted as smbfs instead of cifs worked perfectly. At this point changing the mount to smbfs would have solved my problem but curiosity was stronger.

As it turns either apache or (more likely) the cifs driver has a bug. You can work around it by setting the following inside your apache configuration.

EnableSendfile off

Further upgrades will probably eradicate this problem.

I already knew that .htaccess overrides were allowed since I used .htaccess to enable a seo component for the site. So adding the following lines to .htaccess (in the root folder of his site) was enough to allow large uploads using a php upload.

If it doesn’t exist you’ll need to create a text file named .htaccess in the root of the site containing the following code:

1
2
3
4

php_value upload_max_filesize 30M
php_value post_max_size 30M
php_value max_execution_time 250
php_value max_input_time 250

If you don’t see an increase of the allowed upload size it means that you are not allowed to override this settings and you’ll need to contact your hosting provider.