I have a problem with Drupal 6.20.
Possibly after a PHP update, site stopped working. I get:
Notice: unserialize() [function.unserialize]: Error at offset 0 of 22765 bytes in /PATH/includes/cache.inc on line 33
This is the line:
$cache->data = unserialize($cache->data);
I would appreciate any help.
This problem will happen when you have Drupal 6.x running over PostgreSQL 9.0 because the bytea type was modified.
There are some suggested solutions here: http://postgresql.1045698.n5.nabble.com/Bytea-error-in-PostgreSQL-9-0-td3304087.html - (liking to Wayback Machine)
Running this on the database should fix it:
ALTER DATABASE databasename SET bytea_output='escape';
Sounds like your Drupal cache has gotten corrupted.
The immediate solution would be to clear the caches. Three ways to clear the Drupal caches:
Log in to the site with the admin password and select the flush caches option from the menu. This will obviously only be possible if you can get into the site in the first place.
If you can't do that, you can use the Drush command-line utility to flush the cashes without having to go to the site.
If you can't even get Drush to work (or you just don't want to install it), you can do it manually by going to the the database in your favourite MySQL tool, and emptying all the tables whose names start with the word "cache_".
The real question is why this would have happened in the first place. Sadly, I can't answer that, without a lot more info about your set up (and likely spending some time investigating too).
The danger is that even once you've cleared your cache, the same error could occur again, so even if you do get it working again, it would be a good idea to dig around a bit and see if you can find out the root cause.
My guess would be a rouge module that's got a bug has written bad data to the cache. You might want to check the drupal site and Google to check the modules you're using to see if there's any that have had similar behaviour reported.
Also, you mention a PHP update: Please let us know which versions of PHP you went from and to. There are known issues with some Drupal 6 modules in PHP 5.3, although the core does support it. See http://drupal.org/requirements for more info.
Try a var_dump($cache->data). It could be that PHP is adding escape sequences and/or quotes due to magic quotes or similar.
It is probably because of bad data inside of your array, you can fix it like this:
$data= preg_replace('!s:(\d+):"(.*?)";!se', "'s:'.strlen('$2').':\"$2\";'", $cache->data );
$s_data= unserialize($data);
Related
im using joomla3 for my new site , i used 3.2.2 and currently update to 3.2.3. but its always giving me mysql errors form several tables when browsing ste also saving values from backe end
Error displaying the error page: SQL=SHOW FULL COLUMNS FROM sltdb_template_styles: SQL=SHOW FULL COLUMNS FROM sltdb_template_styles
How to overcome this .. please advice ?
It looks like database connectivity
Try to access the database from the application server using the command line. or try to access your database via PHPAdmin
If still no chance:
Here is fix - i got for google
Use Extension manager->Discover and Install, possibly followed by an Extension manager->Database and Fix when needed.
Joomla requires a proper working infrastructure. Something must have failed otherwise the update should have succeeded. The above steps are normal procedure for fixing when something went wrong. An alterative would be to restore and try again.
Also, Joomla allows you to break down the steps. Using the Extension manager install from directory is the least resourceful way to update. It requires you to download, extract and copy it to the webserver yourself.
Hopefully this will help someone. I had this issue after a server move and it turned out that it was due to a module (wp_posts) that had old db credentials in it, i corrected the credentials which fixed the issue.
Unrelated but one other thing to check if you have this type of issue is can you update things in admin, I had a secondary issues with was that APC cache was not enabled on the new webserver, i discovered that by trying to update things in admin and viewing errors.
The error 0 message is very unhelpful, it seems this could be module specific though rather than joomla itself but it seems quite poor that a module can block the entire site form working, some error trapping needed me thinks!
Cannot comment, yet ... (as a comment to logicc's answer)
Well, the "Error: 0" is indeed not very helpful, but with debugging turned on, you at least get a good idea of where the problem might be coming from:
24 JDatabaseDriver->loadObjectList() /.../modules/mod_wpposts/helper.php:91
25 JDatabaseDriverMysql->connect() /.../libraries/joomla/database/driver.php:1312
About the module blocking the entire page - that might make sense in some cases (a module so important that you would rather have the page not render, at all, than in part?), but it certainly seems like a bad default. For now, I think modules should take care of that themselves with some try-catch-ing.
Oke, i've been busting my head on this one.
I'm gonna try and keep things short, however, if you need more info, don't hesitate to ask.
I've written an import repo for an external firm, so we can import their data into our service.
quick overview of implemented logic?
ftp, grab xml file, parse it with simple_xml and do db stuff using laravel eloquent component.
on my dev machine,
every run gets parsed fully and all data is inserted correctly into the database.
problem
when i try the same thing on my production server.
I'm receiving a duplicate entry error, always on the same exact record. (unless i'm using another file)
pre script setup to help detect the error
on each run i do the following:
make sure i'm using the exact same files on both dev and prod
environment... (i've disabled the ftpgrab and uploaded manually to
the correct location)
truncate all the related tables so i'm always
starting with empty! tables.
i've manually triple-zillion checked for duplicates in the xml, but they're not in there.... and the fact that
my dev machine parses the file correctly confirms this.
what i tried
at this point, i've got no more clues as to how i'm supposed to debug this properly.
by now, i've checked so many things (most of them i can't even remember), all of which seemed pretty unrelated to me, but i had to try them.
those things include:
automatic disconnects due to browser
mysql wait timeouts
php script timeouts
memory settings
none of them seem to help (which was exactly what i was expecting)
another fact
my php version on my dev is 5.4.4 and the version on the production server is 5.3.2 (i know this is bad practise, but i'm not using any new features, it's really dead easy code, though it has quite a few lines :-) )
i've been suspecting this to be the cause, but
i've now switched to 5.3.14 on my dev... still the import runs without an issue
the changes from 5.3.2 to 5.3.14 are probably pretty minor
i've tried to manually compile the exact same php version, but i'm to inexperienced to properly do this. moreover, it probably wouldn't have the exact same specs anyway (i think it's pretty impossibly to ./configure exactly the same, considering the use of MacOs vs Ubuntu? especially for a noob like me)
So i've abandoned this path.
I've tried to find the differences in the php versions, but i can't seem to stumble upon anything that might be the cause to all this.
there was a change related to non-numeric keys in arrays (or strings for that matter) in version 5.4.4 (i think) but since i've now come to the conclusion that 5.3.14 also works, this definitely is not the issue. --- looking around insecurely hoping not having said anything downright stupid ---
quick thought while writing this:
the thing is, even though i'm getting the duplicate error statement.
The record did get inserted into the database.
moreover, the error gets triggered when having processed about 2700 (of total 6000) records.
the bound data to the query is actually the data of the second record in the xml file.)
I'm sincerely hoping anyone could put me on the right track for this issue :(
If you made it this far, but don't have a clue about what's going on, thx for reading and sticking to it.
If you might have clue, please enlighten me!
I have an old joomla installation which was hacked. All I know for now only index.php was changed and they messed with my user accounts. I downloaded index.php from the current version but at one point it calls $app->dispatch(); which requires a component name parameter in my version. Does anyone know what parameter this should be? I tried: null, 'home', 'application',...
Also I'm planning on updating to the newest version later, however I can't seem to find my current version number. I found somewhere that it is displayed in the admin pages but I can't access them yet. Can I find it in the code files somewhere?
EDIT: The index.php from version 1.5.22 worked. Apparently the correct version was 1.5.3. Does anyone know what else I should check that might have been hacked/messed with?
Why not get a copy of the version you used?
http://forum.joomla.org/viewtopic.php?p=2221953
You can go to the joomla project on
joomlacode.org, then select the search
tab. From there you type in "1.0.10"
and select Releases to search in. You
should get some results. Click on the
one you are searching for, the files
can be found on the files tab, this
time the tab is on a blue bar (more to
the bottom of the screen).
Although I'd recommend upgrading completely, to stop being re-hacked again.
====== Answer to second question
How big is the site? Usually if it's just a link spamming attack a quick once over will suffice.
The next issue is that you need to patch the hole that caused the problem, in this case upgrading to the latest Joomla (1.6 - I believe) is the first port of call.
Have you modifed the Joomla system in such a way that the hack could have been opened up by you?
My advice, reset the admin passwords and upgrade Joomla.
Very difficult to say anything else without seeing what the "hack" was.
I had to clean out a hacked Joomla install recently. My tip is to grep all the files base64_decode: some hacks consist of decoding a huge string that emits php.
find ./ | xargs grep base64_decode
The hack looked like this: error_reporting(0);eval(base64_decode('JGxMOXdGMWFZNHpY.....
This particular piece of code detected googlebot and other crawlers, and then emitted a list of spam links heavy on viagra. If a normal user agent string was used it showed a normal site. I had to use a firefox extension that changes the user agent to debug this.
The next step would be getting rid of the exploit and then either patching Joomla and waiting for the next exploit or switching to something more secure, like static html or a well-maintained CMS.
Fortunately Joomla has really nice documentation on how to recover from a hack. http://docs.joomla.org/Security_Checklist_7. As Pino mentioned, it is critical that you are always on the latest version to minimize your exposure to security exploits.
I've found two tools which create "simlinks" within Windows XP (I know they're not real links, but so it goes). The problem is that neither of them create something which I can use with WAMP.
Because I'll often want to link into a repository, I'll often want to keep the www folder contain mostly simlinks. I'd like to do the same under Windows but while Apache recognizes what this tool creates, I get the message: Fatal error: Unknown: Failed opening required 'C:/wamp/www/cwa/something.php' (include_path='.;C:\wamp\bin\php\PHP53~1.0\pear;C:\wamp\Zend\library') in Unknown on line 0 from PHP and C:/wamp/www/cwa/ is also not recognized as a directory by PHP either. (C:\wamp\www\cwa is supposed to be the link, BTW)
How do I fix this? This tool doesn't seem to create something which is recognized by Apache. Is there another tool which is recognized by both Apache and PHP? Is this some form of ini or conf issue?
edit
The two tools above are at these two links:http://www.rekenwonder.com/linkmagic.htmhttp://www.taranfx.com/create-symlink-in-windows
Try making a hard link instead of a junction point. You can use the fsutil command. See here.
I'm just going to mark this one as "answered" because there doesn't seem to be a word-around or, if there is, no one here has shared it.
The only other viable option is to use Apache's aliasing. I had hoped to avoid that because I prefer to modify conf's and htaccess as little as possible, but it looks like there isn't a choice here.
If you are willing to use to work with PHP then it recognizes the junction points however there is an odd caching behavior that seems to occur.
I am calling a PHP-Script belonging to a MySQL/PHP web application using FF3. I run XAMPP on localhost. All I get is this:
Connection Interrupted
The connection to the server was reset while the page was loading.
The network link was interrupted while negotiating a connection. Please try again.
There are a number of possible solutions ... depends on the "why" ... so it ends up being a bit of trial and error. On a fresh install, that's tricky to determine. But, if you made a recent "major" change that's a place to start looking - like modifying virtual hosts or adding/enabling XDebug.
Here's a list of things I've used/done/tried in the past
check for infinite loops ... in particular looping through a SQL fetch result which works 99% of the time except the 1% it doesn't. In one case, I was using the results of two previous queries as the upper and lower bounds of a for loop ... and occasionally got a upper bound of a UINT max ... har har har (vomit)
copying the ./php/libmysql.dll to the windows/system32 directory (Particularly if you see Parent: child process exited with status 3221225477 -- Restarting in your log files ... check out: http://www.java-samples.com/showtutorial.php?tutorialid=1050)
if you modify PHP's error_reporting at runtime ... in certain circumstances this can cause PHP to degenerate into an unstable state if, say, in your PHP code you modify the superglobals or fiddle around with other deep and personal background system variables (Nah, who would ever do such evil hackery? ahem)
if you convert your MySQL to something other than MyISAM or mysqli
There is a known bug with MySQL related to MyISAM, the UTF8 character set and indexes (http://bugs.mysql.com/bug.php?id=4541)
Solution is to use InnoDB dialect (eg sql set GLOBAL storage_engine='InnoDb';)
Doing that changes how new tables are created ... which might slightly alter the way results are returned to a fetch statement ... leading to an infinite loop, a malformed dataset, etc. (although this change should not hang the database itself)
Other helpful items are to ramp up the debug reporting for PHP and apache in their config files and restart the servers. The log files sometimes give a clue as to at least where the problem might reside. If it happens after your page content was finished it's more likely in the php settings. If it's during page construction, check your PHP code. Etc. etc.
Hope the above laundry list helps somebody someday ... probably myself when I run into it again and come back here looking for "how the heck did I fix it last time?" ... :)
It's possible that your script could be caught in an infinite loop. If that doesn't apply, then I'd check the error logs like TimB suggested.
It sounds like the PHP script you're calling is failing without returning a valid response. Depending on the level of logging that you have set up, this should generate an error in the Apache logfile, which will give you some idea of the problem. I'm not familiar with XAMPP, but you should be able to find out where the logs are, and look for an error that occurred at the time you made your request to the PHP script.
copying libmysql.dll to apache\bin folder may help you overcome this strange error
I solved this problem Upgrading the xampp\php\ext\xdebug\php_xdebug.dll
(changed to php xdebug v.2.0.5-5.3-vc9 )
I had the same problem and this is what i did.
I issued the http get command through php cli script, and as it turns out I had declared one class twice somewhere.
By the way , i use AMPPS on an mac
Hope this helps some one!
Try doing the request with Firebug enabled and see what info you can get out of that; I always find that using wget is helpful for seeing the raw HTTP interaction without worrying about Firefox's UI elements interfering.
If you are using certificates for ssl in Windows 2008 Server(iis 7) from old selfssl tool(iis 6), that is the problem. Sometimes Microsoft releases patches which can destruct all these old certificates. The solution is to generate them again.
copying libmysql.dll to apache\bin folder may help you overcome this strange error
Indeed this helped me to solve this problem
The connection to the server was reset while the page was loading.
Incase the issue is not working this did the trick for me.
1. I got a new zip directory for PHP and connected it with apache
2. I searched for the libmysql in the new php and inserted this to the apache/bin
its this libmysql.dll that is needed there and not the one form mySQL/bin.
ok at least thats the one that worked.
I experienced a very similar issue - which doesn't apply to the person who asked this question - but may be of help to others who are reading this page...
I had an issue where in certain cases PHP 5.4 + eAccelerator = connection reset. There was no error output in any log files, and it only happened on certain URLs, which made it difficult to diagnose. Turns out it only happened for certain PHP code / certain PHP files, and was due to some incompatibilities with specific PHP code and eAccelerator. Easiest solution was to disable eAccelerator for that specific site, by adding the following to .htaccess file
php_flag eaccelerator.enable 0
php_flag eaccelerator.optimizer 0
(or equivalent lines in php.ini):
eaccelerator.enable="0"
eaccelerator.optimizer="0"