None of the paths include the i18n information so it's hard to know if the slow queries are coming from http://example.org/en/node/279785 or http://example.org/fr/node/279785 as the path is just listed as node/279785

Furthermore, it would be good if the path allowed you to link & see it (possibly even with the slow queries output if devel is enabled).

Comments

malc0mn’s picture

2 good ones. Best IMHO would be to add a language column and make path & language primary key for the summary table...

mgifford’s picture

Sounds like that approach would work well. In most cases it would be the same, but not all.

mgifford’s picture

Wanted to also say that this might be something that could easily wait till D8. At the moment there's no support for this with similar core code like:

/en/admin/reports/page-not-found

Although I encourage modules to be better from core... I'm also totally fine to postpone this.

malc0mn’s picture

Added the clickable paths suggestion to both D6&7.

@#2: In what cases would adding a language column not be enough? Can't think of any... I'll just write

  global $language;
  $data['language'] = $language->language;

to the DB in a separate column? That way you know in what language the URL was called. I pass it on to the l() function and the path will be generated alias and all so you can click it in the overviews.

When using entity translations the node id will stay the same, but the language differs, so making path + language primary key solves that problem as well...?

malc0mn’s picture

Assigned: Unassigned » malc0mn
Status: Active » Fixed

Added language DB column and logging to 2.x branch (summary & detail), probably won't be backporting this to 1.x version as the 2.x should really replace that with the new #1848850: We don't need different data stores - let Drupal's cache backend decide approach.

Automatically closed -- issue fixed for 2 weeks with no activity.