jeffreysmattson → created an issue.
JeffMattson → created an issue.
JeffMattson → created an issue.
JeffMattson → created an issue.
This has been re-based and tests are passing.
I have re-based and test are passing. Success!
I have updated the MR to point to 11.x
Yes! The patch on Comment #141 works for 10.2.4. Thank you!
@Sam152 and @pacproduct, Your solutions worked for me on D7 -> D10, thanks for posting. Never would have made it there without you. :-)
Thank you for your work on this patch, however it no longer applies for me on Drupal 10.2.4. Using:
https://git.drupalcode.org/project/drupal/-/merge_requests/4178.diff
I have created a feature request here:
https://www.drupal.org/project/drupalorg/issues/3427360 ✨ Missing the ability to search forums on Drupal.org Active
Thanks for your help.
JeffMattson → created an issue.
I think I did it. Thank you for that git command that made all the difference. Looks like the unit tests are failing. Is that from my code or is that a problem in the branch itself? Thank you for your help on this one.
Thank you. I new about site: but never thought to use it on Drupal.org. That will be incredibly helpful in the future. I had googled a topic and ended up on a results page that did not have the search field in the side bar. Just a list of posts and paging links at the bottom of the page. Only when I visited the forum from another link inside of the Drupal site did the search form appear.
Just did a quick check and neither of these pages have a search bar. Just paging...
https://www.drupal.org/forum/support/converting-to-drupal →
https://www.drupal.org/forum →
After struggling to get the twig debugger to work on a site after doing all the above and setting the `/admin/config/development/settings` twig debug which is now required but not mentioned often, I discovered that when you have the `Source HTML Minified` checked here:
`/admin/config/development/performance` the twig debug statements will not show. This seems like a 'duh' moment. When inspecting the page with Firefox it shows the html as 'Beautified' even though it is 'Minified' so you don't actually know that all those comments are being stripped out. Happy theming now!
I would change branches but for whatever reason the branch 1.1.x is not found in this fork so I can't change to it. I would really like to figure out how to do this successfully but hit road block after road block. Should I clone the original repo `entity_share_websub`, I can see the 1.1.x branch there, but my issue branch is not. The two things are not in the same place.
I have tried to figure out how to rebase this onto 1.1.x but still am unable to. I cannot fetch the 1.1.x branch because it is not available to me for some reason.
MacBook-Pro-100:entity_share_websub-3344319 f002bw2$ git fetch entity_share_websub-3344319
From git.drupal.org:issue/entity_share_websub-3344319
* [new branch] 1.0.x -> entity_share_websub-3344319/1.0.x
* [new branch] 2.x -> entity_share_websub-3344319/2.x
* [new branch] 3344319-need-to-create -> entity_share_websub-3344319/3344319-need-to-create
* [new branch] issue-3287314 -> entity_share_websub-3344319/issue-3287314These are all that are available. I am able to rebase onto 2.x, but that doesn't seem to help here. I am not sure what I am doing wrong.
In the gitlab page here: https://git.drupalcode.org/issue/entity_share_websub-3344319/-/tree/3344...
In the "Select Git revision" dropdown 1.1.x is not listed.
What am I doing wrong?
I updated the MR to apply to the 1.1.x branch. It looks like rebasing isn't necessary. Am I wrong?
I am running into this error now using version: Entity Share Websub '1.1.0' and Entity Share version: '8.x-3.0'. When I don't have a field enhancer set for the field "behavior_settings I get this error:
The generic FieldItemNormalizer cannot denormalize string values for "value" properties of the "behavior_settings" field (field item class: Drupal\Core\Field\Plugin\Field\FieldType\StringLongItem).
When I enable the Serialized Data (Entity Share) field enhancer to the field, I get this error:
Cannot synchronize item 377c680c-3fba-47af-82c9-fe09f12272d0 from channel articles of remote home_site using demo_import.
When I look at the JSON endpoint that is returning the paragraph, I see that in the "behavior_settings" field is the string "Array".
This thread looks like it resolved this issue, but I am not sure how to implement the solution as it isn't explained. Is this a new error or am I applying the fix incorrectly?
This patch wont apply to current 2.0.x-dev version. When viewing the MR the page throws an error and comments and MR not viewable. How do we move forward with this?
jeffmattson → made their first commit to this issue’s fork.
jeffreysmattson → created an issue.
I am unable to fetch the 1.1.x branch to rebase. I don't quite know why it doesn't work. The only way I seem to be able to get the 1.1.x branch is by creating a new issue. What am I doing wrong here? I am in a bit of a time crunch and might just have to create another issue to get this to work.
jeffreysmattson → created an issue.
I apologize for all the mess here. I am trying to figure out how to fork it from the 1.1.x branch but gitlab does seem to have that branch available for me. Do I have to start a completely new issue to do that?
This patch no longer applies to v1.21. The release did not include these changes so the error is back and can't be patched. I see the fix has been merged but not released. This ticket should not be closed maybe? What is the correct path to solve this issue?
jeffreysmattson → made their first commit to this issue’s fork.
jeffreysmattson → created an issue.
After three weeks of banging our heads against the wall. With seemingly random site crashes that occurred only in production. With errors like this:
notice Uncaught PHP Exception Drupal\Core\Field\FieldException: "Attempted to create an instance
of field with name field_last_password_reset on entity type user when the field storage does not exist."
at {redacted}docroot/core/modules/field/src/Entity/FieldConfig.php line 315 These errors were not only for the field_last_password_reset. They would error on all kinds of different fields that didn't have field storage, but actually did have field storage.
The site would become unavailable and a simple cache clear would resolve it... until a few hours later it would go down again.
This fixed it. Thank you!
I used #15 because we are still on Drupal 9.
It looks like the brokenness could be fixed in 2.x-dev. The code in this area has changed a lot. In my particular situation, I cannot risk running a dev release. I have created a patch for my situation and will wait until the next release.
Thank you!
I uploaded the simple patch to get the alternative title field to display. Sorry if this is not the way to do this here. I don't see any way to create a patch for the release of 2.0.5.
I wanted to create a patch since line 525 of EasyBreadCrumbBuilder.php overwrites the alternative title with the entity label.
But the 2.x-dev branch has already overwritten that part, so I can't.
How can I create a patch for 2.0.5 to fix this?
Devnado → created an issue.
Yes it is. Thank you.
jeffreysmattson → made their first commit to this issue’s fork.
Thanks for your comment @joachim. I don't understand it. I added that line, should I have added it somewhere else?
jeffreysmattson → made their first commit to this issue’s fork.
jeffreysmattson → made their first commit to this issue’s fork.
jeffreysmattson → created an issue.