-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update drupal #12
Update drupal #12
Conversation
provider: openseadragon | ||
label_display: '0' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know where you can see these schemas (or if you can) but I noticed this label_display
has a value of '0'
(a string) and below (line 45 -> 49) it is label_display: visible
. So does '0'
mean "visible" or "hidden" or something else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strictly, this should be referring to https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/config/schema/core.data_types.schema.yml#L303-305 (via https://github.com/Islandora/openseadragon/blob/8f9eeff9d3be213dfa5e0477959df5882776cb44/config/schema/openseadragon.schema.yml#L15-L16)... we're dealing with the settings of a block here which should be defined as block_settings
; however, I seem to recall digging in to things a bit in the semi-recent past, and the placing of blocks via contexts breaks the associations back to the underlying schema definitions... instead rolling their own schema which seems like copypasta of the core block_settings
type with some additional context specific properties.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Digging deeper, the concrete value seems to come from the block plugin; for example, the trait associated with the BlockPluginInterface
defines a checkbox for this property... When checked, would give the #return_value
of BlockPluginInterface::BLOCK_LABEL_VISIBLE
... when unchecked, 0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So maybe some of these are just stale? I notice both this-here-referenced block config with label_display: 0
and the one below (lines 45-49 with label_display: visible
) are both for the bartik
theme. We haven't used that in ages! And we have documented the need to update all of them to use Olivero. Hopefully that will flush out any stale config language in these contexts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand this enough to approve or disapprove. I had one comment (above) and I noticed that the islandora_fits patch is removed, was this change added elsewhere?
Other than that I can say that I reviewed all the files (except composer.lock, because I'm not crazy) and they all seem to just be re-ordering of elements.
There were some small changes (some I have lost) one example is in config/sync/search_api.index.default_solr_index.yml
where a multilingual
key is added and the roles
was modified from an associative array to a regular array.
Yes, when I installed the security updates there were some database updates to do. I recall one of them - i think it was for search_api - was related to multilingual. |
I did a git pull on isle-dc to get the latest updates and then modified my Makefile to use this branch: diff --git a/Makefile b/Makefile
index 65251df..2afce8d 100644
--- a/Makefile
+++ b/Makefile
@@ -540,7 +540,7 @@ starter_dev: QUOTED_CURDIR = "$(CURDIR)"
starter_dev: generate-secrets
$(MAKE) starter-init ENVIRONMENT=starter_dev
if [ -z "$$(ls -A $(QUOTED_CURDIR)/codebase)" ]; then \
- docker container run --rm -v $(CURDIR)/codebase:/home/root $(REPOSITORY)/nginx:$(TAG) with-contenv bash -lc 'git clone -b main https://github.com/Islandora/islandora-starter-site /home/root;'; \
+ docker container run --rm -v $(CURDIR)/codebase:/home/root $(REPOSITORY)/nginx:$(TAG) with-contenv bash -lc 'git clone -b update-drupal https://github.com/rosiel/islandora-starter-site /home/root;'; \
fi
$(MAKE) set-files-owner SRC=$(CURDIR)/codebase ENVIRONMENT=starter_dev
docker-compose up -d --remove-orphans I then did However, a lot of things aren't working. First, the status page reported SOLR wasn't working (it was using 127.0.0.1 for the host, changing that to 'solr' fixed it). Also, derivatives aren't working either. I presume these issues are just starter site issues + isle in general and not necessarily a blocker for this PR, correct? |
Hm. It's quite possible that |
What does this Pull Request do?
Security updates to Drupal and twig.
Related GitHub Issue: (link) n/a
Other Relevant Links: (Google Groups discussion, related pull requests,
Release pull requests, etc.)
What's new?
what's not new?
How should this be tested?
Does it work/load drupal?
Documentation Status
Additional Notes:
Any additional information that you think would be helpful when reviewing this
PR.
Interested parties
Tag (@ mention) interested parties or, if unsure, @Islandora/committers