| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | theme system |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | needs review |
| Issue tags: | needs backport to D7 |
Issue Summary
Issue Summary:
Theme .info files which do not properly define the 'name' attribute break the menu generation. system_menu() provides the menu entries corresponding to themes -- the relevant code is:
<?php
foreach (list_themes() as $theme) {
$items['admin/appearance/settings/' . $theme->name] = array(
'title' => $theme->info['name'],
// ...
);
}
?>In the case of a malformed theme .info file, $theme->info['name'] can be NULL, causing the following error:
WD menu: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column [error]
'title' cannot be null: INSERT INTO {menu_router} (path, load_functions,
to_arg_functions, access_callback, access_arguments, page_callback, page_arguments,
...The actual error message is very long and difficult to diagnose.
Nowhere do we verify the required attributes of the .info file are even set. This could be done in _system_rebuild_theme_data(), for example. Or perhaps wrapping $theme->info['name'] in a check_plain() call would be sufficient (as is done in block.module).
Steps to Reproduce:
drush dl sky-7.x-1.0
drush -y vdel menu_masks
drush cc allI've attached the simplest patch for this bug, namely one that sets $theme[$key]->info['name'] to $key if it is not already set. (In the cited example, $key here would be 'sky').
Recommendations
There are at least two possible fixes:
- Set the $theme->info['name'] to the theme $key if it is not provided. For example, the sky theme would have $info['name'] set to 'sky'. Optionally write a warning to the watchdog.
- Raise an exception if $theme->info['name'] is not provided.
Status
A patch implementing the first recommendation is available in #58, but has a typographical error as noted in #66.
Comments
#1
#2
I had a similar issue on LAMP... I deleted my D7 DB, recreated it, reset my settings.php file, cleared my browser's cache and started the installation process over again... worked that time.
#3
Yes, i have the similar case too. I am with D7, XAMPP, mysql DB with both Window XP and Vista. I try to back up a database by just copying the whole directory. When restoring, I just create a newly table with the same name of the directory (database) with phpmyadmin and paste it back to the directory under /mysql/data in window file system. It was working fine when in D6 but not in D7. Now, I have to formally create the xxx.sql file to back up and restore the whole database.
#4
I am installing both Alpha3 and head this morning and still getting both these errors with the Acquia stack installer.
#5
I just wanted to update this as I was getting this error just today with the most recent HEAD checked out as of 8:30 this morning. Simply dropping the db and reinstalling helped but there may be an underlying problem.
Edit**
System info:
Ubuntu 9.10
Apache 2.2.12
PHP Version 5.2.10
#6
Same problem every time using latest MAMP:
http://www.mamp.info/downloads/releases/MAMP_PRO.dmg.zip
and a fresh database created using:
mysql -u root -p <<EOFDROP DATABASE IF EXISTS \`drupaldb\`;
CREATE DATABASE \`drupaldb\` DEFAULT CHARACTER SET utf8;
quit
EOF
#7
Same here with RC2, php-5.3.4,nginx-0.8.53 & mariadb-5.1.53.. setting to major since this not only affects d7 but other httpd and php versions.
#8
@likewhoa: Can you confirm this happens for the latest 7.x-dev version of Drupal?
The error is happening because $ancestors is somehow empty:
<?php$parts = array_slice($original_map, 0, MENU_MAX_PARTS);
$ancestors = menu_get_ancestors($parts);
$router_item = db_query_range('SELECT * FROM {menu_router} WHERE path IN (:ancestors) ORDER BY fit DESC', 0, 1, array(':ancestors' => $ancestors))->fetchAssoc();
?>
#9
subscribing... i'm testing d7 rc3 with:
ubunutu 10.10 (Linux 2.6.35 64-bit)
apache 2.2.16
mysql 5.1.49
php 5.3.3
#10
@bfroehle The problem with the dev snapshot is that it doesn't detect my MariaDB server and just gives me option for postgresSQL only even though it's not running. I also have another issue which I need to reproduce on other servers which involves not being able to install while in https.
EDIT: I forgot to update this comment with:
If you compile php-5.3.x with 'mysqli pdo' but no 'mysql' support then you won't notice the mysql/mariadb in setup.
#11
This works for me now with latest snapshot, therefore closing bug.
#12
I got the same error today when I tried to install Drupal 7.0.
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1: SELECT * FROM {menu_router} WHERE path IN () ORDER BY fit DESC LIMIT 0, 1; Array ( ) in menu_get_item() (line 443 of /home/content/39/5986639/html/includes/menu.inc).LAMP server, shared hosting (GoDaddy).
#13
1V then something must to changed because and i will try to reproduce again. Are you sure you are using 7.x-dev?
#14
Yes. I dropped my database and reset settings.php, and the install went fine the second time. I noticed I was not allowing cookies the first time, so maybe that had something to do with the error.
This issue is still valid though. I am planning on setting up another web site in the coming days on the same shared host. I will see if I can reproduce the bug then.
#15
Great. Please post explicit steps used to reproduce the bug and we'll try to get to the bottom of it.
#16
Is there another possibility because I use the database for another site to so I can't drop it. Is it posible to export it, drop it then import it again or do I have to delete it?
#17
I just downloaded the official D7. Got the same error. Did all the above. Reseting the settings.php and recreating DB with utf8. but got the same error again. Fedora 12, mysql - 5.1.46,, PHP 5.3.2. My php is from Send Engine v2.3.0.. Would that be any reason? Error below:
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1: SELECT * FROM {menu_router} WHERE path IN () ORDER BY fit DESC LIMIT 0, 1; Array ( ) in menu_get_item() (line 443 of /XXXXXX/drupal-7.0/includes/menu.inc).
#18
Does this happen for all pages on your site? Or only when you view the main page? For example, can you go to http://yourdrupalsite/admin ? What does the menu_masks entry in {variables} (in your SQL database) look like? Does the {semaphore} table have any entries? Are there any entries at the bottom of {watchdog} about the menu rebuilding process?
Do page loads take forever? (like 30+ seconds)?
Edit:
What I'm thinking is going on here is that the menu_masks variable isn't getting created correctly, so menu_get_ancestors is returning an empty array which kills the MySQL query.
#19
Get the same error when trying to visit mydomain.com/admin. And in the {watchdog} this message is listed:
%type: !message in %function (line %line of %file).The type is "php" and the location is "http://mydomain.com/" and also "http://mydomain.com/admin".
There are no menu_masks in the {variables} entry. The attachment is a picture of {semaphore}.
#20
I get the following error message on Configure site and Finished when I install Drupal:
Notice: Undefined index: name in block_menu() (line 147 of /home/*/sub_html/update/modules/block/block.module).Notice: Undefined index: name in block_menu() (line 166 of /home/*/sub_html/update/modules/block/block.module).
Notice: Undefined index: name in system_menu() (line 641 of /home/*/sub_html/update/modules/system/system.module).
Notice: Undefined index: name in block_menu() (line 147 of /home/*/sub_html/update/modules/block/block.module).
Notice: Undefined index: name in block_menu() (line 166 of /home/*/sub_html/update/modules/block/block.module).
Notice: Undefined index: name in system_menu() (line 641 of /home/*/sub_html/update/modules/system/system.module).
#21
olamaekle: For the entry of {watchdog} you reference above (
%type: !message in %function (line %line of %file).) can you send along the contents of thevariablesfield? That will have the information about where the exception was thrown.#22
bfroehle: Is it this you want (the attachment)?
This is how I tried to install Drupal:
First attempt (failed, got the error)
Number of contrib modules: 47
Number of contrib themes: 15
Second attempt (no error messages at all)
Number of contrib modules: 19
Number of contrib themes: 4
Everything else is the same
Maybe that has something to do with the error?
#23
No, he means the variables field that is in the watchdog table. Also, try to get the binary data to show the contents instead of just BLOB (there should be an option for that under 'Innstillinger').
#24
olamaekle: Sorry, no I was referring to the
variablescolumn of the{watchdog}table. In phpMyAdmin this always shows as[blob]for me, except that if you open the frame in a new tab and append&display_blob=trueat the end of the URL, it'll display their contents. (See the attached image).What'd be most helpful is probably a straight dump of the
{watchdog}table. Select the watchdog table, choose export, un-select the "Use hexadecimal for BLOB" option, and click go. Save the results in a txt file and upload them here.#25
bfroehle: Now I think I got it:
a:6:{s:5:"%type";s:12:"PDOException";s:8:"!message";s:329:"SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1: SELECT * FROM {menu_router} WHERE path IN () ORDER BY fit DESC LIMIT 0, 1; Array\n(\n)\n";s:9:"%function";s:15:"menu_get_item()";s:5:"%file";s:46:"/home/olamaeir/sub_html/test/includes/menu.inc";s:5:"%line";i:443;s:14:"severity_level";i:3;}Like this?
#26
Yes! Except we need the watchdog entries which appear before this one, as that's where the real error is occurring. Can you provide a dump (i.e., export) of the watchdog table as described in comment #24?
Thanks, I appreciate your helpfulness in working through this bug!
#27
Sorry I'm kinda new to this but lets try again.
#28
This is wonderful, the problem behind the visible error message you are seeing is this one (which is watchdog id = 8 in the txt file you posted in #27)
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'title' cannot be null: INSERT INTO {menu_router} ... in _menu_router_save() (line 3674 of /home/olamaeir/sub_html/test/includes/menu.inc).I'm retitling to give a better description of the error, and am investigating further. Was this on a fresh install of D7 or an upgrade? Did you have any contributed modules or themes present?
#29
Both in #22 was exactly the same except fewer contrib modules and themes. Both where fresh install with a minor modification in .htaccess (line added: suPHP_ConfigPath /home/username/).
#30
Well, your problem is the Sky theme, version 7.x-1.0, and issue #1016854: The info file (temporary://update-extraction/sky/sky.info) does not define a 'name' attribute.. Upgrade to Sky theme version 7.x-1.1 and verify that your problem goes away.
#31
WOW! Great work bfroehle, it worked. Thank you.
#32
Issue Summary:
Theme .info files which do not properly define the 'name' attribute break menu_router generation. When we rebuild the menu_router system, we generate a list of paths with menu_router_build(). This, of course, calls hook_menu(). system_menu() provides the menu entries corresponding to themes -- the relevant code is:
<?phpforeach (list_themes() as $theme) {
$items['admin/appearance/settings/' . $theme->name] = array(
'title' => $theme->info['name'],
'page arguments' => array('system_theme_settings', $theme->name),
'type' => MENU_LOCAL_TASK,
'access callback' => '_system_themes_access',
'access arguments' => array($theme),
'file' => 'system.admin.inc',
);
}
?>
In the case of a malformed theme .info file, $theme->info['name'] can be NULL.
Note, in no place that I am aware of do we verify the required attributes of the .info file are even set. This could be done in _system_rebuild_theme_data(), for example. Or perhaps wrapping
$theme->info['name']in a check_plain() call would be sufficient (as is done inblock.module).Steps to reproduce issue:
Download the sky 7.x-1.0 theme. Clear all caches, and the menu_mask variable. Try to load any page... boom!
#33
The attached patch, which adds
check_plain()around$theme->info['name']fixes this issue for me (except that it takes both applying the patch and clearing the caches and some menu variables to take affect).This is probably the most minimally intrusive way to solve the problem. This patch works because
check_plain(NULL)returns an empty string (''), which can then be inserted into the NOT NULL database field.#34
Just marked #1022558: An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows... as a duplicate.
#35
Why would it need to be escaped? All you (IMO) do is abuse check_plain so it returns an empty string. A ternary check would be better. Alternatively, validate the entire .info before.
#36
Heine: That's true, but it's no different that how things are dealt with in block_menu() of
block.module, for example. If we go with a ternary check here, I suggest we should do something similar there.I'm done working on this issue, so hopefully somebody else can jump in here.
#37
I have done the patch, but I still got problems same olamaekle. I got the message below:
"Notice: Undefined index: name in block_menu() (line 147 of /home/signwo/tester/d7/modules/block/block.module).
Notice: Undefined index: name in block_menu() (line 166 of /home/signwo/tester/d7/modules/block/block.module).
Notice: Undefined index: name in system_menu() (line 641 of /home/signwo/tester/d7/modules/system/system.module)."
I am wondering about I need to download the Sky-theme to get it to work, or there is another solution?
#38
I know I said I was done working on this issue, but I wrote up this patch earlier (and discarded it in favor of the shorter patch in #33).
This implements .info file validation for the 'name' (must be non-empty) and 'description' (must be set) fields. Did not validate for 'core', as 6.x modules didn't set this and we want to show admin page messages about upgrading out-of-date modules.
#39
[Ignore, double post]
#40
So, following up on my post in #14. I have tried to install a new installation of Drupal 7.0 on the same shared host as in #14 (but on different accounts). The bug was reproducible.
Server information:
Steps used to reproduce bug:
The installation went fine up until this error appeared when the installer was creating tables:
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1: SELECT * FROM {menu_router} WHERE path IN () ORDER BY fit DESC LIMIT 0, 1; Array ( ) in menu_get_item() (line 443 of /home/content/32/5671032/html/includes/menu.inc).32 tables have been created. See MySQLTablesAfterError.png. There is no watchdog table.
#41
1V: Was that a fresh copy of drupal-7.0 without any other themes or modules present?
#42
Yes, fresh copy. Straight from drupal.org.
#43
1V: Try applying the patch attached to this issue and starting over -- it should help give a clearer picture of where the menu building process is dying.
#44
It seems like a major WTF that you need to specify "description =" , but can leave the description empty after that. I would suggest either make it required, or completely optional, but not something in between.
#45
Stevel: The reality is the earlier
'description' => ''that gets added what is pulled from the info file will make the check for 'description' be pointless anyway.#46
Thanks, bfroehle. I dropped the database, deleted the files and started over, using the same steps as in #40, but also patched includes/menu.inc with your patch. I was able to reproduce the bug successfully.
#47
So, the problem for me was that I didn't have cookies enabled. Or rather, more specific, that my proxy server was crunching all the incoming cookies. I was not able to reproduce this bug with this proxy feature disabled.
See #791004: Installer does not warn the user that cookies must be enabled with the correct cookie domain (and fails when they aren't).
#48
I found another cause of this issue in #1026474: Menu system does not always get rebuilt when needed.
#49
Hi, i am absolutly new to drupal and i am not well-experienced programmator, i know some basics of PHP, MySQL,CSS and complete HTML.. i have same problem as 1V does. I tried to download GIT and to apply patch but it is just too much for me... can you give me some advice how can i do that ? or can you just upload already patched files here pls ?
#50
Try http://drupal.org/patch for instructions.
#51
Ok so i downloaded UnxUtils and opened file called PATCH in UnxUtils\usr\local\wbin directory. The problem is that i write cd something or patch something and it does not work at all O_o i hit enter and it just skipped one line... Anyway, i am installing completly fresh copy from drupal.org and in step 5 [Profile installation] i get this error while it is creating tables or whatever >
* Notice: Undefined variable: site_name in include() (line 33 of /home/free/tym.sk/h/horskevydry/root/www/themes/bartik/templates/maintenance-page.tpl.php).
* Notice: Trying to get property of non-object in drupal_get_user_timezone() (line 2069 of /home/free/tym.sk/h/horskevydry/root/www/includes/bootstrap.inc).
* Notice: Trying to get property of non-object in drupal_get_user_timezone() (line 2069 of /home/free/tym.sk/h/horskevydry/root/www/includes/bootstrap.inc).
And it stopes around number of 12 and another error apear
An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: http://horskevydry.tym.sk/install.php?profile=standard&locale=sk&id=1&op=do StatusText: Service unavailable (with message) ResponseText: PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1: SELECT * FROM {menu_router} WHERE path IN () ORDER BY fit DESC LIMIT 0, 1; Array ( ) in menu_get_item() (line 443 of /home/free/tym.sk/h/horskevydry/root/www/includes/menu.inc).I am posting this "second part" just to make sure, if that patch helps me... and i already switched proxy server off. So the first question is : Will this patch help me ? or is my problem elsewhere ? and the second is : What do i have to do with that UnxUtils to make that patch running ?
i am really a newbie to this things so dont blame me pls ^^
------------------ EDIT: Ok, i read through the very first posts and i solved the problem, i apologize for taking your time .] Anyway I will work on my patching skills so i can help out a bit :D Thanks
#52
Hi,
I'm facing the same issue.
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1: SELECT * FROM {menu_router} WHERE path IN () ORDER BY fit DESC LIMIT 0, 1; Array ( ) in menu_get_item() (line 443 of /home/xxxx/www/prototype/includes/menu.inc).I tried applying the patch that bfroehle suggested but i don't seem to get any error there. Also I don't see the watchdog table in the database. It might have failed before that.
My Installation is on a virtual host using Webmin. I'm using the latest drupal 7 download and the standard install procedure. I use CentOS 5.3, PHP 5.3.
I have cookies enabled on my web browser
I see the following errors in the logs although i'm not sure how significant this information is
PHP Notice: Undefined offset: 0 in /home/xxxx/www/prototype/includes/errors.inc on line 279, referer: http://prototype.xxxx.org/install.php?profile=standard&locale=enPHP Notice: Undefined index: file in /home/xxxx/www/prototype/includes/errors.inc on line 84, referer: http://prototype.xxxx.org/install.php?profile=standard&locale=en
PHP Notice: Undefined index: line in /home/xxxx/www/prototype/includes/errors.inc on line 85, referer: http://prototype.xxxx.org/install.php?profile=standard&locale=en
The variable table shows the following entries
cron_key s:43:"YQPv0j2au7hUNMgS-i-ekv3fHXfslTV011rh_lG8l7E";drupal_private_key s:43:"Y5rSqanB6PYWGiVWK7F7d35VJ9cKa_b5RHd9vN6-Nu4";
install_current_batch s:23:"install_profile_modules";
install_task s:21:"install_system_module";
path_alias_whitelist a:0:{}
theme_default s:6:"bartik";
Webmin shows me that the database has "32 tables containing 376 rows of data"
Another warning i keep getting throughout the installation process is this but i don't know if it is related in any way.
Warning: ini_set() [function.ini-set]: A session is active. You cannot change the session module's ini settings at this time in drupal_environment_initialize() (line 521 of /home/xxxx/www/prototype/includes/bootstrap.inc).Any suggestions?
Thanks
#53
lionic: Try removing any contributed modules and themes you have installed. If that doesn't work, the root cause of your problem is likely #1026474: Menu system does not always get rebuilt when needed or similar.
#54
Hi,
I tried putting in the menu_rebuild code right before the menu_masks variable was used in
menu_get_ancestors. The above error did not come, but I got a page not found error instead when I access the website.Is there any way I can figure out where the code might be failing silently that might be causing the {menu_router} error?
Thanks.
#55
Hi,
It turned out that there was some permissions issue for the user on the database server because of which something was failing silently.
Once the permissions issue was resolved, i could install successfully.
Thanks bfroehle for helping out.
Regds
#56
Ok... I installed 6.20 and 7.0
I had to do the following:
add this in the httpd.conf
<Directory "path">AllowOverride All
</Directory>
And DO NOT change anything in other folders then /sites
( I commented line 521 in include/bootstrap.inc - as was sugested on another forum thread)
#57
Subscribing
#58
I'm attempting to reset this issue so we can work on finalizing a fix for it.
There is an issue summary writeup in #32. Two different patches were proposed in #33 and #38, although both received some criticism.
Very briefly, the issue is that if a THEME.info file does not provide a 'name' attribute, the menu router generation SQL breaks by attempting to insert a NULL value into a NOT NULL column.
WD menu: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column [error]'title' cannot be null: INSERT INTO {menu_router} (path, load_functions,
to_arg_functions, access_callback, access_arguments, page_callback, page_arguments,
...
This can also occur if the theme provides a corrupted .info file -- see Sky 7.x-1.0, for example.
I've attached the simplest patch for this bug, namely one that sets
$theme[$key]->info['name']to$keyif it is not already set. (In the cited example,$keyhere would be'sky').Steps to Reproduce:
drush dl sky-7.x-1.0drush -y vdel menu_masks
drush cc all
Now apply the attached patch, run
drush cc all#59
#60
#58: 619542-58-fix-malformed-theme-info.patch queued for re-testing.
#61
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1: SELECT * FROM {menu_router} WHERE path IN () ORDER BY fit DESC LIMIT 0, 1; Array ( ) in menu_get_item() (line 443 of /data/25/2/21/46/2510046/user/2749407/htdocs/includes/menu.inc).
I seem to have the same problem I believe. I have worked through and been able to use several other fixes to get to this stage.
I am using Drupal 7, Network Solutions shared server hosting, MySQL client version: 5.0.89, UTF-8 Unicode (utf8).
#62
Maybe this can help, copied and pasted the errors first and then the log file below.
This MySQL server has been running for 9 days, 9 hours, 47 minutes and 46 seconds. It started up on Apr 08, 2011 at 12:28 PM.
Errors shown in database log.
Slow_queries 2,870 The number of queries that have taken more than long_query_time seconds.
Handler_read_rnd 604 M The number of requests to read a row based on a fixed position. This is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of queries that require MySQL to scan whole tables or you have joins that don't use keys properly.
Handler_read_rnd_next 2,776.74 M The number of requests to read the next row in the data file. This is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.
Qcache_lowmem_prunes 39 M The number of queries that have been removed from the cache to free up memory for caching new queries. This information can help you tune the query cache size. The query cache uses a least recently used (LRU) strategy to decide which queries to remove from the cache.
Created_tmp_disk_tables 4,510 k The number of temporary tables on disk created automatically by the server while executing statements. If Created_tmp_disk_tables is big, you may want to increase the tmp_table_size value to cause temporary tables to be memory-based instead of disk-based.
Select_full_join 425 k The number of joins that do not use indexes. If this value is not 0, you should carefully check the indexes of your tables.
Select_range_check 36 k The number of joins without keys that check for key usage after each row. (If this is not 0, you should carefully check the indexes of your tables.)
Sort_merge_passes 32 k The number of merge passes the sort algorithm has had to do. If this value is large, you should consider increasing the value of the sort_buffer_size system variable
Opened_tables 12 M The number of tables that have been opened. If opened tables is big, your table cache value is probably too small.
Table_locks_waited 41 k The number of times that a table lock could not be acquired immediately and a wait was needed. If this is high, and you have performance problems, you should first optimize your queries, and then either split your table or tables or use replication
The Above is the errors, I am including the full log.
Server traffic: These tables show the network traffic statistics of this MySQL server since its startup.
Traffic ø per hour
Received 3,820 MiB 17 MiB
Sent 3,288 MiB 15 MiB
Total 7,108 MiB 31 MiB
Connections ø per hour %
max. concurrent connections 297 --- ---
Failed attempts 380 k 1,681.48 3.00%
Aborted 13 k 59.73 0.11%
Total 13 M 56.03 k 100.00%
Query statistics: Since its startup, 212,426,180 queries have been sent to the server.
Total ø per hour ø per minute ø per second
212 M 940.79 k 15.68 k 261.33
Query type ø per hour %
admin commands 1,375 k 6,090.89 0.69%
alter db 13 0.00 k 0.00%
alter table 9,798 43.39 0.00%
analyze 833 k 3,689.65 0.42%
backup table 0 0.00 0.00%
begin 2,325 k 10.30 k 1.16%
call procedure 954 4.23 0.00%
change db 13 M 57.76 k 6.53%
change master 0 0.00 0.00%
check 0 0.00 0.00%
checksum 0 0.00 0.00%
commit 1,516 k 6,712.46 0.76%
create db 319 1.41 0.00%
create function 0 0.00 0.00%
create index 19 0.00 k 0.00%
create table 70 k 308.89 0.03%
create user 0 0.00 0.00%
delete 3,367 k 14.91 k 1.69%
delete multi 273 1.21 0.00%
do 0 0.00 0.00%
drop db 100 0.00 k 0.00%
drop function 0 0.00 0.00%
drop index 0 0.00 0.00%
drop table 4,705 20.84 0.00%
drop user 0 0.00 0.00%
flush 403 1.78 0.00%
grant 2 0.00 k 0.00%
ha close 0 0.00 0.00%
ha open 0 0.00 0.00%
ha read 0 0.00 0.00%
help 0 0.00 0.00%
insert 3,867 k 17.13 k 1.94%
insert select 6,406 28.37 0.00%
kill 5 0.00 k 0.00%
load 3 0.00 k 0.00%
load master data 0 0.00 0.00%
load master table 0 0.00 0.00%
lock tables 15 k 64.56 0.01%
optimize 1,251 5.54 0.00%
preload keys 0 0.00 0.00%
purge 0 0.00 0.00%
purge before date 0 0.00 0.00%
rename table 182 0.00 k 0.00%
repair 42 0.00 k 0.00%
replace 344 k 1,524.24 0.17%
replace select 41 0.00 k 0.00%
reset 0 0.00 0.00%
restore table 0 0.00 0.00%
revoke 0 0.00 0.00%
revoke all 0 0.00 0.00%
Query type ø per hour %
rollback 194 0.00 k 0.00%
savepoint 0 0.00 0.00%
select 59 M 261.17 k 29.52%
set option 8,013 k 35.49 k 4.01%
show binlog events 0 0.00 0.00%
show binlogs 1,251 5.54 0.00%
show charsets 14 k 60.78 0.01%
show collations 19 k 81.94 0.01%
show column types 0 0.00 0.00%
show create db 4 0.00 k 0.00%
show create table 224 k 993.24 0.11%
show databases 134 0.00 k 0.00%
show errors 0 0.00 0.00%
show fields 381 k 1,687.11 0.19%
show grants 4,170 18.47 0.00%
show innodb status 0 0.00 0.00%
show keys 7,886 34.93 0.00%
show logs 0 0.00 0.00%
show master status 10 0.00 k 0.00%
show ndb status 0 0.00 0.00%
show new master 0 0.00 0.00%
show open tables 0 0.00 0.00%
show privileges 0 0.00 0.00%
show processlist 3,280 14.53 0.00%
show slave hosts 0 0.00 0.00%
show slave status 10 0.00 k 0.00%
show status 3,855 17.07 0.00%
show storage engines 118 0.00 k 0.00%
show tables 449 k 1,988.47 0.22%
show triggers 213 k 945.01 0.11%
show variables 68 k 302.27 0.03%
show warnings 1,306 5.78 0.00%
slave start 0 0.00 0.00%
slave stop 0 0.00 0.00%
stmt close 20 0.00 k 0.00%
stmt execute 35 0.00 k 0.00%
stmt fetch 0 0.00 0.00%
stmt prepare 39 0.00 k 0.00%
stmt reset 20 0.00 k 0.00%
stmt send long data 0 0.00 0.00%
truncate 1,280 5.67 0.00%
unlock tables 15 k 66.76 0.01%
update 4,553 k 20.16 k 2.28%
update multi 57 k 251.71 0.03%
xa commit 0 0.00 0.00%
xa end 0 0.00 0.00%
xa prepare 0 0.00 0.00%
xa recover 0 0.00 0.00%
xa rollback 0 0.00 0.00%
xa start 0 0.00 0.00%
Begin SQL query
Variable Value Description
Flush_commands 1 The number of executed FLUSH statements.
Last_query_cost 0 The total cost of the last compiled query as computed by the query optimizer. Useful for comparing the cost of different query plans for the same query. The default value of 0 means that no query has been compiled yet.
Slow_queries 2,870 The number of queries that have taken more than long_query_time seconds.
Begin SSL
Variable Value Description
Ssl_accept_renegotiates 0
Ssl_accepts 0
Ssl_callback_cache_hits 0
Ssl_cipher
Ssl_cipher_list
Ssl_client_connects 0
Ssl_connect_renegotiates 0
Ssl_ctx_verify_depth 0
Ssl_ctx_verify_mode 0
Ssl_default_timeout 0
Ssl_finished_accepts 0
Ssl_finished_connects 0
Ssl_session_cache_hits 0
Ssl_session_cache_misses 0
Ssl_session_cache_mode NONE
Ssl_session_cache_overflows 0
Ssl_session_cache_size 0
Ssl_session_cache_timeouts 0
Ssl_sessions_reused 0
Ssl_used_session_cache_entries 0
Ssl_verify_depth 0
Ssl_verify_mode 0
Ssl_version
Begin Handler
Variable Value Description
Handler_commit 0 The number of internal COMMIT statements.
Handler_delete 1,563 k The number of times a row was deleted from a table.
Handler_discover 0 The MySQL server can ask the NDB Cluster storage engine if it knows about a table with a given name. This is called discovery. Handler_discover indicates the number of time tables have been discovered.
Handler_prepare 0
Handler_read_first 6,458 k The number of times the first entry was read from an index. If this is high, it suggests that the server is doing a lot of full index scans; for example, SELECT col1 FROM foo, assuming that col1 is indexed.
Handler_read_key 2,530.10 M The number of requests to read a row based on a key. If this is high, it is a good indication that your queries and tables are properly indexed.
Handler_read_next 1,289 M The number of requests to read the next row in key order. This is incremented if you are querying an index column with a range constraint or if you are doing an index scan.
Handler_read_prev 234 M The number of requests to read the previous row in key order. This read method is mainly used to optimize ORDER BY ... DESC.
Handler_read_rnd 604 M The number of requests to read a row based on a fixed position. This is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of queries that require MySQL to scan whole tables or you have joins that don't use keys properly.
Handler_read_rnd_next 2,776.74 M The number of requests to read the next row in the data file. This is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.
Handler_rollback 0 The number of internal ROLLBACK statements.
Handler_savepoint 0
Handler_savepoint_rollback 0
Handler_update 392 M The number of requests to update a row in a table.
Handler_write 595 M The number of requests to insert a row in a table.
Begin Query cache
Variable Value Description
Flush query cache
Qcache_free_blocks 1,416 The number of free memory blocks in query cache.
Qcache_free_memory 4,566 k The amount of free memory for query cache.
Qcache_hits 101 M The number of cache hits.
Qcache_inserts 52 M The number of queries added to the cache.
Qcache_lowmem_prunes 39 M The number of queries that have been removed from the cache to free up memory for caching new queries. This information can help you tune the query cache size. The query cache uses a least recently used (LRU) strategy to decide which queries to remove from the cache.
Qcache_not_cached 7,602 k The number of non-cached queries (not cachable, or not cached due to the query_cache_type setting).
Qcache_queries_in_cache 6,471 The number of queries registered in the cache.
Qcache_total_blocks 18 k The total number of blocks in the query cache.
Begin Threads
Variable Value Description
Show processes
Slow_launch_threads 0 The number of threads that have taken more than slow_launch_time seconds to create.
Threads_cached 1 The number of threads in the thread cache. The cache hit rate can be calculated as Threads_created/Connections. If this value is red you should raise your thread_cache_size.
Threads_connected 17 The number of currently open connections.
Threads_created 525 k The number of threads created to handle connections. If Threads_created is big, you may want to increase the thread_cache_size value. (Normally this doesn't give a notable performance improvement if you have a good thread implementation.)
Threads_running 5 The number of threads that are not sleeping.
Threads_cache_hitrate_% 95.85 %
Begin Binary log
Variable Value Description
Binlog_cache_disk_use 0 The number of transactions that used the temporary binary log cache but that exceeded the value of binlog_cache_size and used a temporary file to store statements from the transaction.
Binlog_cache_use 0 The number of transactions that used the temporary binary log cache.
Begin Temporary data
Variable Value Description
Created_tmp_disk_tables 4,510 k The number of temporary tables on disk created automatically by the server while executing statements. If Created_tmp_disk_tables is big, you may want to increase the tmp_table_size value to cause temporary tables to be memory-based instead of disk-based.
Created_tmp_files 63 k How many temporary files mysqld has created.
Created_tmp_tables 7,941 k The number of in-memory temporary tables created automatically by the server while executing statements.
Begin Delayed inserts
Variable Value Description
Delayed_errors 0 The number of rows written with INSERT DELAYED for which some error occurred (probably duplicate key).
Delayed_insert_threads 0 The number of INSERT DELAYED handler threads in use. Every different table on which one uses INSERT DELAYED gets its own thread.
Delayed_writes 470 The number of INSERT DELAYED rows written.
Not_flushed_delayed_rows 0 The number of rows waiting to be written in INSERT DELAYED queues.
Begin Key cache
Variable Value Description
Key_blocks_not_flushed 0 The number of key blocks in the key cache that have changed but haven't yet been flushed to disk. It used to be known as Not_flushed_key_blocks.
Key_blocks_unused 329 k The number of unused blocks in the key cache. You can use this value to determine how much of the key cache is in use.
Key_blocks_used 65 k The number of used blocks in the key cache. This value is a high-water mark that indicates the maximum number of blocks that have ever been in use at one time.
Key_read_requests 12.44 G The number of requests to read a key block from the cache.
Key_reads 75 M The number of physical reads of a key block from disk. If Key_reads is big, then your key_buffer_size value is probably too small. The cache miss rate can be calculated as Key_reads/Key_read_requests.
Key_write_requests 56 M The number of requests to write a key block to the cache.
Key_writes 17 M The number of physical writes of a key block to disk.
Key_buffer_fraction_% 16.25 %
Key_write_ratio_% 31.12 %
Key_read_ratio_% 0.60 %
Begin Joins
Variable Value Description
Select_full_join 425 k The number of joins that do not use indexes. If this value is not 0, you should carefully check the indexes of your tables.
Select_full_range_join 17 k The number of joins that used a range search on a reference table.
Select_range 5,919 k The number of joins that used ranges on the first table. (It's normally not critical even if this is big.)
Select_range_check 36 k The number of joins without keys that check for key usage after each row. (If this is not 0, you should carefully check the indexes of your tables.)
Select_scan 14 M The number of joins that did a full scan of the first table.
Begin Replication
Variable Value Description
Show slave hosts Show slave status
Rpl_status NULL The status of failsafe replication (not yet implemented).
Slave_open_temp_tables 0 The number of temporary tables currently open by the slave SQL thread.
Slave_retried_transactions 0 Total (since startup) number of times the replication slave SQL thread has retried transactions.
Slave_running OFF This is ON if this server is a slave that is connected to a master.
Begin Sorting
Variable Value Description
Sort_merge_passes 32 k The number of merge passes the sort algorithm has had to do. If this value is large, you should consider increasing the value of the sort_buffer_size system variable.
Sort_range 2,775 k The number of sorts that were done with ranges.
Sort_rows 1,896 M The number of sorted rows.
Sort_scan 8,806 k The number of sorts that were done by scanning the table.
Begin Tables
Variable Value Description
Flush (close) all tables Show open tables
Open_tables 512 The number of tables that are open.
Opened_tables 12 M The number of tables that have been opened. If opened tables is big, your table cache value is probably too small.
Table_locks_immediate 89 M The number of times that a table lock was acquired immediately.
Table_locks_waited 41 k The number of times that a table lock could not be acquired immediately and a wait was needed. If this is high, and you have performance problems, you should first optimize your queries, and then either split your table or tables or use replication.
Begin Transaction coordinator
Variable Value Description
Tc_log_max_pages_used 0
Tc_log_page_size 0
Tc_log_page_waits 0
Begin
Variable Value Description
Compression OFF
Open_files 1,010 The number of files that are open.
Open_streams 0 The number of streams that are open (used mainly for logging).
Prepared_stmt_count 0
Queries 212 M
#63
@Ray8abit: Sorry to hear you are having issues. For such long posts of information, it is generally courteous to attach that information in a text file rather than just paste it in the editor window. Unfortunately, the information provided is not sufficient to diagnose your problem. Have you tried applying the patch in #58? If that doesn't address your problem, please open a new issue as this issue is for one specific cause of the symptom you describe.
For an issue summary and the latest patch, see #619542-58: Malformed theme .info files break menu_router generation.
#64
My apologies
#65
not sure if this was the cause, but i got the same error on an install of 7.0 so i restored the install folder to the exact same environment (i have a custom restore script), and i _enabled javascript and cookies_ for the site i was installing and it worked this time without any error. Im using some addons to disable js/cookies selectively and i forgot to allow the d7 site. I know d6 had some similar problems on the install if js or cookies are disabled
#66
Typo in the patch "resonable".
Is this worth writing a test for?
#898634: install_drupal(): call to install_display_output() results in SQL syntax error contains a change to menu_get_item() that may allow the menu system to recover from this state but I've not tested that with this - if that's sufficient, I'd be fine with having the exception thrown (or making that .info key not required in D8).
#67
I'm just confirming the note in #51 of an notice error on line 33 of /themes/bartik/templates/maintenance-page.tpl.php
Notice errors should be squished as they are annoying.
#68
I posted an issue summary and have revised the comments in the patch as directed by catch in #66.
The change in #898634: install_drupal(): call to install_display_output() results in SQL syntax error won't help this issue, as the PDO Exception is thrown when we are populating the {menu_router} table.
Does this need a test? Ehh, I don't know.
#69
The explicit reference to this issue can be removed from the comment, git blame covers that. Sorry I missed that first pass.
I don't think this is worth testing so RTBC apart from removing the link.
#70
catch: I added the link in the last iteration of this. The link points to Writing .info files, which seems appropriate.
#71
In that case it should at least be an @see then.
If we can't make this optional for 7.x, then we should log to watchdog when this has to be corrected, I don't like the idea of silently passing here if the bug is in contrib themes.
#72
It seems strange to me that Drupal would not enforce required fields. This patch prevents an error msg but what other unexpected problems might arise? Why not treat these the same way as themes that do not have a 'content' region and don't let them get enabled?
#73
@drocks that sounds like a good plan to me.
#74
This plan of enforcing the required fields isn't really possible without #1067408: Themes need an installation status. It's not enough to prevent the theme from being enabled --- the issue is that the mere presence of the malformed .info file in a theme directory breaks Drupal.
What's the current policy regarding these types of changes? Can we agree on a small, commented hack (like #68 or a different solution) for inclusion now (and backport to D7) before blocking the issue on a major theme status change (with no possibility of backport to D7)?
#75
@bfoehle the closest to a policy is http://drupal.org/node/767608
I am personally very much in favour of committing commented hacks if it's a serious issue with no clear fix - even if we open another major bug report (or keep this issue open) for a more comprehensive fix for D8. The current issue queue thresholds were put in place partly to allow that to happen (i.e. without adding hundreds of commented hacks to D8 that never get fixed properly).
Since a subtheme could do this, and subthemes don't need any kind of enabled status at all, preventing them being used doesn't look like an option indeed. We could really use a comment/@todo though so leaving at NW.
#76
For module.info files the documentation says that the 'name' variable is only used for display purposes. Bur the theme.info docs don't say anything about about the allowed values of 'name'. And that value is used in a number of places in drupal. For example, the values in .info are used to populate the values stored in the system table record for a subtheme. Since none of the data in .info is validated in any way doesn't that leave drupal open to all kinds of weirdness, as shown here. The patch here will help if the 'name' value is omitted from a .info file bur not if it gets some arbitrary or conflicting setting. I guess what I am asking is, why does drupal trust some arbitrary user input such as .info['name'] over the actual theme 'name' stored in the system table?
#77
A really simple hack would be to add a line like:
'name' => 'Name not provided in your .info file. Please correct'
to the theme info $defaults in system.module.
#78
I did an extensive(but not exhaustive) search of drupal code to find where theme info['name'] is used and found 4 in system module and 3 in block.module. All of the use in block module was for display purposes. 2 of the 4 in system.module were for display. The documentation for drupal_parse_info_file says that the 'name' attribute is for display purposes for both modules and themes. Perhaps the problem here is inappropriate use of the info['name'] attribute.
#79
While the 'title' of a menu router item is only supposed to be used for display, I think dcrocks is along the right lines here.
Here's a look at a different way to fix this. Instead of setting title directly to $theme->info['name'];, it uses a title callback, then gets the theme name in there.
I tested this manually by removing the name key for Seven, and it removed the fatal error during menu_rebuild(), while meaning there are various notices about the missing key still (which is fine since it's required).
Adding a test theme just for this bug seems like far too much overhead, however it's easy to reproduce with core patches + the test bot. So three patches:
One that removes the theme key for Seven, this should completely blow up.
One that includes the fix and the broken .info, this should have some exceptions but not fatal errors.
And one that only includes the changes to system_menu().
This is still a hacky workaround until we have #1067408: Themes need an installation status but it localises the hack a bit more maybe.
#80
The last submitted patch, theme_name_broken.patch, failed testing.
#81
I still have some angst as to the best way to fix this problem. The core problem is that there is no validation of .info problem contents, leading to issues like the one here with 'name'. I think there are more elsewhere in drupal. It seems like there are 2 approaches:
1) make sure these parameters always meet program expectations
2) make sure the program can handle any arbitrary value or non-value for these parameters
The 1st solution is more future proof. And it is not bad practice to assign defaults to required parameters. But it is bad practice to not inform the user that they have done something wrong. Setting a default for info['name'] such as 'Untitled', with documentation, would be an easy fix but by no means guarantee a problem free drupal installation. Nor does it address other possible values for info['name'], such as the name of an non-existent or already existent theme. The best fix, at least for the few required parameters in .info, would be to apply a reasonably thorough validation of those parameters. Otherwise the drupal community is going to solving these one malapropism at a time.
#82
Moving back to needs review, looks like the test bot doesn't like three patches at once.
#83
I'm ambivalent on the green patch in #79.
On the one hand it changes a PDOException into a regular PHP warning and keeps Drupal functional (but with warnings, as it should). Notice that it actually allows Drupal to be installed unlike the test-only patch which breaks the installation even.
On the other hand it adds extra complexity with a questionably needed callback function.
#84
Yeah I agree with #83, I'm not happy about that patch, I would like whatever we commit to throw noisy warnings though (although not quite as noisy as unrecoverable fatal errors).
#85
The included patch forces a default info['name'] value and marks the theme as incompatible so that it won't be enabled, plus provides a clue as to the actual error. This is not the best solution but could provide a model for other errors in the .info file. The patch is for drupal 8.x but can't be a straight backport to 7.x because of differences in the files. I only did simple testing and I hope someone else can see if the other errors in this issue still show up.
#86
Please ignore above patch, dropped a line. fixed here.
#87
The above patch might actually work for 7.x but I generated a separate one anyways.
#88
Assuming #86 is acceptable I'd like to add a couple more changes.
change the text color of the 'incompatible' div to red
change handling of 'no content region' error msg to something more applicable and make it an 'incompatible_info' error
change it so any of these 'incompatible' error themes have a name prefixed with ERROR, then the theme name
fins a better way to indicate the actual error
Handle more 'name' type errors, e.g., duplicate names
#89
I've spent some time looking at how errors in .info are(not) handled and I just realized I don't know how to handle 1 case in particular: the admin modifies the .info file of the current default theme and introduces errors. What happens if the name property is dropped from the file? Is there an existing policy for this?
#90
Not much discussion here. But after looking at what is needed to 'nicely' handle theme .info file errors and how drupal has treated similar errors in other places just maybe this should be closed as working as designed. Drupal seems to prefer some errors be allowed as long as their cause is fairly obvious and adding error management code might be burdensome. In this case the index errors are easily decoded and fixed. What does anyone think about this?
ps. The fixes I provided were certainly unpolished and I wouldn't want anyone to consider them. But the more I 'improved' them, the bigger they got.
#91
I'd be fine with #86/87 - either with the requirements hunk, or even just the default value. I don't think we need to deal with themes that have the key removed, that seems much more unikely.
We do in general like to allow errors to fall through, but ones that completely trash sites and are hard to recover from are a bit of a different category from just getting a notice or warning (or fatal errors that don't leave the db inconsistent). We generally have been careful to not allow things like enabling 6.x modules on 7.x sites, even if that shouldn't happen in normal usage, for the same reasons (although this is currently broken - but that's a critical bug).
#92
There seems to be no place yet where there is a test theme somewhere.
It would probably make sense to add a broken test theme to fix this behavior
#93
I think there's some in /themes, but
#953336: Contributed modules are not able to test theme-related functionality aims to allow them to be included with modules.
#94
I would like to do some additional changes to #86. For one, it doesn't handle multiple errors. It also doesn't look like a normal drupal error message(no box or background). And I think it would be more drupal like to have the error messages on top of the theme display than on the bottom. If people are willing, I can put more time into it.
Ps. I tried to experiment with other possible errors(eg. duplicate name) in the .info file and though strange things happened, there weren't any exception messages during simple testing. So I think they might be left for other issues.
PS there are theme test files under modules/simpletest/tests
#95
Got distracted but almost ready. Have a question. Current logic tests only disabled themes for .info error. But nothing prevents someone from modifying an enabled theme .info file, even the current default theme. Should tests be extended to all, or at least all but default, themes?
#96
Attached is a screenshot for comments. I'm concerned I'm using appropriate wording. I added a drupal message to the top of the appearance page because I think that is standard drupal practice. Please let me know what you think before I finalize the code.
#97
Changing status until further comment. Also, if I should test for more errors.
#98
If someone puts 'name =' followed by blanks in their .info file, the logic scans multiple lines until it reaches a non-blank character, and then scans to the end of that line to assign a value to the name key. A common result is the description key/value pair becoming the name of the theme. No way to test for this error, but it might be helpful if the default value for the description keyword be 'no description' rather than ''. Thoughts?
#99
Here is my latest attempt with a test added for missing base themes. Please provide input on my message text.
#100
No response, so maybe a patch would help. To summarize:
The policy on errors in a theme's .info file has mainly been to let any errors fall thru and what happens, happens. There are currently 2 exceptions to that, core and php compatibility. But several other .info file errors have shown to result in serious consequences and drupal failure. So I have built a patch that tests for these other errors, pushes a message, and prevents the theme from being enabled. The changes are:
0) The code allows for multiple errors on multiple themes.
1) Add a default value for the name keyword, '???????'. I think a string like this is more likely to catch the eye than a text string , e.g., 'no name'. Then stack an error message.
2) Changed the default value for description to 'No description' from ''. This is more informative and sometimes give a clue to the weird things that can happen when scanning a bad .info file. A user could still have an empty description be specifying description = ''
3) Gave 'no content region' error its own error message instead of 'incomaptible'.
4) Added a test where a subtheme specifies a base theme that doesn't exist. Stack an error message if so.
5) If any errors exist, do a drupal_set_message so that a message appears at the top of the appearance page, which I think is standard drupal practice.
6) Added an 'invisible' h2 element at the top of the error display div for accessibility purposes.
7) Changed theme info error div to a box with styling matching drupal error messages.
I've tested the patch on a current 8.x dev. A sample image is provided. It would be simple to backport to D7.
Please critique the code and message text
#101
Can anyone review? Changed the title to reflect the patch.
#102
Has a bug. Will try to fix soon.
#103
Have fix but was going to wait on #22336: Move all core Drupal files under a /core folder to improve usability and upgrades. Even though no one is paying much attention, is there support for adding tests for page_top and page_bottom regions?
This whole thing is about what have to be considered 'user' errors rather than 'drupal' errors. But they can lead to critical errors in a drupal implementation, or unexpected behaviors, whose cause might not be immediately obvious. If these things can be caught and flagged for the user it might make drupal a little friendlier.
#104
It would be easy to force the existence of regions content, page_top, page_bottom, and help in every theme by default. Is there any interest in doing this? Or is this a philosophical issue?
#105
Where do we draw the line at too much error checking?
The original issue was about one specific instance where Drupal itself throws a PDOException error just by having an invalid theme.info file sitting in the directory. This is a pretty major error since it'll cripple your Drupal site without much indication as to why.
Since then it has morphed into a lot more error checking -- but are these errors something core needs to check? Why not just toss them in the Theme Developer module?
Personally I'd just like to see the one-liner fix in #68 (which easily hides the error) or the 5 liner in #79 (which turns it into a PHP warning).
#106
Well, what is Drupal's philosophy here? These are 'user' errors, but does Drupal want to be user friendly, or should there just be a 'bath at your own risk' sign? If Drupal has requirements they should be enforced, and not be a learning challenge to users.
I've come across this attitude before to just let user errors fall through until they figure it out. Don't agree with it but won't fight the church. Someone else needs to put in a nickel on this.
#107
Nothing here for a while. I am re-rolling my patch against new drupal. I'd like to point out that I've only added 2 new error tests. But I have changed the way they are displayed. The .png in #100 does look busy, but only because I wanted people to actually look at the messages and their presentation, and the fact that the patch will display multiple errors against multiple themes.
Again, I disagree with the drupal fumble your way to success philosophy. A short informative message is more educational and less exasperating.
#108
I agree with bfroehle. If you want to do full validation of theme.info files then that could be tackled in a follow-up issue but it's not necessary to do that in order to fix the major bug here.
Also regardless of philosophy around error checking, for this to be backported to Drupal 7, it needs to be fixed in such a way that it doesn't add new strings (which in turn breaks translations).
#109
Ok, here is the one liner. Restores issue title as well.
#110
#109: Malformed_theme_info_files_break_menu_router_generation-619542-109.patch queued for re-testing.
#111
What's needed to move this forward?
oops, i see.. a review is needed :]