🇮🇹Italy @mxt

I also tried to set these default drupal settings just to see if this can help:

$settings['file_additional_public_schemes'] = ['protected'];
$settings['file_sa_core_2023_005_schemes'] = ['protected'];

But the problem is still there...

Just to do a test, I tried to setup the default Drupal $settings['file_private_path'] stuff with a path similar to the one setted for $settings['protected_download_file_path_protected'] (so both dirs are at the same level), and this works fine: image styles are correctly created, and images are visible in the node.

So it seems that there is something wrong with paths or the custom stream wrapper implemented by this module.

mxt → created an issue.

Do I have to create a custom token where I load the node and pass it...

Yes, this seems like the correct approach: I created a custom "global" token that returns the specific node object containing the protected images everywhere, to which you can then append the protected_download specific tokens, something like this:

file:protected-download-url token:
[my-global-token-type:my-specific-node:field_images:0:entity:protected-download-url]

file:protected-download-expire token:
[my-global-token-type:my-specific-node:field_images:0:entity:protected-download-expire]

And you can put above tokens wherever you want, including the email automatically sent after each newsletter subscription.

One thing I still have to figure out is how to set a custom expiration date, because the one printed by the token seems to be predefined and I haven't yet found a way to change it at will (but this will eventually be the subject of another issue)

MXT → created an issue.

Tried today: the problem is still there.

Yes it seems that above settings works: images are saved withing protected-files folder, and these are rendered in the node I attached them with this html:

<img loading="lazy" src="/protected-download/protected/66b55c00/w9-l6MXrPA8jWOS6UE8ZOgPGwiwqZaunaCOSGAjjfo0/2024-08/my-image.jpg" width="4000" height="3000" alt="alt-text">

And these are not rendered in the node itself (and also in its edit admin ui) because such src triggers a 404 error.

Now I'm trying to understand HOW I can generate a working url to such images to be used in an email...

Do you have any suggestion?

I suppose it could be something like this:

$settings['protected_download_file_path_protected'] = '/my/hmac/filesystem/path';

(to be placed in settings.php)

Can the HMAC path be setted in settings.php for example?

Sorry I'm not sure I understood correctly: can this module be used on D10 without an administration page or is it mandatory for it to work?

Any news on this?

My use case: send a custom email every time a user completes the subscription process for a newsletter.

Thank you!

Any news on this?

Thank you

This does not work anymore in D10 version.

After adding % symbol, the widget keeps it, but then if you save the whole page display settings, the % is removed from value.

@athyamvidyasagar there is already a working patch (see #87 📌 Olivero: Center align content (instead of left align) Needs work ) that is much more advanced and takes into account many other aspects than yours, which is too simple.

Please before posting a patch be sure to read the whole thread and check the work already done by others first, thank you (this is the second time 📌 Olivero: Center align content (instead of left align) Needs work I say this in this thread)

In case you (or someone else) want to contribute to the conclusion of this work, what is missing to do is written in comment #88 📌 Olivero: Center align content (instead of left align) Needs work

Thank you.

For those wishing to test the above implementation, the related patch can be created by clicking on plain diff in the "Issue fork" box at the beginning of this thread.

I reproduce the current link here for convenience:

Plain diff to be applied as a patch

AAAHHH!!! Thank you very much @ressa!!!

So with my:

Probably, as often happens, it may be that the failure of the backend test is due to something really trivial, but which I haven't been able to see yet...

I was absolutely right! ;-D

And yes: this is the demonstration that with the right tools, the goal can be reached sooner and better: I didn't know about this Lando + Drupal Contributions: I absolutely have to find the time to try it.

Thank you for the tip @ressa, much appreciated!

Guys, this is getting absurd: I spent more time trying to fix the failing test than implementing the new feature that allows Olivero to be centered.

The beauty is that the test that fails on the backend, has nothing to do with the frontend functionality that works great, as confirmed by others above, so much so that we are using it successfully on an upcoming site (can't share the demo as it is not yet officially public).

The most absurd thing is that the element that the test is looking for exists because moveToElement does not fail, while the waitFor ElementPresent/Visible in the next line continues to fail. So, first it finds it and then it doesn't find it anymore?

Anyway I don't want to insist on this anymore, first to avoid spamming this thread with various attempts to fix the test, due to the fact that I'm basically working "blind", as the Nightwatch tests don't produce screenshots so that I can visually see where the problem is, and don't even run correctly on DrupalPod (I run them using $ddev nightwatch --tag olivero, but it doesn't work correctly: do you know a better way?). I tried to use DrupalPod because I still couldn't get Nightwatch to run correctly in my usual "docker4drupal" based local environment...

Probably, as often happens, it may be that the failure of the backend test is due to something really trivial, but which I haven't been able to see yet...

At this point I'm asking you all, and in particular Olivero's maintainer, for a suggestion on how best to proceed in this situation.

Thank you.

Thank you @Bhanu951,

I used DrupalPod → , and at the end I was able to create a new working branch based on 10.1.x in the (old) pre-existing issue fork following your suggestions.

In particular, using DrupalPod, I had to:

1. Start a DrupalPod session WITHOUT selecting an existing branch (so 10.1.x was automatically chosen)
2. Remove existing remote
3. Add new drupal-123456 remote
4. Create 123456-issue-short-description-10.1.x branch
5. Make/commit changes
6. Push the new branch
7. The new 123456-issue-short-description-10.1.x branch is now listed under the issue fork branches in the issue itself

Thank you.

Encountered the same issue trying to work on #3156754

I reread this tons of times:

I recommend branching in your local checkout and pushing from there. That way you can update 10.1.x from the canonical drupal project, which you can keep at the origin Git remote. Then branch from there and push to the issue fork’s Git remote.

but I just don't understand what I should do, sorry...

Can you please write down a crystal clear step by step guide for dummies where nothing is given for granted?

I really would like to contribute to Drupal...

(I also think that this should be "officially" documented somewhere, in the issue forks guide maybe? Or, better, it would be nice to have a feature somewhere that easily allows to fetch updates from the issue fork itself)