Attached is a patch to implement the pagination.
khaled.zaidan → created an issue.
It would be very helpful if someone could review this patch.
Here's a simple patch to do the alternative approach I mentioned. This might be enough on its own!
I'm thinking something along the lines of:
1. User manually sets a derivatives static directory in the files folder. E.g. staticDirs: ['../web/sites/default/files/storybook-derivatives']
2. When rendering the story (in storybook's route), we make the code check for any image derivatives.
3. Any image derivatives found, we first make ensure the derivative is generated and make a copy to the storybook derivatives dir.
4. Then modify the markup to the image derivatives point their paths to the new copies we've created
5. This could all be configured/enabled/disabled through the module configs, so it can accommodate different builds as needed.
Setting staticDirs to your web root still isn't ideal, as this means if you try to push storybook to Chromatic, it will attempt to push your entire website (which Chromatic won't allow).
I would be nice to have something to dynamically push image derivatives and/or change image paths before the render to story book. That way you can target the exact asset files you need.
I've only just run into this now, so I'm not sure what the best solution is or whether someone has already figured it out. I'll update here if I come across a better approach.
Here's a patch that does the proposed solution above.
khaled.zaidan → created an issue.
Here's a patch to make this functionality available.
It adds weights to profile types and makes them draggable, similar to vocabularies and taxonomy terms in core.
Patch for the suggested feature.
khaled.zaidan → created an issue.
I've found that there's no actual need for the conditional in the patch in #8?
We always want to retain the publish on date for the other translations. We also need the same logic for unpublishing.
However, we should add a check on whether the fields are translatable.
Here's a patch that makes those changes.
lussoluca → credited khaled.zaidan → .
Patch attached.
khaled.zaidan → created an issue.
Attaching a fresh patch that applies against 8.x-3.6.
And another patch for v2.3.x
Updated patch!
I'm realising that I forgot to update the config in the module. I'll amend that shortly.
Here's an initial patch of the feature suggested above.
Adds both options mentioned. If "Restrict transitions that can be scheduled" is ticked, then the user is able to select from all transitions for all entity-types/bundles which ones to allow.
khaled.zaidan → created an issue.
@mageshbcet1 and @gilmar.lima, is the label bit still an issue?
I was looking to get this patch over the line, but I just tested now and the latest (draft) label seems to get loaded correctly.
Could you please confirm whether it's still happening? If so, could you please provide some details how to replicate?
I've tried with the referenced entity being a regular node and a paragraph library item (regular paragraph fields don't have an editable label... do they?), in both cases, the draft title was used as label in the edit form.
Patch for the fix suggested.
khaled.zaidan → created an issue.
Worked for me.
Just found that the patch in #2 didn't handle empty values properly, as the service would convert them to an empty string rather than a NULL or an empty array.
Fixed now in the attached patch.
Attached is a patch to the proposed solution.
khaled.zaidan → created an issue.
Attaching patch for fix.
khaled.zaidan → created an issue.
Sorry, patch had a bunch of unrelated gibberish in it.
Re-uploading.
Not a complete implementation by any means, but a small patch to get things rolling maybe?
It adds a plugin for the Geopoint field type in Typesense. It works with the geofield module (at least just for indexing the data).
Attaching patch for propose fix.
khaled.zaidan → created an issue.
Attaching patch for suggested fix.
khaled.zaidan → created an issue.
Yeah, I just spotted this issue now, as well.
I think it's worth implementing hook_update_N() to remove the permission with the next release.
Code is simple (I just haven't yet gotten the hang of GitLab :( ).
/**
* Remove the non-existent 'access pwa' permission from the anonymous user role.
*/
function pwa_update_8002() {
user_role_revoke_permissions(RoleInterface::ANONYMOUS_ID, ['access pwa']);
}