url() does not recognize if $path == frontpage

the bug is not fixed with the issue mentioned.

this time I fixed the root of the evil.

it is drupal_lookup_path().
* first of all I commented every step which is important.
* it returns '' as the alias of the frontpage path
* fixed small bug which was a result of $map[$path] = FALSE;.

the patch applies to drupal 4.7 and 5

tested it at drupal 5
works great!

i had an idea

have no time, yet --> untested!!!

here is a new version of the patch

I removed some new dead code and fixed an error of the last patch

I benchmarked the code per http://drupal.org/node/79237
but i was not able to "disable mysql query cache"

it seems that there is a performance loss of 3 percent
i compared "Time per request" in the output of the benchmark - i hope this was the right one

here comes a new patch with artos suggestion of using static.

i benchmarked this 10 times and I got every time the same result:
the new patch seems to be 6% faster then the current version of this function in head.

I did not change anything on the test system.
It would be nice if someone else coud benchmark this again
Because it might be a wonder if this would be so much faster...

the error only occours if the frontpage variable is set to any url alias (not to the real src).

I dont understand any word about regexp... so i fixed it by pressing del on my keyboard ;)

btw. I dont think that
variable_get('site_frontpage', 'node')
was used properly in block_list() (block.module)

think about this use case:
your url_alias looks like this:

###############################
#   src  #          dst       #
###############################
# node/5 # my-first-frontpage #
# node/5 # my-great-frontpage #
###############################

* site_frontpage variable has the value my-great-frontpage
* some block gets only shown on the <front>-page

what is block_list() doing if you are on the frontpage?

the snippet of interest:

          $path = drupal_get_path_alias($_GET['q']);
          $regexp = '/^('. preg_replace(array('/(\r\n?|\n)/', '/\\\\\*/', '/(^|\|)\\\\<front\\\\>($|\|)/'), array('|', '.*', '\1'. preg_quote(variable_get('site_frontpage', 'node'), '/') .'\2'), preg_quote($block->pages, '/')) .')$/';
          // Compare with the internal and path alias (if any).
          $page_match = preg_match($regexp, $path);
          if ($path != $_GET['q']) {
            $page_match = $page_match || preg_match($regexp, $_GET['q']);
          }
          // When $block->visibility has a value of 0, the block is displayed on
          // all pages except those listed in $block->pages. When set to 1, it
          // is displayed only on those pages listed in $block->pages.
          $page_match = !($block->visibility xor $page_match); 

$_GET['q'] is node/5
first of all it looks for the alias of "q" with drupal_get_path_alias() the alias is my-first-frontpage (first matching row in table)
now it replaces <front> in the allowed paths with variable_get('site_frontpage', 'node') this means with my-great-frontpage
it looks if my-first-frontpage is in the list. but it will never find this path. Now it searches again for node/5... with no result.

this means a solution for this problem without the patch above is to replace variable_get('site_frontpage', 'node') with drupal_get_path_alias(variable_get('site_frontpage', 'node'))

another issue which will be fixed by this: drupal_lookup_path does not cache negative results

one question to higher skilled developers:
is it allowed in SQL to use LIMIT?

eg. change
SELECT dst FROM {url_alias} WHERE src = '%s'
to
SELECT dst FROM {url_alias} WHERE src = '%s' LIMIT 1

does this give us a performance gain?

nicholasThompson, what you are describing happens for example if you are using pathauto configured to add a new alias after an update of a node.
what we are doing in this case is to take the first entry we find in the database.

I could imagine that we add a new "active" or "weight" row to the url_alias-table but I think this is another issue and could mean a loss of speed...

* could someone run a benchmark, because I got weird results on my last test (see #11)
* look over the code again
* and set it asap to "ready to be commited" to see what happens and what the big guys say about that...

i think order by costs speed
so this will never come

well i did another benchmark - this time without mysql query cache.

the patch is on my test environment around 5% slower than without the patch.
but it works and fixes a few issues

so I set it to rtbc and look what happens....

btw. how to disable mysql query cache

at /etc/mysql/my.cnf:
change
query_cache_type = 1
to
query_cache_type = 0

don't forget to restart your mysql server
(this could be a good addition to http://drupal.org/node/79237)

I dont have access to edit the handbook

I looked at the pgsql handbook and it seems that it will be supported.

pgsql 8.1:
http://www.postgresql.org/docs/8.1/interactive/sql-select.html#SQL-LIMIT

pqsql 7.3
http://www.postgresql.org/docs/7.3/interactive/sql-select.html#SQL-LIMIT

rtbc still remains for #14

but i tried to optimize it more and more.
here you can see my current stage.
I tried for hours and hours a lot of things
I can't really say if the new patch is faster
so i would be really happy if someone could test it on his machine

Thanks

what did I change?

• replace count()-query - why do we look for count which does us not really interest? let us get any alias so this MAY save us a query later on
• replace drupal_get_normal_path() with drupal_lookup_path('source', ...) - dont call a function you dont really need in this case. stay inside drupal_lookup_path()
• shifted around the queries - no speed gain. to get the alias in some special case (i nver saw this one but i could think that this may happen)
• added ORDER BY pid DESC LIMIT 1 - only to one of the two queries, because the other one has UNIQUE in the db - i added order by because pgsql-doc suggests it
• path.module can use drupal_lookup_path('alias', $path) instead of its own query

here comes a new patch.
this time it is 0.44 % slower than the current query (as alway please benchmark it too i want to hear about your results)
it is the best result currently

please test it
and tell me if there are any negative side effects

the one at #32 is the most current one.
it was developed for 5.0 but there was a commit so this will not anymore apply cleanly.
but it should be easy for you to solve this

it should be possible to apply this to drupal 4.7, too but then with a little bit hand work
it the patch file you can read modules/path/path.module this file was in drupal 4.7 at modules/path.module
modules/block/block.module was at modules/block.module

I want to inform you that there is another issue which hacks around in drupal_lookup_path()
http://drupal.org/node/97317
but with another purpose..
this is the reason why this issue does not apply anymore

here comes a new patch

I didnt test it much, because of lack of time.

I had to clear my cache to get this running...

something veeery old slipped in...

it runs since a few days on my test page and works as expected

and here comes a new, better one patch.

thank you for trying the patch.
I appreciate every feedback I get.

here comes a fixed patch.
I hope it works for you, too

You can see my test case below
I use it inside the devel.module's execute block

$url['taxonomy/term/16']      = TRUE;
$url['blog/tags/countries']   = TRUE;
$url['taxonomy/term/1']       = FALSE;
$url['blog']                  = FALSE;
foreach ($url as $address => $flag) {
  if ($flag) {
    print 'should be frontpage url = ';
  }
  print url($address, NULL, NULL, TRUE);
  print "<br />\n";
}

I set taxonomy/term/16 and blog/tags/countries to my frontpage path