Problem/Motivation
When the website is set to use "Domain" based URL language detection and you try to use facets from a facet source with a facets_pretty_path url processor, it doesn't work.
Steps to reproduce
- Enable Domain based language url detection:
/admin/config/regional/language/detection/urland fill in the urls for each enabled language. - Use a facet from a source that has been set to use facets_pretty_path (and AJAX)
- The facet will appear to not work, reloading the page will display the error message e.g. "The user-entered string
http://<site url>/<facet pretty path components>must begin with a '/', '?', or '#'."
This is because in Drupal\language\Plugin\LanguageNegotiation\LanguageNegotiationUrl::processOutbound(), if the 'Domain' option is used, then the outbound site URLs are rewritten to use an absolute path.
Then, when in Drupal\facets_pretty_paths\PrettyPathsActiveFilters::getFiltersFromRoute() this line here:
$route_params = Url::fromUserInput($q)->getRouteParameters();
attempts to use the now absolute url with the Url::fromUserInput($q) call, which fails.
Proposed resolution
To solve this, i've gone with a relatively simple method of determining whether the site is using domain based language negotiation, and parsing $q to extract just the path, which is what it would be for a site that doesn't have domain based language negotiation set.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | facets_pretty_paths-language_negoriation_url_ajax_fix-3328831-9.patch | 3.61 KB | rossb89 |
Issue fork facets_pretty_paths-3328831
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
rossb89 commentedPatch attached.
I should note that this does work nicely and apply alongside of patch 5 from "FPP lost path context on ajax request" https://www.drupal.org/node/3129632
Comment #3
rossb89 commentedComment #4
rossb89 commentedComment #5
rossb89 commentedComment #6
joseph.olstadReroll, I'd feel more comfortable about this if there was a check wrapping this logic to ensure that the language module was installed using a condition on the moduleHandler for the language module before trying to open the configuration that might not exist and could throw a null exception.
Comment #7
joseph.olstadThe above patch needs some extra logic to make sure it doesn't crash for those not using language negotiation.
https://www.drupal.org/project/facets_pretty_paths/releases/8.x-1.5
Comment #9
rossb89 commentedI had completely forgotten about this!
I've re-done this against the latest 8.x-1.x with the suggested change to check the language module exists before trying to load the config.
I have opened a MR, but will attach a patch just in case that is useful for anyone.
Comment #10
rossb89 commentedComment #12
joseph.olstadComment #13
joseph.olstadhttps://www.drupal.org/project/facets_pretty_paths/releases/2.0.3
Comment #14
joseph.olstadComment #15
joseph.olstadMaybe should mark 8.x-1.x-dev as not supported.
Comment #16
rossb89 commentedAh yes, I totally should have done this against 2.x! Thanks for approving, merging in and doing a new release!
I guess this issue can be marked as fixed now? I see 1.x isn't visible on the project homepage anymore.
Comment #17
joseph.olstad