Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.This is in node.admin.inc: function node_admin_nodes()
// Enable language column if translation module is enabled
// or if we have any node with language.
$multilanguage = (module_exists('translation') || db_result(db_query("SELECT COUNT(*) FROM {node} WHERE language != ''")));
This query is a performance hit for sites with lots of nodes.
mysql> SELECT COUNT(*) FROM node WHERE language != ''; +----------+ | COUNT(*) | +----------+ | 3901948 | +----------+ 1 row in set (57.15 sec)
The number that is returned is unimportant; it will just evaluate to a boolean. So we could use other queries in its place, like this:
mysql> SELECT language FROM node WHERE language != '' LIMIT 1; +----------+ | language | +----------+ | en | +----------+ 1 row in set (0.00 sec)
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 375064-node-language-1.patch | 1.57 KB | catch |
| #3 | 375064-node-language-1.patch | 1.57 KB | c960657 |
| #3 | 375064-node-language-D6-1.patch | 1.48 KB | c960657 |
Comments
Comment #1
robertDouglass CreditAttribution: robertDouglass commentedActually, that query didn't make it much better, but an index does:
mysql> alter table node add index node_language (language);Comment #2
robertDouglass CreditAttribution: robertDouglass commentedOops, I'd already reported this: http://drupal.org/node/374035
Comment #3
c960657 CreditAttribution: c960657 commentedEven with the index added in #373897: admin/content still has sortable author column resulting in SQL errors, I still think we should optimize the query to use LIMIT 1 like we do elsewhere in core.
Comment #5
c960657 CreditAttribution: c960657 commentedTest bot failed to test the D6 patch.
Comment #6
catchLooks good, re-uploading D7 patch for the bot.
Comment #7
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Not marking this fixed yet because I do have a follow-up question:
Any reason we want a query? It seems like the module_exists() check might be sufficient? One might argue that that would be the proper behavior anyway.
Comment #8
catchIf you disabled translation module, you could still have multilingual nodes and want to filter on them, however I don't see a particular reason to provide a UI for that in core since it's something that can easily be done from contrib. Also this should really be something that's hooked in in Drupal 8, it's sad that we have node module doing a module_exists().
Comment #9
podaroksubscribe
Comment #10
Azol CreditAttribution: Azol commentedsubscribe
Comment #11
jnpwebdeveloper CreditAttribution: jnpwebdeveloper commentedThis is crazy! I am not a Drupal pro but this made a really noticeable difference in my test environment. I didn't even have any nodes in my installation and it was causing a bottle neck. I saw that this was a major hang up when checking my performance logs.
Why the heck is there a check for language support if the majority of sites don't even use this feature. This should only be done if the module is installed or variable is set.
Comment #12
montesq CreditAttribution: montesq commentedIMHO, if you disable translation, you should not expect to have any information about the node language anywhere in Drupal...
That is why I agree to say that checking module_exists('translation') must be sufficient.
Comment #13
c960657 CreditAttribution: c960657 commentedYou don't have to use the Translation module in order have nodes with different languages. The Locale module defines a multi-lingual setting per node type, locale_multilingual_node_type().
Perhaps a better check is to remove the current condition and replace with a check to see if any content type allows multi-lingual nodes, i.e. loop over all language_content_type_... variables.
Comment #18
joseph.olstadThis issue was fixed back in January 2011 by non-other than Dries and catch and c960657.
Dries committed this 2011-01-12
4bf9e43e (Dries Buytaert 2011-01-12 23:09:13