Attended
Added the composer merge plugin and testing of different methods.
https://github.com/localgovdrupal/localgov_project/pull/173
finn lewis → credited andybroomfield → .
finn lewis → credited andybroomfield → .
finn lewis → credited andybroomfield → .
finn lewis → credited andybroomfield → .
See the linked Github issue above:
- Create a new directory venue with a brand new geo entity as a location. This should geocode the map pin.
- Then edit said directory venue, and edit the location (not delete and replace).
- Clear out the address and try to add a new one. Whilst the autocomplete does replace it, the leaflet map pin and lat / lon fields are not updated.
finn lewis → credited andybroomfield → .
finn lewis → credited andybroomfield → .
I'm seeing this issue on Drupal 10.3.9. This is happening on paragraphs and any custom entity (content types seems fine).
It appears to be any field, except the first which opens fine.
Error is
: Undefined array key "localgov_opens_in_a_new_window" in on line
: Trying to access array offset on value of type null in on line
: Trying to access array offset on value of type null in on line
: Trying to access array offset on value of type null in on line
: Trying to access array offset on value of type null in on line
Patch in #2 does resolve this issue.
Might be a new issue though, this is what we are seeing. The child paragraphs are bleeding out of the container.
Just to add I'm also seeing this on Gin-rc14 and not using paragraphs EE.
@cilefen yes, i'm able to get it working with the states.js file from Drupal 10.2 inside of an otherwise 10.3 site.
andybroomfield → created an issue.
Changing
once('geoEntityGeocodeLeaflet', document.getElementById(formId)).forEach(function (form) {
to
once('geoEntityGeocodeLeaflet', document.querySelectorAll('form[id^="' + formId + '"]')).forEach(function (form) {
works. Might not be the most performant though.
andybroomfield → created an issue.
Bumping back to needs review for the updated MR.
Looking at $entity->get($field) on the node page gives me
Drupal\computed_field\Field\ComputedFieldClass {#2574 ▼
#definition:
Drupal\computed_field\Field
\
ComputedFieldDefinition {#2572 ▶}
#name: "localgov_event_date_occurrence"
#parent:
Drupal\Core\Entity\Plugin\DataType
\
EntityAdapter {#2423 ▶}
#_serviceIds: []
#_entityStorages: []
#stringTranslation: null
#typedDataManager:
Drupal\Core\TypedData
\
TypedDataManager {#594 ▶}
#list: []
#langcode: "en"
#valueComputed: true
}
On the Search API page I get
Drupal\computed_field\Field\ComputedFieldClass {#9711 ▼
#definition:
Drupal\computed_field\Field
\
ComputedFieldDefinition {#9742 ▶}
#name: "localgov_event_date_occurrence"
#parent:
Drupal\Core\Entity\Plugin\DataType
\
EntityAdapter {#9788 ▶}
#_serviceIds: []
#_entityStorages: []
#stringTranslation: null
#typedDataManager:
Drupal\Core\TypedData
\
TypedDataManager {#1240 ▶}
#list: array:1 [▼
0 =>
Drupal\datetime_range\Plugin\Field\FieldType
\
DateRangeItem {#9688 ▼
#definition:
Drupal\Core\Field\TypedData
\
FieldItemDataDefinition {#9741 ▶}
#name: 0
#parent:
Drupal\computed_field\Field
\
ComputedFieldClass {#9711}
#_serviceIds: []
#_entityStorages: []
#stringTranslation: null
#typedDataManager:
Drupal\Core\TypedData
\
TypedDataManager {#1240 ▶}
#values: array:3 [ …3]
#properties: array:2 [ …2]
}
]
#langcode: "en"
#valueComputed: true
}
I traced the NULL value to docroot/core/lib/Drupal/Core/TypedData/ComputedItemListTrait.php which the get method returns NULL if there is no value in the index.
public function get($index) {
if (!is_numeric($index)) {
throw new \InvalidArgumentException('Unable to get a value with a non-numeric delta in a list.');
}
// Unlike the base implementation of
// \Drupal\Core\TypedData\ListInterface::get(), we do not add an empty item
// automatically because computed item lists need to behave like
// non-computed ones. For example, calling isEmpty() on a computed item list
// should return TRUE when the values were computed and the item list is
// truly empty.
// @see \Drupal\Core\TypedData\Plugin\DataType\ItemList::get().
$this->ensureComputedValue();
return $this->list[$index] ?? NULL;
}
I think it returns NULL as the ComputeValue of src/Plugin/ComputedField/DateOccurrence.php will return an empty array. I can change this to ['now'] and the entity pages get a dateTime of the current date.
We're not setting this to anything, it's just a NULL value if it's not computed becuase we're viewing the entity page. it's outside of a search api view. But we get the WSOD even though we don't have the computed field in our manage display. It throws the error regardless.
Added initial patch in MR.
andybroomfield → created an issue.
andybroomfield → created an issue.
andybroomfield → created an issue.
This is fixed in localgov_alert_banner 1.7.6.
Thanks for your contribution adinancenci.
I think this issue might have cropped up again, just trying the config above in fresh webform and experincing this issue.
Thanks Adinancenci for spotting the issue and the patch.
I've opened a PR on Github repo for testing
https://github.com/localgovdrupal/localgov_alert_banner/pull/319
andybroomfield → created an issue.
It looks like the method createDbQuery in modules/search_api_db/src/Plugin/search_api/backend/Database.php is where the locations fields are addded
$this->addLocationConditions($condition_group, $query);
But since this gets called not just when assembling the original query but also when facets are being built in the getFacets method
I've managed to resolve the issue I encountered with the facets by cloning the $query in createDbQuery with the passed in $query, patch attached.
Thanks for the work on this patch.
This is working for when there are multiple locations.
I've discovered there is an issue when adding facets to a search api view with location, where the query looks like its adding the location query multiple times and is preventing the query working with this patch.
I get this error: A database exception occurred while searching.
and then no search results.
I've pushed a rebased branch that removes the .install modifications.
The module still installs on Drupal 10 and tests are passing so this is ready for review again.
Have tested this and selecting add indefinatly does ban the IP address with a date set to 2038 (max unix time stamp).
Hopefully I've got the merge request ok, otherwise I can submit as a standard patch.
andybroomfield → created an issue.
andybroomfield → created an issue.
We've encounterd this issue and applied the patch in comment 9.
Its been working well so far and not had a reoccurance of this issue, though there is a strange side effect that may be related.
After a cache clear, our editors told us they could not access /admin/content anymore. This was due to a PHP error
Symfony\Component\Routing\Exception\RouteNotFoundException: Route "view.block_content.page_1" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 206 of /mnt/www/html/docroot/core/lib/Drupal/Core/Routing/RouteProvider.php).
As this patch removes routes that start with view. if they override an admin listing (entitiy collection), I believe this is now getting removed by this patch. Not sure why this would then not work like the other admin views that override entity collections?
We can work around this issue by disabling the content block view, which we don't use content blocks anyway.
andybroomfield → created an issue.
andybroomfield → created an issue.
Tests are now passing on Drupal CI.
There are still linter and coding standards warnings, though I suggest that is handled in a new issue.
This also builds on current dev work so should now install on Drupal 10.
andybroomfield → created an issue.
I have reviewed this in a fresh install on Drupal 10 (using the composer drupal lenient plugin) and then applied the patch in #11.
I tested assigning VAPN to a basic page and then verifying that only users with the appropriate role could access the selected content.
I'd be happy for this to be merged for Drupal 10.
andybroomfield → created an issue.
We're actually having a little trouble replicating this exactly.
It does seem to happen, but the circumnstaces are weirdly specific. It's when one of the pages was previously published, then set back to draft with the latest revision, but the previous revision is left published. Then trying to use preview link on some (but not all) the child pages results in the error.
I don't actully think Book is at fault here, it must be something to do with the way the preview link is interacting with workflow and content revisions, but will need more investigation. The patch fixes the error in that the navigation block can then display, though thats probably not the real problem.
andybroomfield → created an issue.
I have tested this and it workd for me on a couple of the few Drupal 7 sites I still support.
Have added patch / MR.
Noticed another issue whist fixing (might be a PHP 8.1 issue) that passing the result of $this->getPublishStatusLink directly into Drupal renderer was throwing a 'Only variables should be passed by reference' when I fixed the operations link.