a page not found returned after flushing a page cache

I think we should be using base_url rather than base_root to account for Drupal being under sub-directory. Solving that should solve the multilanguage site redirect issue.

I agree that we need to account for the whole URL and path during a flush page cache request. So I isolated this information into two new helper functions called flush_page_cache_get_url() and flush_page_cache_get_path().

I also cleaned up the 'Clear custom cache cid and tables based on drupal path." code so that it uses the drupal_match_path() function which has full wildcard support.

Finally, I found a bug in the admin_settings table where it just was saving new values.

iamEAP, maybe I should just commit these changes to the 6.x-1.x and 7.x-1.x branches so that it will be easier to test.

I like the bug fixes there.

I feel like flush_page_cache_get_url() is still duplicating work core does for us (D7: drupal_settings_initialize, D6: conf_init).

I'm also not 100% sure parse_url handles the multilingual path prefixes (that this thread was about originally) very well, but I'll test in the morning.

Actually my code changes are trying to bypass core's handling of URLS because several core and contributed modules mess with these parameters during the process of loading and rendering the page, meanwhile no one tends to touch $_SERVER variables via request_uri().

Works for me.

I might change the re-wording in the example, but otherwise, I like the changes.

Example paths are blog for the blog page and blog/* for every personal blog. is the front page.

To maybe...

Example paths are blog for the blog page and blog/* for all blog entries. is the front page.

That text was takens from block module's block_admin_configure() and I forgot to include the $t_args which include the paths and front pages link.

Thanks for catching that.

http://drupalcode.org/project/flush_page_cache.git/commit/6202574