Most severe error I ever had and my methods to work around it, don´t work.
Installed maybe 10 new modules (I have near 250) and updated a few like a suspicious one wysiwyg_imageupload from the 1 to the 2 series.
Suspicious, because it talked about about possible problems upgrading. But the other 10 modules are maybe even more likely to have caused the problem.
update.php worked and resulted in two new tables for wysiwyg_imageupload 2 series.
But then my site was gone and instead "XML Parsing Error: not well-formed", this happened after ticking the new modules on the page
.../admin/build/module
After time, I have learned that if I hit the escape button quickly on loading, I can still see my contents, but without the left and right colomn.
The error message that follows has nothing to do with the real problem; if I rename that module in question with a dot in front (so the module is not recognized anymore), another error shows up from another module (after 4 modules who gave error message after each other, I gave up this method). Also renaming/deactivating the 10 installed modules didn´t work. This always worked before as a bypass when a new module resulted in a problem. Loading the old 1 series wysiwyg_imageupload didn´t work, nor deactivating that module.
I looked on google and drupal for the error message "XML Parsing Error: not well-formed", but couldnt find a general explanation what it means and the specific explanations about certain modules like xmlsitemap, didn´t seem to be involved. I de-activated them too without any result.
I give here my latest error message that I can see on the main page when I quickly hit the escape button before the page is fully loaded, But I suspect that none of the error messages has something to do with the later xml parse error. But to be sure I give them here:
# user warning: Table 'mysite_alba.albapm_block_user' doesn't exist
query: SELECT recipient FROM albapm_block_user WHERE author = 1 AND recipient IN (0) GROUP BY recipient in .../sites/all/modules/privatemsg/pm_block_user/pm_block_user.module on line 183.
(above warning was repeated another 4 times)
# warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'ctools_access_menu' was given in .../includes/menu.inc on line 452.
(above warning was repeated another 3 times)
# warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'context_blocks' was given in .../includes/theme.inc on line 656.
(above warning was repeated another 10 times)That indymedia_alba has some database errors before with new modules, but not resulting in real site problems.
Context probably gives errors, because I de-activated it after de-activating ctools or another module that first gave an error that then changed in an error for context.
Activated/renamed back again context => now nothing will load anymore and immediately get this message:
Fatal error: Call to undefined function ctools_include() in .../sites/all/modules/context/context.module on line 443
array(4) { ["type"]=> int(1) ["message"]=> string(44) "Call to undefined function ctools_include()" ["file"]=> string(74) ".../sites/all/modules/context/context.module" ["line"]=> int(443) } OK, activate/renamed ctools again:
Now the left and right column also load, before getting ""
the error messages before the screen wenmt away, were:
# user warning: Table 'mysite_alba.albapm_block_user' doesn't exist
query: SELECT recipient FROM albapm_block_user WHERE author = 1 AND recipient IN (0) GROUP BY recipient in .../sites/all/modules/privatemsg/pm_block_user/pm_block_user.module on line 183.
(above warning was repeated another 3 times)
# warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'imce_access' was given in .../includes/menu.inc on line 452.
(above warning was repeated another 2 times)Next to understanding what has happened and what means XML parsing error: Any idea how to get the site back working again?
(otherwise I reinstall everything and copy the only 20 articles back out of the MySQL database)
Comments
browser dependent error?
the parser error is with my admin login with seamonkey browser (mozilla).
but when I use IE without loggin in, the site shows up pretty normal
account suspended; deleting database and parts of the install
Very nice again! Bluehost suspended my account for the second time and that it will be definitive if there ever is a 3rd occasion. Yes Drupal database problems (also with a second advanced install). So guess what? I have done it two times before: shutting down all the drupal installs and wait 1-2 years; maybe the future drupal can do it all without errors if&when all the modules are ready for the new release (like 7 or 8)? Or shut it down definitively, as I did after 1-2 years trying TikiWiki in favor of Drupal? There is only one problem; there is no alternative yet for Drupal. And I have gotten much further this time, although I had never started this work 4 years ago, if I had known that I wouldn't have succeed in anyway near half a year work.
So now have to go for the safe-sex very secure approach; deleting my installs, reinstall, not ticking some advanced modules (or even putting them out of the modules dir for a long time), installing again if there happens a drupal database error. Then manually copying the articles back in drupal as new articles, out of phpmyadmin of the old database. Then ofcourse I have to learn how one can repair drupal databases instead of reinstalling everything. Also how one safely can remove a module that causes an error and the site only gets back again by removing the module first instead of ticking-off. Having another hoster/vps ready and all the files, because this was the last time Bluehost accepted these drupal errors.
Sounds like you've got a dogs
Sounds like you've got a dogs breakfast there, so it's hard to untangle what's really happened.
Generally,
warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback,is a symptom of modules being incorrectly removed. Which seems like what you've been doing, but it's not too awful.The menu cache remembers all the paths and callbacks of modules it expects to see - so it doesn't have to rebuild them too often. If you feel the need to remove/rename/delete modules (which is fair enough) then visit the admin - modules page and just save once.
That triggers a module-menu rebuild and will throw out any dangling menu items for modules that no longer exist.
Can't tell where the XML error is coming from. From your description of hitting 'escape' it sounds like it's a client-side javascript alert? Thus it's one of your AJAX widgets, something clever on the page like a twitter feed, plugin or something.
Without knowing how you got into this state, I can't suggest how to back out of it correctly
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Thanks for making
Thanks for making suggestions, Dan.
Indeed when installing so many modules, its just too much work only install one module at a time and then test first. Same for updating; often more modules at the same time, sometimes with several new modules. But if it gives a severe error, I have to remove the module that seems to give the erro, to get the site back (but this time that didn't work!). But then here is a small database error that i have to correct manually, but dont know how yet.
Yes, javascript, jquery a.s.o. (don't know the difference) they were already given minor errors, like the click-able multilingual buttons showing up two times and a difference between the admin user and anonymous (not working, but before was).
Anyway, I'm going to start over and hope to do something more structural/safer this time.
I just found some file named "error_log" in my drupal dir:
(then the other install I was working on also caused errors, so its unclear if this/other/both install was the cause for bluehost to suspend)
Here are the modules I'd installed (a very few were upgrades):
modules May 25th
modules May 24th
not laughing what I did on the other install..:
After those problems of this install that continued, I made another install of Pressflow core + all my modules + Indymedia Alba + those of OpenMedia and OpenPublish. Yes it gave some errors, I think even missing patches in core for some of those other modules.
Almost sure I haven´t ticked that very dangerous drupal core "syslog" on, because always watching that one, after my account was suspended for ticking it on one time before.
But both installs gave 'errors', or at least that there was a clog up of their servers error log, resulting in Bluehost saying this is the last time they will restore the account, after I have taken measures.
So deleted the new install+database, removed the database user for this install and will install again without db-errors and lesser modules, before manually copying the articles back by using phpmyadmin out of the old db. Then have to learn how to repair drupal databases so I can act immediately in future, before start building a complex site again. AND FOR SURE I'M GOING TO FIND AND DELETE DRUPAL CORES "SYSLOG" OPTION!
Syslog is not an option
Syslog is not an option non-sysadmins should ever enable because they don't know what they are doing, and don't have the ability to access or do anything with the information it logs.
Although there is a reason for syslog to be in the 'core' distribution, there is not a reason for non-admins to be able to even turn it on.
In this case, it seems the BlueHost admins are actually being responsible enough to pay attention to their sysadmin logs and are objecting to folk filling it with noise. +1 to Bluehost for actually caring about warning signs!
Go +1 on #800438: webhost problem with syslog.module If you find that sometimes users have to be protected from making their own mistakes. (In this case I'd agree)
.dan. is the New Zealand Drupal Developer working on Government Web Standards
this time maybe not syslog, but a parallel modules-method?
Even seriously doubt that I´d turned syslog on this time; always double (un)checking since last deactivation of my account. OK, last morning I was tired and had to leave in a hurry to go with my girlfriend to forensic medical research after she was beaten two days ago with a metal tube while they tried to rob her bag. Don't think I made that error again as I was anxiously avoiding something like that, but human errors under these circumstances are theoretically possible.
So awaiting more explanation of Bluehost, if that module was turned on this time. Theoretically there are other possibilities; that an erroneous install itself accidentally turns a module on. For example in my first install OpenID was suddenly working, while I never had activated it (maybe as it had to be turned on to get another module working, so the system asks for a confirmation to turn that also on). So in the second install, maybe combining Openpublish, Openmedia, Pressflow, and their many specialty modules together with my many modules, maybe could have opened some backdoor that is similar to syslog?
Installed everything again
Installed everything again and now the same xml parsing error after running the update.php and returning to the main page.
The following queries were executed: imce module Update #6201
* CREATE TABLE {imce_files} ( `fid` INT unsigned NOT NULL DEFAULT 0, PRIMARY KEY (fid) ) /*!40100 DEFAULT CHARACTER SET UTF8 */
XML Parsing Error: not well-formed
Location: .../admin/build/modules/uninstall
Line Number 566, Column 48:swekey_attach_url = "?q=swekey_attach&swekey_id=$swekey_id&user_id=1";
But when I rename swekey with a dot in front =>
XML Parsing Error: not well-formed
Location: .../admin/build/modules/uninstall
So it doesnt matter for the problem deleting modules; after a day work back at the same point again... There must be another method, instead of reinstalling with a new database?
UPDATE: removed theme => no result; removed part and all modules => no result (so I put them all back)
But now I know my admin password (last install didn't know, mail wasn't working either and couldn't decode as it was encrypted on another way than md5 and only seamonkey browser was always logged in) => logged in with IE and can now use the admin pages.
The layout for IE is completely changed, but IE is not giving that error message and not blocking the screen. The banner picture for example has to be stretched full screen and there are no colomns; all of them were set in blocks, but not working:
http://mi-cr.org
=> so now I can tick off modules, so suppose in some hours will get the site back and know what module(s) caused it...
=> ticked off a lot of modules, but no result yet.
=> then went to blocks, because the error has something to do with the blocks not showing up (banner block not stretched, left and right columns are gone)
Yes, here are a lot of errors shown:
FOUND: ITS THE QUIZ MODULE!!!
FOUND: ITS THE QUIZ MODULE!!!
And don´t understand why they keep going on a severe error for a year:
deprecated use of form array in matching administration page - falcon - July 13, 2009 - 08:42
http://drupal.org/node/517602
A week work and partly to blame in two de-activations of webservices, all for no reason! Errors can happen but after one year still the same?
OK (1); maybe an old error came back in another way than one year ago, in the recent 6.3.5 release of end April, so who knows; an acceptable human error from the very good people who are contributing these very good modules. Then installations are different, so these errors might not happen in all installations, because the error might be connected with problems this module has with some other optional modules
OK(2): The severity of this problem had to do with several accidental factors that all came together; the only logged in browser Seamonkey not showing up admin pages (while IE does, but couldnt login), forgot my password, emailing password recently had stopped working, password was encrypted by a special module not md5 and couldnt fill in another md5 password in phpmyadmin, other database problems and syslog clogging up, near 250 modules so digging in a haystack what could have caused problems...
- - - - - - - - -
Now I dont know how to get rid of this (and the new install was so clean until half a day ago...), without reinstalling all over again:
Database schema Inconsistent
The Schema comparison report shows:
* 95 modules with matching tables
* 53 extra tables
* 15 warnings
* 5 module with mis-matching tables
The database schema comparison report provides more details.
still some little remnants of "xml parsing error"
yes; the sites banner is stretched again, the two sidebars are back, also Seamonkey is working without that parsing error, but..:
One of the newly installed modules is drawing and most -but not all- of the new "drawing test" still returns the same error: "xml parsing error" with seamonkey (mozilla) browser, while IE has severe theme errors but still shows most of he site.
Then -only in Seamonkey- in admin/build/modules there is a blank middle screen untill the end of the left column and then the modules list starts. IE doesnt return this error (and Seamonkey never had these errors before something went wrong with my install). Only part of the admin pages is now like that; admin/reports/status shows up normal for example.
De-installed (button) everything that came under "admin/build/modules/uninstall", but the database error list (from some database reporting module) with the same contents keeps showing up.
Errors remaining on admin/build/block page
/includes/common.inc:
Schema? => ticked off schema and all depending (sub)modules, then cleaned:
Desinstalar Nombre Descripción
Data Node Relate data tables to nodes.
Data Taxonomy Relate data table entries to taxonomy terms.
Migrate Import content from external sources
Schema The Schema module provides functionality built on the Schema API.
Table Wizard The Table Wizard provides services for managing database tables
=> same errors on block page continue...
/modules/block/block.module:
=> this must be enough data for some module php experts to know what is happening here with the block core module?
=> OK, but the error messages on the block page disappeared; it seemed to be a truncated cck upload; the strange thing is that it was unpacking without an error message. Bluehost had problems uploading, but finally I succeeded to upload the full KB´s and the error messages were gone. But the middle screen of most admin pages only starts after the end of the left column...
last error disappeared, must be one of these modules:
vinked off a lot of modules and now again, this time a whole bunch. Finally the middle page/column shows up at the top and not anymore a blank middle-screen untill the end of the left column.
So must be one of these modules causing it:
Desinstalar Nombre Descripción
Advanced Forum Activa la vista y semejanza de otros softwares populares de foro.
Colorbox A light-weight, customizable lightbox plugin for jQuery 1.3 and 1.4.
Composite Layout Provides a composite layout for nodes and can also display other nodes and blocks.
Content Templates Create templates to customize output of teaser and body content.
Content Moderation Content Moderation
Content Taxonomy Autocomplete Defines a autocomplete widget type for content_taxonomy
Content Taxonomy Options Defines a option widget type for content_taxonomy for selects, radios/checkboxes
Content Taxonomy Tree Defines a dynamic tree widget for Content Taxonomy
Date Popup Habilita calendarios emergentes y widgets de ingreso y selección de fechas y horas basados en jquery.
Date Repeat API Date Repeat API para calcular fechas y horas repetidas a partir de reglas iCal.
Email Defines an email field type for cck
Embedded Audio Field Defines a field type for displaying third party music, podcasts, and other audio, such as podOmatic and Odeo.
Embedded Image Field Defines a field type for displaying images from third party providers, such as Flickr or Photobucket.
Embedded Video Field Defines a field type for displaying third party videos, such as YouTube and Google Video.
Embedded Wave Field Defines a field type for displaying waves from third party providers, such as Google or ...
Feeds Defaults Get started: useful default configurations for Feeds: RSS/Atom aggregation, OPML import, node import and user import.
Fieldgroup Create display groups for CCK fields.
FileField Meta Add metadata gathering and storage to FileField.
Flag actions Execute actions on Flag events.
Flag friend access control Allows users to specify that only their friends can view this piece of content
Flexifilter Allows creatation of flexible input filters entirely through the user interface.
Friendlist Access Give access to nodes depending on relationships
Hacked! Shows if drupal or any of its modules have been changed
ImageAPI GD2 Uses PHP's built-in GD2 image processing support.
Imagecache Canvas Actions Actions for manipulating image canvases layers, including watermark and background effect. Also an aspect switcher (portrait/landscape)
Imagecache Color Actions Additional ImageCache actions, providing color-shifting, brightness and alpha transparency effects.
Imagecache Custom Actions Allow direct PHP code manipulation of imagecache images.
Imagecache Text Actions Display simple or dynamic captions on images.
Image Attach Allows easy attaching of image nodes to other content types.
Image FUpload (image) Allows uploading several images all at once to image module
Image Gallery Allows sorting and displaying of image galleries based on categories.
Image Import Allows batches of images to be imported from a directory on the server.
Image assist This module allows users to upload and insert inline images into posts. It automatically generates an Add image link under the textarea fields of your choice.
Language icons Adds icons to language links.
Location CCK Defines a Location field type.
Number Defines numeric field types.
Common syndication parser Provides an XML parser for FeedAPI modules. Requires PHP5.
SimplePie parser Provides an XML parser for FeedAPI modules. Uses SimplePie library. Requires SimplePie 1.01+.
Phone - CCK The phone module allows administrators to define a CCK field type for phone numbers.
Pollfield Permite que su sitio capture votos sobre diferentes tópicos en forma de preguntas de opción múltiple.
Sound Manager 2 playlist CCK formatter Defines a formatter for render the file to soundmanager2
Activate filefield or audio module.
Translation overview Provides an overview of the translation status of the site's content.
A whole list, but I will edit this posting when this list gets smaller, untill the module that causes the last part of the errors, is found.
=> OK; I ticked all these modules on -bit by bit- , but the error of the empty middle columns untill the end of the left column, hasn't returned!
I even had vinked related modules on...
OK, now rebuilding permissions, update.php and cron and see what happens then:
YES; no errors & no idea why there were errors and why that error has disappeared; sometimes reinstalling modules works, sometimes there is a specific sequence in wich modules need to be activated?
So next step: installing schema & related (sub)modules again and see if there still are database errors (before step by step installing the earlier other omitted modules again):
=> again the install doesn't show imminent errors..!
=> /admin/reports/status
* Field micrevent_timezones.offset: no Schema type for mysql type time.
* Field micrevent_timezones.offset_dst: no Schema type for mysql type time.
...
Database schema Inconsistent
The Schema comparison report shows:
* 92 modules with matching tables
* 3 extra tables
* 17 warnings
* 6 module with mis-matching tables
* Field micrevent_timezones.offset: no Schema type for mysql type time.
* Field micrevent_timezones.offset_dst: no Schema type for mysql type time.
* imc_node_moderation.nid is type int but its default 0 is PHP type string
* imc_node_moderation.status is type int but its default 0 is PHP type string
* imc_feature_proposal.nid is type int but its default 0 is PHP type string
* imc_feature_proposal.active is type int but its default 1 is PHP type string
* imc_feature_vote.nid is type int but its default 0 is PHP type string
* imc_feature_vote.value is type int but its default 1 is PHP type string
* imc_feature_vote.block is type int but its default 0 is PHP type string
* pollfield_votes.field_name_delta is type int but its default 0 is PHP type string
* pollfield_votes.weight is type int but its default 0 is PHP type string
* og_term.tid is type int but its default 0 is PHP type string
* og_term.nid is type int but its default 0 is PHP type string
* og_term.public is type int but its default 0 is PHP type string
* messaging_message_parts.data is type text and may not have a default value
* blogapi_files.fid is part of the primary key but is not specified to be 'not null'.
* fupload_previewlist.fid is part of the primary key but is not specified to be 'not null'.
* media_mover_files.mmfid is part of the primary key but is not specified to be 'not null'.
* media_mover_config_list.cid is part of the primary key but is not specified to be 'not null'.
- Match: 205
- Mismatch: 9
- Missing: 9
- Extra: 3
OK, site is working again without any apparent error, but how do I clean up the database without reinstalling??!
(if I succeed repairing this instead of reinstalling, I have finally -after more than 3 years and failing 1 and 2 year before- passed the Drupal wannabee stress test for beginners basics being able to maintain and build a more advanced site!)
last part; database cleanup..:
=> ticking off all modules (and related) that give a mismatch in Schema and then /admin/build/modules/uninstall
=> All mismatches disappeared (but the question is if they come back when ticking on again..?)
But: these remained after trying to uninstall everything with a similar name:
Extra (2):
Tables in the database that are not present in the schema. This indicates previously installed modules that are disabled but not un-installed or modules that do not use the Schema API.
* comments
* node_comment_statistics
And these errors are shown at the start of the page /admin/build/schema/compare:
* imc_node_moderation.nid is type int but its default 0 is PHP type string
* imc_node_moderation.status is type int but its default 0 is PHP type string
* imc_feature_proposal.nid is type int but its default 0 is PHP type string
* imc_feature_proposal.active is type int but its default 1 is PHP type string
* imc_feature_vote.nid is type int but its default 0 is PHP type string
* imc_feature_vote.value is type int but its default 1 is PHP type string
* imc_feature_vote.block is type int but its default 0 is PHP type string
* pollfield_votes.field_name_delta is type int but its default 0 is PHP type string
* pollfield_votes.weight is type int but its default 0 is PHP type string
OK, these messages disappeared after disabling Indymedia Editor and Pollfield, but remaining:
Extra (2):
Tables in the database that are not present in the schema. This indicates previously installed modules that are disabled but not un-installed or modules that do not use the Schema API.
* comments
* node_comment_statistics
=> The core module "comment" doesn't show up in the core list, but indeed is in the core modules directory!
Instead somewhere else is:
Comment 6.9-imcalba A content type used to comment on other node content.
(this is not a name of an existing module in the sites/all/modules dir, but part of an indymedia alba module but is deactivated)
deleting tables, as there seems no other way?
"comments" and "node_comment_statistics" didn't go away on a normal way, so now in phpmyadmin deleting/dropping these tables (after saving to be sure) => performed
=>
/admin/build/schema
Match (186)
Mismatch (0)
Missing (0)
Extra (0)
HÉ-HÉ ..!
= = = = = = = = = = = = = = = = = = = = =
But now the follow-up: constructing again what was deleted and hoping no database errors return. But I fear some modules themselves have database errors and probably even the Indymedia-Alba, but lets see...
The lesson (next to practising): on a life site containing data, always back up database before new modules or upgrading. And oeps; what if the backup has an error and can't be placed back..? More secure: only install security updates and other updates after a month if there were no bugs found. Or copy your website and change the copy first and see if the database keeps correct, next to other possible errors, before updating your original real site...
re-installing; some give database errors AGAIN
Just a few core modules re'activated (+update.php + cron + rebuild permissions to be sure) and the first database error is back already:
Mismatch: blogapi_files
column fid - difference on: not null
declared: array('description' => t('TODO: please describe this field!'), 'type' => 'serial')
actual: array('description' => t('TODO: please describe this field!'), 'type' => 'serial', 'not null' => TRUE)
so lets stick with this tiny error & resolve, before continuing?
Not that easy, because this core module is wrong and no-one cared to include a patch in the 6.16 version that came almost 2 months after the official bug report. Even now, many months later, no-one seems to care to repair this and have ready to include in 6.17:
Schema error with mysql - http://drupal.org/node/680938
So re-installing all the modules that gave errors, will be a mess again because here is a clear structural Drupal error and that is why Bluehost used me to bring over this message to the Drupal community (next to that I lost my site for a week now and counting).
ahh, but here is some explanation: http://www.lullabot.com/videos/database-fun-schema-module
Now a very important question is if there sometimes might be a good usable reason for differences between "declared" and "actual" and being the result of bad programming, but the resulting "actual" sometimes necessary? Or should it always be corrected to the "declared" value?
mess returning and hunting down faulty modules & faulty messages
Its a real mess, all the "Schema" database error messages. Some are just minor error messages for different MySQL versions; maybe its even impossible to write the correct code for the most used versions. Sometimes the code seems to be corrected automatically for a MySQL version and then Schema module detects an error. To sort one error out as probably innocent, took me half a day as a non-SQL expert:
Schema error with mysql - http://drupal.org/node/680938
Then the database errors have returned as I ticked modules back on, but there is not yet enough reporting and resolving on Drupal about the database mismatches of some modules.
Also one error returned of only IE internet explorer browser not showing the (Tendu) theme anymore, after two weeks this and other errors together, I finally could determine its the Jquery Menu module:
Drupal Themes not working on Internet Explorer, Please Help - http://drupal.org/node/794868#comment-3039250
same with D 6.17 + IE CSS optimalisation
Installed for the 5th time now. So lets tick a lot of modules on at once; maybe all the patches in Drupal 6.17 and the solution for the IE theme errors, also result in that the parse errors don't return?
NOPPES...
Problem is still there, so starting all over again sorting out what it can be..?
IE shows OK now, so maybe a module is needed like Mozilla-Parser-Repair ?
IE shows this error:
warning: Invalid argument supplied for foreach() in /home3/clearxst/public_html/mi-cr/sites/all/modules/image_gallery_access/image_gallery_access.module on line 314.
So login with IE => the IE theme-less problem returns, this time with the standard Drupal theme and with the IE CSS patch! Not documented , what now?
Unsupported operand type
Now on uninstalling some modules, this error:
Fatal error: Unsupported operand types in .../modules/system/system.module on line 627
array(4) { ["type"]=> int(1) ["message"]=> string(25) "Unsupported operand types" ["file"]=> string(62) ".../modules/system/system.module" ["line"]=> int(627) }
OK; I'm going to reinstall with a new database for the 6th time now...
Something that is different now in the other Seamonkey (Mozilla) browser:
"XML Parsing Error: junk after document element"
Maximum modules+themes a logical 264 ?
I'm starting to think that maybe it just has to do with the amount of core and additional modules & themes, crossing some barrier, like a logical 2x2x2x2x2x2x2x2 = 8 bits? Or whatever... It's not the first time; one and two years ago I had similar problems on many modules and then gave up for a year.
OK, see in another thread I should test with feed validator:
http://drupal.org/node/83603 => http://feedvalidator.org/
Probably several modules cause this problem, especially in certain combination's and other co-factors..?
JQuery Menu
It's clear that JQuery Menu is involved in some (but not all) of these errors, but the developer says that other modules are to blame because the others contain small errors that come to light when activating JQuery Menu:
So the conclusion might be: If you really need JQuery Menu; you need to know that from the start, not later: When you have a lot of modules and THEN start using JQuery Menu, its a real mess and can be almost impossible to find out which combination of modules causes the error. Then after activating JQuery Menu as the first: ticking every module on separately and running all checks before adding the next module, like in several browsers, logged in and out... (oops, 200 times..?).
So I should first see if I get all these modules running without errors without JQuery Menu. If & when I succeed and have isolated modules that also give problems without JQuery Menu, I can re-install and test again for every module on top op JQuery Menu... Suspect I have at minimum a 40 hour working week to go yet...
Re-instal step by step, where start the errors...
Activado Regulación Nombre Versión Descripción
Activity 6.x-2.x-dev Allow users to see their friends' activity on the site.
Depende de: Token (activado), Trigger (activado)
Requerido por: Activity comments (desactivado)
Activity comments 6.x-2.x-dev Allow users to comment on activities
Depende de: Activity (desactivado), Token (activado), Trigger (activado)
# warning: Invalid argument supplied for foreach() in .../includes/common.inc on line 3338.
# warning: Invalid argument supplied for foreach() in .../includes/common.inc on line 3259.
But error disappears on reloading the page (?)
now the real errors start:
ticked everything under "drawing" (+ rebuild permissions, update.php, cron.php)
=>
XML Parsing Error: not well-formed
Location: .../admin/build/modules
Line Number 745, Column 162:
Charts & Graphs might have nothing to do with it, as my earlier experience is when I delete this, than the parser error remains pointing to another and then to one another module a.s.o.
The parser error is in Seamonkey (Mozilla) and nothing of the site is shown anymore.
But IE shows the site, but only without the theme and columns.
So I continue in IE with the admin account:
admin/settings/performance => Partial optimization for theme CSS development (from the "IE CSS optimizer" module)
=> IE browser gets the site back to normal now, but Seamonkey/Mozilla continues with only the XML Parser error on the screen
So now going to admin/build/block/list & on that page are these errors:
removing all blocks =>
no effect on errors...
.../admin/content/node-settings/rebuild , update.php, cron.php =>
no effect on errors...
In between upgraded to the newest 6.x-2.x-dev version of Activity, update, settings rebuild, cron =>
no effect on errors...
So now removing the drawing module; .../admin/build/modules = tick off:
(first stage)
Drawing demo 6.x-2.x-dev
Drawing GD toolkit 6.x-2.x-dev
Drawing SVG toolkit 6.x-2.x-dev
=> site returns in Seamonkey browser and no errors more on block page!
The module is NOT removed by .../admin/build/modules/uninstall and still these module parts are ticked on:
Drawing 6.x-2.x-dev
Drawing graph 6.x-2.x-dev
Now ticking on again: Drawing demo 6.x-2.x-dev (+nr,upd,cron) => ALL ERRORS RETURN
ticking off "Drawing demo" => SITE BACK, no block errors
ticking on again "Drawing GD toolkit" (+rebuild, update, cron) => NO errors
ticking on again "Drawing SVG toolkit" => (+rb,ud,cr) => NO errors
activated some blocks again => NO errors
CONCLUSION: Only "Drawing demo" of the "Drawing" module is 'rotten'.
=> Issue: http://drupal.org/node/819366
(& I have to continue this research, expecting to find more conflicting modules)
activated: content access, image access a.s.o.:
This error is only for logged out user, not for admin.
=>
............. (editing, soon...)
= = = = = = = = = = = = =
Then some error on the Charts page:
I'm getting this error also:
I'm getting this error also:
warning: Invalid argument supplied for foreach() in /includes/common.inc on line 3338.
warning: Invalid argument supplied for foreach() in /includes/common.inc on line 3259.
find any fix for this?