joseph.olstad → created an issue.
Ok NOT reverting
https://www.drupal.org/pift-ci-job/2891957 →
the jenkins CI tests are passing, the gitlab-ci tests are failing
There's something else going on here.
reverting this fixes all the tests!
ok, same patch for ctools latest tagged releases for both 8.x-3.x and 4.1.x
I checked, the new patch rolls cleanly for both branches
The same patch rolls cleanly for the head of 8.x-3.x
3.x also needs this
Ooops, wow, wxt is using ctools 3.x, oops, I'll roll a new patch for 3.x
should be good.
Patch for 4.1.x is here:
https://git.drupalcode.org/project/ctools/-/merge_requests/65.diff
Or, just use this:
https://www.drupal.org/files/issues/2024-06-14/ctools-entity_field_rende... →
joseph.olstad → changed the visibility of the branch 2924356-block-entityfield-renders to hidden.
joseph.olstad → changed the visibility of the branch 2924356-block-entityfield-renders to hidden.
joseph.olstad → changed the visibility of the branch 2924356-field-renders-twice to hidden.
rolling again sec
@kevin.brunner, until this is integrated into wxt, you can get around this problem by correctly adding a patches ignore entry to the
patches-ignore section of the composer.json
it is drupalwxt:
followed by drupal/ctools with the exact string to the broken patch
then add the newly rerolled patch → to replace it in the patches section.
patch needed a reroll
joseph.olstad → created an issue.
Drupal\Tests\file_entity\Functional\FileEntityReplaceTest 0 passes 1 exceptions
FATAL Drupal\Tests\file_entity\Functional\FileEntityReplaceTest: test runner returned a non-zero error code (2).
Drupal\Tests\file_entity\Functional\FileEntityReplaceTest 0 passes 1 fails
Drupal\Tests\file_entity\Functional\FileEntityFileTypeClassi 0 passes 1 exceptions
FATAL Drupal\Tests\file_entity\Functional\FileEntityFileTypeClassificationTest: test runner returned a non-zero error code (2).
Drupal\Tests\file_entity\Functional\FileEntityFileTypeClassi 0 passes 1 fails
Drupal\Tests\file_entity\Functional\FileEntityEditTest 0 passes 1 exceptions
FATAL Drupal\Tests\file_entity\Functional\FileEntityEditTest: test runner returned a non-zero error code (2).
Drupal\Tests\file_entity\Functional\FileEntityEditTest 0 passes 1 fails
Drupal\Tests\file_entity\Functional\FileEntityCreationTest 0 passes 1 exceptions
FATAL Drupal\Tests\file_entity\Functional\FileEntityCreationTest: test runner returned a non-zero error code (2).
Drupal\Tests\file_entity\Functional\FileEntityCreationTest 0 passes 1 fails
Drupal\Tests\file_entity\Functional\FileEntityTypeTest 0 passes 1 exceptions
FATAL Drupal\Tests\file_entity\Functional\FileEntityTypeTest: test runner returned a non-zero error code (2).
Drupal\Tests\file_entity\Functional\FileEntityTypeTest 0 passes 1 fails hmm, that commit appears to have broken a bunch of tests
see the pipeline
https://git.drupalcode.org/project/file_entity/-/jobs/1535866
committed to 8.x-3.x-dev
Thanks for the great work on this!
still critical, until this is fixed, use the "Scheduled Transitions" module instead
@neptune-dc , save yourself a lot of trouble, switch to the scheduled_transitions module instead
lightning_scheduler has some serious performance bugs , your site performance will gradually get worse over time if you keep this module installed, it reprocesses all previously processed revisions going back to the EPOC time, January 1st 1970, if you can imagine what this does to performance, think twice about using this module. Scheduled Transitions actually works! and doesn't have performance and scalability bugs. Scheduled Transitions actually works with translations also
I got through to Hasitha via LinkedIn, but he hasn't yet added me as co-maintainer.
Fixed in 1.0.58 see change record
Removing it from safedelete
spun it into https://drupal.org/project/access_unpublished_linked_nodes
ok @apadermo,
Understood
With that said, this module needs to be upgraded to Drupal 10 asap so that the rector can work on the Drupal 11 compatibility.
Currently it's Drupal 9 only and also doesn't work with oauth2 unless using my merge request which modernizes the project.
I believe Drupal 11 is to be released shortly.
update bot struggling here
@apadermo, this has been dragging on for approximately 3 years.
Check your own comment over 1 year ago:
https://www.drupal.org/project/azure_key_vault/issues/3230373#comment-14...
✨
Add restore and purge features for Azure secrets and keys
Active
Please consider expediting!
It's been 17 days without a response from the first message. I also sent him a text message to his phone number from his website.
website:
https://ozwebapps.com.au/
his phone number is there.
I also just sent him a message on facebook and linked-in
He appears to be more of a microsoft azure employee /consultant than a Drupal developer. Has been unable to contact every possible way to reach out has been attempted.
Timezone is Australia, Sydney Australia, he's in a city near Sydney Australia .
Rolled a patch for 10.2.5 from merge request 6038
clean for 10.2.5
@leymannx, that looks like an accurate reroll. I'm not sure if I understand what the implications are with the @guignonv suggestions in comment #32 .
Unfortunately, my client ran out of budget to pay me to work on this so I have no time to dig hard back into this for now.
It's been 17 days, no response, multiple attempts to reach the maintainer.
Same fix also applies to the 2.x branch
patch #11 is the one we've been using for years.
patch #18 and #21 failed phpstan, both of these patches are a bit tough on the eyes.
patch #11 passes tests, it's a one line fix.
6 years now and counting.
Existing test coverage should ensure that this doesn't cause regression.
It's been 6 years without test coverage. Would be good to fix this.
works well for over 6 years running
The designated 404 page can be any route, but can be a node, in many cases it would be expected to have complex content such as an image with a person shrugging their shoulders and looking up.
Nodes can be 404 pages
this is what our patch above deals with.
the designated 404 page is configured here: /admin/config/system/site-information
if it's a node, we should use the body field data , and load the expected translation value also.
I looked over the other issue:
✨
Make the 404 page more configurable
Needs work
It is not a duplicate from what I can see. Doesn't get the configured 404 page node body field value for all active languages.
joseph.olstad → created an issue.
This is still needed and very soon we will also need Drupal 11 compatibility.
This seems to be working for us so far, see merge request 3 above
@ozwebapps, are you still able to review the
🌱
Offer to maintain azure_key_vault
Needs review
Or have you actually won the lottery?
I've brought this project back from deprecation.
On friday it will have been 14 full days passed without a response from the maintainer after I contacted him offering to co-maintain. This was after more than a month of pushing up commits in issues and commenting on several important issues.
It appears that the original author/owner/maintainer of this project has won the lottery!
joseph.olstad → created an issue.
joseph.olstad → created an issue.
bump
4 days to go
The related changes that were made pertaining to media entities are in this issue:
I'll mark this as fixed for the first part, good enough.
ya it would be nice to have a configuration on/off option for the TOC. With that said, I'd imagine that will want it.
Sorry I haven't had any more time to work on this, it's working with the latest Merge request 6.
seems like a good change but I haven't had a chance to test this.
So @sourojeetpaul, you tested this and it's good?
fixed in 3.0.x dev
Thanks!
ok it's mergeable now
ongoing performance work trying to get MySQL 8 to perform fast in Azure has not yet been fruitful. Have cranked up IOPS as high as they go, cranked up the cost of the instance to 16000$ per month or more , still slow, cranked up memory, cpu cores, filesystem options, still slow as molasses.
Yet when testing a db instance on a 200$ option with MariaDB in azure, it's nearly 3x faster than anything we've gotten out of Azure+MySQL 8.
Awesome work on this! Very important milestone!
marking as RTBC,
Please find the maintainers on the project page → , click on their avatar, then look for the contact tab, send a friendly message of appreciation for this module along with a hyperlink to this issue requesting for the tagged release.
These same maintainers are likely in the Drupal slack, I suggest a friendly ping on there also.
Nicely done, thanks!
This should work:
composer require 'drupal/panels:^4.8@RC'
I'd stick to this ^ just in case. It should work fine on future rc releases and future minors.
joseph.olstad → changed the visibility of the branch 3338959- to hidden.
joseph.olstad → changed the visibility of the branch 3338959- to hidden.
Sorry I'm unable to test this but hopeful that it works for the 3.0.x branch.
Needs review/testing
This isn't fixed IMHO until the GUI gets the improvement. Otherwise very confusing for any editor scratching their heads.
I have not tested this latest merge request.