While this patch will fix the issue, applying the patch locally won't actually fix the problem if a site has the core update module enabled. The version is checked remotely when update refreshes available updates so this issue has the potential to white screen any site with this and the update module enabled without any updates to the
Full error message
The website encountered an unexpected error. Try again later.
UnexpectedValueException: Could not parse version constraint ^: Invalid version string "^" in Composer\Semver\VersionParser->parseConstraint() (line 521 of /code/vendor/composer/semver/src/VersionParser.php).
Composer\Semver\VersionParser->parseConstraints('^10 || ^ 11') (Line: 40)
Composer\Semver\Semver::satisfies('10.2.5', '^10 || ^ 11') (Line: 161)
Drupal\update\ProjectCoreCompatibility->isCoreCompatible('^10 || ^ 11') (Line: 144)
Drupal\update\ProjectCoreCompatibility->setReleaseMessage(Array) (Line: 124)
update_calculate_project_data(Array) (Line: 40)
update_requirements('runtime') (Line: 91)
update_page_top(Array) (Line: 352)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}(Object, 'update') (Line: 388)
Drupal\Core\Extension\ModuleHandler->invokeAllWith('page_top', Object) (Line: 67)
Drupal\hook_event_dispatcher\HookEventDispatcherModuleHandler->invokeAllWith('page_top', Object) (Line: 353)
Drupal\Core\Render\MainContent\HtmlRenderer->buildPageTopAndBottom(Array) (Line: 146)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 186)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 38)
Drupal\mercury_editor\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
pixelwhip → created an issue.
Closing this as outdated. It has been fixed in 2.x.
pixelwhip → created an issue.
pixelwhip → created an issue.
Released 1.1.0 with Drupal 10 support
pixelwhip → made their first commit to this issue’s fork.
pixelwhip → made their first commit to this issue’s fork.
This merge request is intended to be tagged as 1.1.x. It updates the core requirements and changes the dependency to the core version of SDC.
pixelwhip → made their first commit to this issue’s fork.
This merge request adds a clip-path to the button pane to clip out a notch in the bottom corner to allow the resize handle to be visible.
pixelwhip → created an issue.
pixelwhip → created an issue.
pixelwhip → made their first commit to this issue’s fork.
pixelwhip → created an issue.
pixelwhip → made their first commit to this issue’s fork.
This was fixed as part of the Cypress tests update in addition to adding a new clean
task that will remove all compiled CSS and JS assets.
pixelwhip → created an issue.
Thanks everyone for your help on this. I've made some additional modifications and merged it into 5.x. There are some related changes I'd like to consider regarding the links and spacing but will handle that elsewhere. For now, this is a big improvement over the previous teaser and provides a more sane default.
pixelwhip → created an issue.
#22 fixed the issue I was having and works with the back button.
I refactored this change to move all the internal methods inside the Drupal behavior so other modules and themes might more easily tap into it. I needed this as my exposed form contained some custom multi-select listboxes that are not handled by change alone and are outside the scope of this module.
The original merge request has been updated to include the latest changes from #8 it also reintroduces support for multi-value filters that are formatted as ?filtername[]=foo&filtername[]=bar
. This was removed in patch #6. It seems multi-value filters can have different formats in the url search params.
pixelwhip → created an issue.
The `--server-url` is already possible with Drush's `--uri` option. In my case, I need to omit the server url from the stories.json file completely so it can be set in the Storybook configuration.
Example:
drush storybook:generate-all-stories --uri=https://spiffy.url
I discovered this recently when setting Storybook up with Tugboat for the Prototype theme ✨ Add tugboat integration Active . If you don't have the URI configured for Drush, the URL will end up being `http://default*`
I'm in favor of this and think it would be a DX improvement.
I prefer @use "../../../libraries/partials/partials" as *;
or even adding the partials path /libraries/partials
a loadPath in the sass configuration so we can shorten it to something like @use "partials" as *;
See https://sass-lang.com/documentation/js-api/interfaces/options/#loadPaths
The reason wildcard includes are frowned upon in JS is it makes it impossible to treeshake dead code paths when the code is bundled – resulting in larger than needed bundle sizes. Since we don't (or at least shouldn't) be putting selectors in our partial files, this is not a constraint we need as the compiled CSS won't. include any output from the partials.
pixelwhip → created an issue.
Thanks for getting this started. It's definitely a step in the right direction. I've added comments to the pull request.
This fix has been released as part of 2.1.x-alpha16
Closed and reopened the MR in an attempt to trigger tugboat and tests
pixelwhip → made their first commit to this issue’s fork.
Thanks for all your work on this. Merged!
pixelwhip → created an issue.
pixelwhip → created an issue.
pixelwhip → created an issue.
pixelwhip → created an issue.
pixelwhip → created an issue.
pixelwhip → created an issue.
pixelwhip → created an issue.
pixelwhip → created an issue.
pixelwhip → created an issue.
pixelwhip → created an issue.
pixelwhip → created an issue.
pixelwhip → created an issue.
pixelwhip → created an issue.
Thanks for the work on this! Just wanted to let you know this is on our radar and will hopefully be able to review and move it along in the next couple days.
pixelwhip → created an issue.
There is currently no configuration for this. You could potentially alter the dialog data attributes on the local tasks similar to how mercury_editor_menu_local_tasks_alter
creates them.
@Sbubaron Mercury Editor currently uses the default node edit form. You could achieve what you're looking for fairly simply by defining a custom form display, configuring it with just the fields you want, then defining a new route that points to that entity form display. See https://www.drupal.org/docs/drupal-apis/routing-system/structure-of-routes →
Added a new MR for 5.x
pixelwhip → made their first commit to this issue’s fork.