capysara → created an issue.
Add a MR to include use DependencySerializationTrait in the logger.
I updated the title and IS. Looks like it's related to the new relic module. When it's enabled, the UI doesn't work.
capysara → created an issue.
swirt → credited capysara → .
I updated the MR so it's against 11.x. It works, but the code is just copy/pasted so it needs to be updated for modern coding standards. IS still needs updated as noted in a previous commit.
capysara → changed the visibility of the branch 711735-block-filter-category-11 to hidden.
capysara → changed the visibility of the branch 11.x to hidden.
capysara → made their first commit to this issue’s fork.
capysara → created an issue.
capysara → created an issue.
what service you needed to inject
It was my custom service. Nothing reusable for others.
Thanks for the quick turnaround! I really appreciate it.
Possibly phpstan was calling out because some of the namespaces were missing the backslash and interpreted as relative to the context of the module's namespace? When I extended the __construct method in my batch script, the ones without it were flagged in drupal-check, for example,
Parameter $state of method Drupal\mymodule\cbo_scripts\LocationsBatchScript::__construct() has invalid type Drupal\codit_batch_operations\Drupal\Core\State\State.
Added a MR to remove the "final" to allow overrides.
capysara → created an issue.
I created a MR. There's a @todo comment in there because I haven't use comments, so I'm not sure what the data looks like.
Thanks for updating!
I was hoping for some confirmation that what I described in the Summary was the right way. I'll go ahead and write up my notes and make a MR, and we can go from there.
capysara → created an issue.
I tried the Sync Metadata from /admin/content/media again, and this time it seemed to fix it. Is it possible that the first time I tried it there wasn't enough time between updating in Dam and trying to sync in Drupal? If that's the case, is there any way to make it fail more gracefully?
capysara → created an issue.
volkswagenchick → credited capysara → .
volkswagenchick → credited capysara → .
volkswagenchick → credited capysara → .
Added MR with documentation update.
capysara → created an issue.
capysara → created an issue.
Thanks for taking a look!
I think that there's something in my custom theme that's interfering, but I'm not sure what yet. If it turns out that it's just me, then I will close out this ticket. If I find that I have some edge case with this module, then I'll update with steps to reproduce.
capysara → changed the visibility of the branch 3507808-anchor-mapping-in-embedcodeurlbuilder to hidden.
capysara → changed the visibility of the branch 3507808-undefined-array-key to hidden.
Added a MR with proposed changes.
capysara → created an issue.
volkswagenchick → credited capysara → .
Added MR with the proposed change.
capysara → created an issue.
Works with Facets 3.0.0, so I'm marking as RTBC.
Also, closed duplicate https://www.drupal.org/project/jsonapi_search_api/issues/3487310 🐛 TypeError: reset(): Argument #1 ($array) must be of type array, false given in reset() Active because we came to the same conclusion in that issue.
I'm closing this one as a duplicate of https://www.drupal.org/project/jsonapi_search_api/issues/3403954 🐛 Adept to the new empty results empty facet behaviour of facets Needs review which was created earlier and applies the same update.
capysara → created an issue.
The patch (which is the same code as the MR against 11) applies to Drupal 10.4.1, but I'm still getting the same error message.
The "Allow almost any HTML" is showing html on a body field, but it isn't displaying the same on the Search: Excerpt field. Is there specific configuration I need for the Excerpt field?
I didn't make any changes to MR 32 or the patch in #19 (which is the same as the MR), but I rebased the MR to address the conflicts. I'm hiding the branch and the extra MR so that work can continue in 32.
capysara → changed the visibility of the branch 8.x-1.x to hidden.
Added MR with proposed solution.
capysara → created an issue.
capysara → changed the visibility of the branch 3240928-getpathnames-conflates-cache-11.1.x to hidden.
capysara → changed the visibility of the branch 3240928-getpathnames-conflates-cache to hidden.
baluertl → credited capysara → .
capysara → changed the visibility of the branch 10.3.x to hidden.
capysara → changed the visibility of the branch 11.1.x to hidden.
capysara → made their first commit to this issue’s fork.
I manually tested and can confirm this patch resolves the issue described. Tested on a clean install with easy_breadcrumb 2.x and core standard install 10.3.7-dev.
* Create a basic page, with title Page 1 and alias `/test`
* View page and confirm breadcrumbs are Home -> Page 1
* Update easy_breadcrumbs config—add Paths to replace with custom breadcrumbs: `/test :: Capybara | /test`
* Confirm breadcrumbs are unchanged
* Apply patch and clear cache
* Confirm breadcrumbs now correctly display Home -> Capybara
Without patch:
With patch:
I tried creating a MR against 1.0, but it didn't work out so I'm hiding the branch I created and setting back to Needs Work.
capysara → changed the visibility of the branch 3447628-load-the-config to active.
capysara → changed the visibility of the branch 3447628-load-the-config-1.0 to hidden.
Created MR against 1.1.x
capysara → changed the visibility of the branch 3377497-add-embed-code to hidden.
capysara → made their first commit to this issue’s fork.
Created MR against 1.0.x. I haven't reviewed this; I just moved the changes to the other branch, so I'm setting back to Active.
capysara → changed the visibility of the branch 3447628-load-the-config to hidden.
capysara → made their first commit to this issue’s fork.
Created MR against 1.0.x.
capysara → changed the visibility of the branch 3476119-3476119-fix-integration-link-1.0 to hidden.
Created MR against 1.0.x.
capysara → changed the visibility of the branch 3471261-missing-integration-links to hidden.
capysara → changed the visibility of the branch asset-id-missing-integration-link-3471261 to hidden.
If you're looking for a views filter, you can add an exposed filter for Property Value, set Property path from incoming object to "ff". That gives you a text field that you can search for the File Format. I've added one to my acquia_dam_asset_library view, to the Widget display so it displays in the media library modal. Note: the filter Operator says, "Is equal to" but it works like a "Contains" filter.
It pulls remote data from DAM's Asset Digest. Asset info->File info->Format. I believe that this file format data is automatically added on upload, see the File info section.
alexpott → credited capysara → .
Created a MR against 3.0.x and hiding earlier branches and the patch.
I didn't make any changes to the MR except to reroll it.
capysara → changed the visibility of the branch 3270462-conditional-fields to hidden.
capysara → changed the visibility of the branch 3.0.x to hidden.
capysara → changed the visibility of the branch 3365161-publish-status-and-patch-3ac7 to hidden.
capysara → changed the visibility of the branch 3.0.x to hidden.
capysara → changed the visibility of the branch 3365161-publish-status-and to hidden.
capysara → made their first commit to this issue’s fork.
As a patch, the MR works and it also applies to the latest 3.0.3.
However, I'm not sure if this is a complete solution because, in my case, it was misleading. Maybe an edge case, but somehow I had a node had been previously been saved without a value in the publish_state field. In the UI, it visually showed the default Publish State: Published, and since the node had already been saved and I thought that the validation prevented it from being saved without publish_state having a value, I assumed that the value was selected when it was actually empty.
In 3312463 → , it was reported that it's possible to save publish state as empty or none, but I haven't been able to intentionally recreate that behavior.
If you have entities with publish state's that are unintentionally null or none, then those are actually errors that need to be fixed. With this patch, scheduling just fails silently. I know 100s of logged messages isn't ideal, but how would we distinguish between
@cballenar What permission configuration gets "a user that has no publishing rights. User creates record, saved with status of Draft, a Publish On value, but no Publish Status"?
Create a MR against 3.0.x based on the patch in #22.
Also hiding the patches so that work can continue in the MR.
Still needs work as tests are failing.
capysara → made their first commit to this issue’s fork.
Rebased against the most recent 2.x and added some phpcs fixes.
I'm also hiding the patches on this issue so that work continues on the MR. I know that people still need patches, but it's confusing when there are both MRs and patches. Individuals can generate their own based off the diff of the current MR.