I like this idea. The issue with relying on meta tags is that a lot of sites won't use them. I wonder if we could leverage Puppeteer to grab a screenshot of the webpage and save it as a file, but I believe this requires having node.js.
Here's the documentation for when I come back to this:
https://pptr.dev/guides/screenshots
This isn't going to be straightforward but it's a really good idea that I'd definitely like to look into.
This feature request has been captured in a duplicate ticket: https://www.drupal.org/project/media_entity_link/issues/3244504 ✨ Ideas for module: capture screenshot, store page info Active .
Closing as a duplicate.
As vladimiraus seems absent and danrod has opened another issue I will move this to closed (outdated).
2.0.4 released with support for PHP 8.1 and 8.2 reinstated.
Never mind. I think I was just using the wrong variable in the gitlab-ci template.
Just tried this and the runner was hanging. Looked here:
https://www.drupal.org/docs/getting-started/system-requirements/php-requ... →
Drupal 11 only supports PHP >= 8.3.
Perhaps we should have two releases - one for Drupal 11+ and one for Drupal 9/10? Ideally we'd avoid having two points of maintenance for this module though as I'm currently the only active maintainer!
Whoops!! Sorry. I'll get on this!
I have referenced this issue here:
https://www.drupal.org/project/projectownership/issues/3514042#comment-1...
💬
Offering to co-maintain Media Entity Link
Active
Cross referencing these two issues:
https://www.drupal.org/project/media_entity_link/issues/3504411
💬
Offering to co-maintain Media Entity Link
Active
https://www.drupal.org/project/media_entity_link/issues/3520583
💬
Offering to co-maintain Media Entity Link as well
Active
where danrod: https://www.drupal.org/u/danrod → has also offered to be a co-maintainer
As I am not the project owner I am unable to add further maintainers to the project.
Hi. I know you're busy working on this. Is there any update on getting Drupal 11 support into a stable release?
Any update on a stable release for this? I opened this issue: https://www.drupal.org/project/country_path/issues/3508079 📌 Drupal 11 release RTBC which got closed with a message saying a release was planned for the end of March? Thanks.
Fixed on 2.0.3.
Have managed to reproduce this. The field storage is left orphaned. However would that not be the desired behavior if the field has been used on another media type? I created a new media type called "another_link" and then uninstalled the module. My new media type "another_link" was removed when the module was uninstalled which I'd argue is perhaps not desirable.
My question is what do we expect to happen when the module is uninstalled?
- Any media type using the field.storage.media.field_media_entity_link should be deleted along with the field storage?
- A check should be performed to see if any other media types are using the field storage and if so do not delete the field storage or any media types that are using it except for the one provided by the media_entity_link module?
I'm going to set this as maintainer needs more info until we can reach a consensus on what the correct behavior should be!
I've tested this on a clean install and it looks good!
Fixed on the dev branch. Please feel free to test and report back and I'll tag a release!
Not getting anywhere with this one. Tests are not my strong point so setting to Needs Work! Anyone who has a deeper knowledge, feel free to duck in!
@danrod this is fine with me. I think the more maintainers the better so this module doesn't become stale again. I'm only assigned the developer role though which means I can't add maintainers I believe so you might need to create another issue like this one so that @avpaderno can assign you as a developer also, or perhaps we can avoid the waiting times and get you added now? Either way I'm of the opinion that more maintainers is better for the longevity of this module!
Done!!
All done!
Pleased to say this is finally fixed and released!
Thank you.
Hopefully happening soon over here:
https://www.drupal.org/project/projectownership/issues/3514042
💬
Offering to co-maintain Media Entity Link
Active
Leaving open (fixed) as per bot's recommendation.
Thank you bot! Merged.
Yes!
darren.fisher → changed the visibility of the branch 2842405-hide-empty-langcode-wrapper to hidden.
darren.fisher → changed the visibility of the branch 2842405-empty-language-langcode to active.
darren.fisher → changed the visibility of the branch 2842405-empty-language-langcode to hidden.
Thank you. And that takes us to the first full release 1.0.0!!
Tested and added another fix to 1.0.x for tp_select_data(). Let me know if all looks good to you and I'll close this and tag a new release.
Thank you @priscarabelli. This was sat on my to do list. I've added a test to cover this and updated the readme and implemented this in to the menu, select, and table functions so that full stops don't come out when using these twig functions. I've merged to 1.0.x if you want to test it works for you? Will tag a release once we've had a change to test the dev branch.
Thank you so much! I really appreciate your review.
Cross referencing this issue: https://www.drupal.org/project/projectapplications/issues/3485070 📌 [1.0.x] Twig casings Active where I have applied for the ability to opt projects into security advisory coverage which will likely be required in order to become a maintainer of this module.
Tagged and released. Thanks everyone.
Just popping back and marking this as needs review again.
I've recently created another module which contains more PHP than this one. See: https://www.drupal.org/project/twig_placeholders →
I've been following all the standards and hopefully this will give you a better idea of my capabilities. I've been working with Drupal for over 10 years professionally for a variety of enterprise organisations and am now looking to be more involved in the contrib space and being able to opt projects in to security advisory coverage will be a major step. For example I have an application open to maintain / co-maintain an abandoned module: https://www.drupal.org/project/projectownership/issues/3514042 💬 Offering to co-maintain Media Entity Link Active and have recently become a co-maintainer on the nodeaccess project https://www.drupal.org/project/nodeaccess → .
In addition to this I've also added additional commits to the twig_casings project and intend to continue updating and supporting these modules for many years to come.
Marking fixed. Will tag a release once the tests are passing on 1.0.x
Thanks for testing the MR @priscarabelli!!
This looks good. Going to merge to dev and then fix the pipeline there as it's a bit easier for my workflow. I like the way the arguments work so happy to merge in as is.
darren.fisher → created an issue.
Added the lorem ipsum service to this. Something I've realised is that the lorem ipsum service assumes you want sentences and add full stops to the end of each generation so I will open a separate issue to deal with this and later implement it here.
This is looking really good. I've updated the README in this branch to document this new functionality and changed the default values in MenuDataExtension.php to match what is in the README.
Next steps:
- I'm going to look at using the lorem ipsum service to generate the menu titles.
- We'll want some tests similar to the other twig functions that cover the functionality provided by this new twig function.
darren.fisher → made their first commit to this issue’s fork.
It seems this may be unrelated to the previous issue. I will roll this patch in to a merge request so it's easier to review and test in the gitlab pipelines.
Is this related to https://www.drupal.org/project/twig_tweak/issues/3427835 ✨ Add possibility to placeholder menu renders Active ?
Also the PHPStan errors are weird. They all state:
No error to ignore is reported on line XX
Here's the full error output:
------ --------------------------------------------
Line src/Command/SignatureFormatter.php
------ --------------------------------------------
47 No error to ignore is reported on line 47.
------ --------------------------------------------
------ --------------------------------------------
Line src/UriExtractor.php
------ --------------------------------------------
49 No error to ignore is reported on line 49.
83 No error to ignore is reported on line 83.
------ --------------------------------------------
------ ---------------------------------------------
Line src/UrlExtractor.php
------ ---------------------------------------------
72 No error to ignore is reported on line 72.
112 No error to ignore is reported on line 112.
------ ---------------------------------------------
------ ---------------------------------------------
Line src/View/BlockViewBuilder.php
------ ---------------------------------------------
148 No error to ignore is reported on line 148.
------ ---------------------------------------------
[ERROR] Found 6 errors
When I inspect the first one I see:
// @todo Fix this.
// @phpstan-ignore-next-line
I'm not sure why these are here? I'm sure there is some reason but it appears the PHPStan would not error on the following line anyway so maybe these can be removed? Again seems like this is probably a separate issue?
Just fixed the phpcs errors introduced by these changes. The PHPUnit failures I'm unsure of the correct approach.
Line 32 of tests/src/Kernel/Command/DebugLoadersTest.php contains the following assertion:
self::assertStringContainsString('/twig_tweak/templates/', $display);
The test is asserting that the output must contain the string:
"/twig_tweak/templates/"
But the actual output is:
"modules/custom/twig_tweak-3427835/templates/"
I'm not sure if this needs some sort of partial string check update using regex as the -3427835 relates specifically to this issue branch which means phpunit will always fail on any branch. This feels like a separate issue altogether.
What do you think?
darren.fisher → made their first commit to this issue’s fork.
Thank you @guiu.rocafort.ferrer. Any update on the release?
The maintainer for this module has been unresponsive for some time and the module is currently in limbo. I would like to be considered as a maintainer so I can ensure this module stays up to date and has a regular release schedule! Thank you for your consideration.
Bumping this. Tomorrow this issue will be escalated to the Drupal.org project ownership issue queue.
Thanks for this. Merged and fixed! Will add tests for this new functionality on the 1.0.x branch so I can test thoroughly locally and then will tag a new release!
darren.fisher → made their first commit to this issue’s fork.
I think I've cracked it. Tests now pass. I must stress though I'm pretty new to the inner workings of this module so please can this be thoroughly reviewed and tested before being merged? The logic has had to be altered a fair bit from the patch for 1.x due to large changes in the module between branches!
New MR to resolve this issue in 2.x. Please test thoroughly!!
https://git.drupalcode.org/project/nodeaccess/-/merge_requests/18
There are PHPUnit errors. I will try and get to these shortly!
Also I believe all work is now taking place on the 2.0.x branch and as it is still an issue let's start there and if needed cherry pick the change to the 1.x branch although 1.x is no longer listed as a recommended version on Drupal.org.
I'm going to roll this in to a merge request so we can test it more thoroughly.
I'm not sure if this lies within the remit of the nodeaccess module? Can you provide some more information about your request and I can investigate if this issue belongs in another queue or does indeed fall under the remit of the nodeaccess module? Thank you.
Is this the same issue as:
https://www.drupal.org/project/nodeaccess/issues/3511078
🐛
Updating from 1.x to 2.0.1@alpha purges settings and grant field data
Active
If so we should also mark one of these as closed (duplicate).
Is this the same issue as:
https://www.drupal.org/project/nodeaccess/issues/3509391
💬
Upgrade to version 2 deletes existing permissions
Active
If so we should also mark one of these as closed (duplicate).
nodeaccess.settings.yml 1.x
grants:
view: 1
edit: 1
delete: 1
priority: 0
preserve: 1
nodeaccess.settings.yml 2.x
allowed_grant_operations:
grant_view: true
grant_update: true
grant_delete: true
bundles_roles_grants: {}
grants_tab_availability: {}
map_rid_gid: {}
roles_settings: {}
There is an update hook provided in nodeaccess.install:
https://git.drupalcode.org/project/nodeaccess/-/blob/2.0.x/nodeaccess.in...
/**
* Migrates nodeaccess.settings.
*/
function nodeaccess_update_9002(&$sandbox) {
$config = \Drupal::configFactory()->getEditable('nodeaccess.settings');
// From grants to allowed_grant_operations.
$old_grants = $config->get('grants');
$config
->set('allowed_grant_operations', [
'grant_view' => (boolean) $old_grants['view'],
'grant_update' => (boolean) $old_grants['edit'],
'grant_delete' => (boolean) $old_grants['delete'],
])
->clear('grants');
// From allowed_types to grants_tab_availability.
$old_allowed_types = $config->get('allowed_types') ?? [];
$grants_tab_availability = [];
foreach ($old_allowed_types as $bundle => $value) {
$grants_tab_availability[$bundle] = (boolean) $value;
}
$config
->set('grants_tab_availability', $grants_tab_availability)
->clear('allowed_types');
// From role_map to map_rid_gid.
$old_role_map = $config->get('role_map');
$config
->set('map_rid_gid', $old_role_map)
->clear('role_map');
// From role_alias to roles_settings.
$old_role_alias = $config->get('role_alias');
$roles_settings = [];
foreach ($old_role_alias as $role_id => $value) {
$roles_settings[$role_id] = [
'display_name' => $value['alias'],
'name' => $value['name'],
'weight' => (int) $value['weight'],
'selected' => (boolean) $value['allow'],
];
}
$config
->set('roles_settings', $roles_settings)
->clear('role_alias');
$bundles = array_keys($old_allowed_types);
$bundles_roles_grants = [];
foreach ($bundles as $bundle) {
$old_bundle_settings = $config->get($bundle);
foreach ($old_bundle_settings as $role_id => $grant) {
$bundles_roles_grants[$bundle][$role_id] = [
'grant_view' => (int) $grant['grant_view'],
'grant_update' => (int) $grant['grant_update'],
'grant_delete' => (int) $grant['grant_delete'],
];
}
$config->clear($bundle);
}
$config
->set('bundles_roles_grants', $bundles_roles_grants)
->clear('priority')
->clear('preserve')
->save();
}
Did you run drush updb / drush updatedb and drush cr / drush cache:rebuild?
Please let me know and I can investigate this further if you're still having issues?
Just coming along to update this issue. 2.0.x is now the default branch and is listed on the project page. This branch has not had a tagged release in over 2 years. Ideally we will tag a new release of this branch soon so that the module is Drupal 11 compatible and includes all the other good fixes that have been merged over the past 2+ years. This will also allow us to test all the open issues in the issue queue against a tagged release which will give us a new jumping off point for cleaning up the issue queue and getting some of these issues resolved once and for all!
I believe this issue to be outdated as Drupal 7 is now officially end of life. Please feel free to correct me if I'm wrong. I'm just trying to have a cleanup of the older issues in this issue queue!
I believe this issue to be outdated as Drupal 7 is now officially end of life. Please feel free to correct me if I'm wrong. I'm just trying to have a cleanup of the older issues in this issue queue!
This change has been committed to the dev branch as part of the Drupal 11 compatibility work: https://git.drupalcode.org/project/nodeaccess/-/merge_requests/16/diffs
Please test the 2.0.x-dev branch and report back if all is working as expected. I think we need as many eyes as possible on the dev branch in order to get a new tagged release!
I am marking this issue as fixed and giving you credit as your code contribution has been included in the dev branch as a fix!
darren.fisher → created an issue.
Fixed! Will tag a new release once merge train is complete!
Closing as fixed. Will tag a new release once https://www.drupal.org/project/twig_placeholders/issues/3516429 📌 Resolve PHPStan (next minor) issues Active is resolved.
Fixed!
darren.fisher → made their first commit to this issue’s fork.
darren.fisher → created an issue.
Closing as fixed. Will tag a new release once https://www.drupal.org/project/twig_placeholders/issues/3516379 🐛 {{ tp_video() }} Rendered HTML appears as escaped text instead of Active is resolved!
Closing as fixed. Will tag a new release once https://www.drupal.org/project/twig_placeholders/issues/3516379 🐛 {{ tp_video() }} Rendered HTML appears as escaped text instead of Active is resolved!
Fixed!
Merged!