Problem

When the Include base URL in expires option is enabled, the URLs for the expired paths are not properly build as their are missing the slash ('/') between the base URL and the paths.

Proposed resolution

Append the trailing slash to $base_url when used in expire_cache_derivative().

Comments

pbuyle’s picture

StatusFileSize
new900 bytes
halcyonCorsair’s picture

Status: Active » Needs review
halcyonCorsair’s picture

anavarre’s picture

Just tested patch in #1. Content is now correctly updated in the front page, whether it's a new or updated content. Individual pages are looking very fine as well.

anavarre’s picture

Status: Needs review » Reviewed & tested by the community
halcyonCorsair’s picture

I'll take a look at this during the weekend, and hopefully commit it.

kim.pepper’s picture

I have tested this patch and confirm it works for me.

halcyonCorsair’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/expire.module
@@ -435,7 +435,7 @@ function expire_cache_derivative($paths, &$node = NULL) {
+    $base_urls[] = $base_url . '/';

It has been pointed out to me that using base_path() (http://api.drupal.org/api/drupal/includes!common.inc/function/base_path/7) instead of '/' is more correct here.

e.g.

+++ b/expire.module
@@ -435,7 +435,7 @@ function expire_cache_derivative($paths, &$node = NULL) {
+    $base_urls[] = $base_url . base_path();
tekante’s picture

StatusFileSize
new908 bytes

Adjustment to patch in #1 based on commentary in #8

fizk’s picture

Priority: Normal » Major

Please commit the fix.

The "Include base URL in expires" option is enabled by default, so this issue shows up in the default use case.

halcyonCorsair’s picture

I will work on this and some of the other open issues tomorrow.

halcyonCorsair’s picture

Status: Needs work » Fixed

Fixed in dev.

unkn0wn’s picture

Status: Fixed » Needs work

Now i see in nginx logs:
127.0.0.1 - - [28/May/2012:05:56:27 +0400] "PURGE /node/826929 HTTP/1.1" 200 0 "-" "-"
127.0.0.1 - - [28/May/2012:05:56:27 +0400] "PURGE /taxonomy/term/1643 HTTP/1.1" 200 0 "-" "-"
127.0.0.1 - - [28/May/2012:05:56:27 +0400] "PURGE /ttp://dcom.ru/node/826929 HTTP/1.1" 200 0 "-" "-"
Where is "h" letter in http and and is "http://" prefix really needed?

Also i have e-store with 13 subdomains for different languages. Product descriptions translated via Content Translation module. I have no use Domain Access, i simply define different domain for each language in 'Detection and Selection'. But expire module cannt handle this feature, as result expire provide path alias for general language and /node/XXXXXX for all other languages, so only general language flushed from cache. I even try to install Domain Access and create two subdomains for test, but it's really trouble for me: i have ~300.000 nodes, and each node i must link to domain.

mrfelton’s picture

Status: Needs work » Needs review
StatusFileSize
new1.13 KB

The fix that was committed was incorrect. $base_url includes everythign but the trailing slash. If you have your site in a subdirectory, $base_url will be http://example.com/directory and $base_path will be /directory/. With the code that was committed, this will result in expire urls like http://example.com/directory/directory/, which is wrong.

This module should be appending a trailing slash to the base url, and not the entire base_path, since the base path is already included in base_url (minus the trailing slash). Patch attached.

Also, the global really should be defined at the top of the function. Patch resolves.

nicholasthompson’s picture

StatusFileSize
new906 bytes

How about just using url() with the absolute option? That way the tried-and-tested Drupal Core system handles it? IMHO I think we should be using url() in more places rather than the global $base_path and $base_url variables.

manos_ws’s picture

Status: Needs review » Reviewed & tested by the community

I confirm that both #14 and #15 work.
Without fixing this I cant use the module.

Please review this and commit it

anavarre’s picture

Ok, so should we settle on $base_url . '/'; for now and move forward?

heddn’s picture

StatusFileSize
new663 bytes

re-rolled #15 and removed the un-needed global $base_url

kim.pepper’s picture

Status: Reviewed & tested by the community » Needs review
pgrond’s picture

StatusFileSize
new850 bytes

It is still not always correct in a multilingual site. I added a simple line that makes sure there is always 1 / at the end of the string.

heddn’s picture

@pgrond, I don't see where the new line that was inserted ever is read. Is this patch missing some code? Can you explain how/why the earlier fix isn't effective on multi-lingual sites?

pgrond’s picture

I'm sorry, I also posted another patch (issue http://drupal.org/nonde/1728652). The complete code is:

if (variable_get('expire_include_base_url', EXPIRE_INCLUDE_BASE_URL)) {
    $base_urls[] = url('', array('absolute' => TRUE)); 
    if (module_exists('domain')
     && module_load_include('inc', 'expire', 'expire.domain') != FALSE) {
      $base_urls = array_merge($base_urls, expire_get_base_urls($node));
    }
    foreach ($expire as $path) {
      foreach ($base_urls as $base) {
        // If domain access is enabled the $base_urls is an array with configured subdomains
        if (is_array($base)) {
          foreach($base as $subdomain) {
            $urls[] = $subdomain . $path;
          }
        }
        else {
          $base = rtrim($base, '/').'/';
          $urls[] = $base . $path;
        }
      }
    }
  }
  else {
    $urls = $expire;
  }

The / is not added correctly all the time. Did not debug in detail but this line ensures there is one slash at the end of the base path.

jemond’s picture

Status: Needs review » Reviewed & tested by the community

I can confirm this patch works in production. I think the url()/absolute method is more maintainable than the slash append approach, so this patch looks good to me.

heddn’s picture

StatusFileSize
new1.56 KB

Rolled #22 into a patch. RTBC once again.

jemond’s picture

Status: Reviewed & tested by the community » Needs review

Apologies, I was reporting that the patch in #20 was working, not #22.

SqyD’s picture

Ok... I am committing the patch in #24. It looks fine to me... Thanks all!

SqyD’s picture

Status: Needs review » Fixed

comitted to 7.x-1.x. Thanks all involved!

Status: Fixed » Closed (fixed)

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