Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
In #2773163: Unrouted URIs do not have internal representations, external URL routing was fixed inside the generateBundleUrls()
method of BatchUrlGenerator
, but not in the generateCustomUrls()
method. I'll attach a patch which applies the same fix in that method (I was getting the same error, but it was in a custom URL it seems).
Full error from drush simple_sitemap-generate
below:
Initializing batch... [status]
exception 'UnexpectedValueException' with message 'Unrouted URIs do not have internal representations.' in [error]
/var/www/site/docroot/core/lib/Drupal/Core/Url.php:768
Stack trace:
#0 /var/www/site/docroot/modules/contrib/simple_sitemap/src/Batch/BatchUrlGenerator.php(178):
Drupal\Core\Url->getInternalPath()
#1 /var/www/site/docroot/modules/contrib/simple_sitemap/src/Batch/Batch.php(125):
Drupal\simple_sitemap\Batch\BatchUrlGenerator->generateCustomUrls(Array)
#2 [internal function]: Drupal\simple_sitemap\Batch\Batch::generateCustomUrls(Array, Array,
Object(DrushBatchContext))
#3 /var/www/site/vendor/drush/drush/commands/core/drupal/batch.inc(163):
call_user_func_array('Drupal\\simple_s...', Array)
#4 /var/www/site/vendor/drush/drush/commands/core/drupal/batch.inc(111): _drush_batch_worker()
#5 /var/www/site/vendor/drush/drush/includes/batch.inc(98): _drush_batch_command('23097')
#6 /var/www/site/vendor/drush/drush/commands/core/core.drush.inc(1206): drush_batch_command('23097')
#7 [internal function]: drush_core_batch_process('23097')
#8 /var/www/site/vendor/drush/drush/includes/command.inc(373): call_user_func_array('drush_core_batc...',
Array)
#9 /var/www/site/vendor/drush/drush/includes/command.inc(224): _drush_invoke_hooks(Array, Array)
#10 [internal function]: drush_command('23097')
#11 /var/www/site/vendor/drush/drush/includes/command.inc(192): call_user_func_array('drush_command', Array)
#12 /var/www/site/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch(Array)
#13 /var/www/site/vendor/drush/drush/includes/preflight.inc(66):
Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#14 /var/www/site/vendor/drush/drush/drush.php(12): drush_main()
#15 {main}
Comment | File | Size | Author |
---|---|---|---|
#8 | Screen Shot 2016-11-30 at 10.20.39 AM.png | 107.43 KB | chrisfromredfin |
#2 | unrouted_uris_do_not-2828238-2.patch | 587 bytes | geerlingguy |
Comments
Comment #2
geerlingguy CreditAttribution: geerlingguy commentedPatch attached.
Comment #3
gbyte CreditAttribution: gbyte as a volunteer and commentedThe custom link form validator should prevent non-routed paths from being put in. Could you please investigate what kind of paths created this problem and how they made it into configuration?
Great work with the drupalvm BTW :)
Comment #4
gbyte CreditAttribution: gbyte as a volunteer and commentedComment #5
geerlingguy CreditAttribution: geerlingguy commented@gbyte.co - I'll try to figure out what was causing it at some point, but it could be a bit of time—I had to get that fixed for a client ASAP but won't be able to get back to that codebase/database for a while, most likely :/
They had about 12,000 URL paths in the sitemap, but I'm fairly certain it was a custom menu path for one of their menu links.
Comment #6
chrisfromredfinI am having the same issue as @geerlingguy. Here's my stacktrace. My guess is that it's the full canonical link to the frontpage/homepage. This is on a dev instance, but having the same issue on production cron runs.
His patch "fixes" the issue (makes the error go away, anyway).
Command: drush8 -l http://gallerysystem.dev cron
Backtrace:
I think the specific case is toward the bottom of #2 there - it's the only "external" URL I can see in the stacktrace:
Comment #7
gbyte CreditAttribution: gbyte as a volunteer and commented@cwells How did this link get into the custom link configuration? Did you use the form or the API to import custom links?
Comment #8
chrisfromredfinLooks like I did it.
Comment #9
gbyte CreditAttribution: gbyte as a volunteer and commentedThis can't be the home
/
path. I am guessing it is one of the other paths. I am not sure however how this error comes up, as there is form validation checking that the links put in are valid and during generation there is also a check which skips and logs all invalid custom links. If any of you guys could reproduce this error on a fresh instance, I will be happy to patch it.Comment #10
geerlingguy CreditAttribution: geerlingguy commented@gbyte.co - I did notice just now that updating a Features export changed the way the home page path is stored:
So now the exported
simple_sitemap.custom.yml
config file looks like:Maybe the way the config was exported previously (I think it was using Symfony's YAML component on this project) was making the import do something weird in the active config? I still can't reproduce the issue at this time.
Comment #11
chrisfromredfinI can re-create this. I installed a bare Drupal 8 latest (8.2.4) and the latest stable simple_sitemap (8.x-2.8).
Create a view called "blog" that's a view of teasers of articles. Create a page display (be sure to set the path of the view to /blog). All other things are default settings on the view.
Add "/blog 0.6" to the custom links in the simple sitemap.
Invoke cron using drush (<- this is important, it does not happen when invoking cron through the UI).
Comment #12
chrisfromredfinUpdating to active, I think the 'more info' was that it happens only when invoking cron using drush (drush version 8.1.8, btw).
Comment #13
gbyte CreditAttribution: gbyte as a volunteer and commentedI just tried to reproduce the issue by installing Drupal 8.2.5 and simple_sitemap 2.8 and tried regenerating through UI, cron and
drush core-cron
. No exceptions and no logged errors there. After deleting the view, the old link is logged as non-existant to watchdog during generation and there are no PHP exceptions. I am really surprised you got this on a new install but I need to be able to reproduce this myself to take action. Anyone else getting this on a fresh install?Comment #14
pjcdawkins CreditAttribution: pjcdawkins at Platform.sh commentedI'm getting this.
Attempting to debug, it looks like via cron, any Url::fromUserInput('/foo') will be interpreted as unrouted.
Through the UI, there's no problem.
Tracing it further, the problem is in Url::fromInternalUri():
The condition fails (due to PathValidator::getPathAttributes() encountering a caught MethodNotAllowedException), so the
$url
is returned prefixed bybase:
, which means it's unrouted.That MethodNotAllowedException appears because the method is interpreted as an empty string. But $_SERVER['REQUEST_METHOD'] is set to GET, even via Drush. The empty string is introduced somewhere and I don't understand where.
Comment #15
pjcdawkins CreditAttribution: pjcdawkins at Platform.sh commentedA couple of hours later... I've found a solution.
This appears to relate to a Drush bug: https://github.com/drush-ops/drush/issues/2511
With the patch from here for Drush: https://github.com/drush-ops/drush/pull/2512.patch
it will work, and the sitemap produced is identical to the one produced via the UI.
That patch has been committed to Drush, but not yet released.
Comment #16
kentr CreditAttribution: kentr as a volunteer commentedpjcdawkins alerted me to this issue.
The drush patch has been committed to
8.x
andmaster
, so you can get it by installing the dev versions.Something like one of:
Because of the drush finder script, you have to do some workarounds to use these if you also have a project-specific drush (like if you're using Drupal Composer Template). The easiest way I got around it is by removing the project-specific drush completely.
Comment #17
pjcdawkins CreditAttribution: pjcdawkins at Platform.sh commentedkentr: if you're using a project-specific drush with Composer, you can add a project-specific patch in composer.json:
Comment #18
kentr CreditAttribution: kentr as a volunteer commentedAh, nice trick.
Comment #19
chrisfromredfinI had some dependency issues trying to update my local drush to 8.2.x-dev, so I manually applied the patch and can confirm this fixes the issue. Drush issue, not Simple Sitemap's.
I know drush issues are handled in their github, but wanted to make sure the issue queue reflects the right project.
Comment #20
chrisfromredfinComment #21
gbyte CreditAttribution: gbyte as a volunteer and commentedGood work guys, thanks for the investigation and quick commits.