🇪🇸Spain @omarlopesino

Created MR. A Review will be appreciated. I will merge it on Monday though, as it is stable.

omarlopesino → created an issue.

Released at beta9

It works perfect, thanks also for correcting most of styling errors reported by drupalci!

I've done some slight adjustments and I am merging it.

Thanks!

I've checked it and it works fine: for HTML it downloads a txt and for md it downloads a .md file. Plus, it solves a problem that was making the .txt extension added twice. Merged into 1.x, it will be released asap, thanks!

If it is easy, we could add a selector in the action plugin configuration form to choose between HTML or Markdown. My only concern is I don't remember if that configuration is global for all the selected elements, or is specific for each one. If it is global, go for it. Otherwise, only markdown.

Oh it was on my plans doing this but I haven't started yet, so contributions are welcome :)

If you are going to work on it, I expect that this feature works technically as follows:

- Do a Drupal Action Plugin to save the markdown generated by content_first.builder service into a temporary file.
- Allow this action to be enabled at /admin/content, so any content needing downloading can be selected.
- After doing the bulk operations, save all the files into a ZIP.
- Either display a Drupal message linking the generated file, or auto download it in the next page load.

This would be a "Drupal way" solution that would meet the requirement, otherwise it can become tricky I think.

beta8

The plan is developing it the next week and releasing it at beta7.

omarlopesino → created an issue.

Merged. I will create beta6 release with this.

For the moment , the solution will only provide the content first as markdown. That is because HTML output is sanitized in tokens and markdown should be enough.

omarlopesino → created an issue.

Merged! It will be released at beta 6

I have finished the refactor. I have checked it with a site using content first and the generated content appears equal, without regressions. I have checked: HTML, markdown, copy and download. This is ready to review.

omarlopesino → created an issue.

I've fixed the composer.json too. Waiting for tests to move to RTBC.

omarlopesino → made their first commit to this issue’s fork.

I've checked the code and I fixed it. Can you upgrade to 1.0.0-alpha5 and let me know if you have the same issue? Thanks!

Glad that you have fixed it! I think that the problem is that the module is still not stable. I'll try to release a stable version as soon as I can prioritize it.

Integrating with UI styles currently is not in our scope, but it could be good to considerate as UI styles integrates at entity bundle level and it is more abstracted from CSS variables.

Having said this, the MR has been reviewed so it has been merged.

Done.

This is ready to review

Coding style --> fixed
Use custom textarea to allow creating new variables -> Done
Consider validate if new variables are not the same than overriden variables -> I have added a validation to check new css variables have correct format, plus they do not conflict with the variables of the current selector.

Working on a first version that allow replacing global variables. They appear inside a fieldset, and for each one there is a textfield.

Preview:

Pending:

1. Coding style
2. Use custom textarea to allow creating new variables.
3. Consider validate if new variables are not the same than overriden variables.

omarlopesino → created an issue.

Re-rolled to 6.3.x

I've just re-rolled it to solve conflicts with 7.0.5

Postponed until:

• ✨ Add support for path-based invalidation Active is merged.
• Drupal 12 release date gets closer. I think this changes are proper to be added along with the hooks classes refactor.

I have changed it according to the latest changes (supporting of queue invalidation) that were conflicting with this issue.

I see the changes okay but I cannot test it as I don't have configured a site with path based cache. May somebody test it? Thanks!

Working to fix merge conflicts

Merged and released at 1.2.0. Thanks all for the help and feedback!

The MR !10 looks fine.

About the feedback from #7, this module has born as a solution to inmediate purge files, as a project was needing to instantly refresh its financial reports / legal documents after replacing those files having the same. Purge allows it but do not recommend it https://git.drupalcode.org/project/purge#api-examples . In the practice , inmediate purge is working fine.

It is true that not every site needs an inmediate purge, and there are sites where inmediate purging every update file on a page may lead to performance issues. That's why this contribution is very valuable for the project, letting developers to choose the best option for their sites.

After reviewing it, it works fine. The hook update provides the backwards compatibility and it additionally fixes some problems on the hook_requirements. I've merged it and I will create a release right now.

I move it to needs work because I've noted that this solution would fail in sites that do not use layout builder.

I have created a MR solving the problem. Please review, thanks!

omarlopesino → created an issue.

The attached MR adds the API key field to the form and uses it at every api call whenever is available. Please review, thanks!

omarlopesino → created an issue.

Works fine!

Working on it, see the attached MR. I will go back on this tomorrow to review if it is possible to add a different form element type for each property type.

omarlopesino → created an issue.

I have created an MR with the fix. Please review, thanks!

omarlopesino → created an issue.

I've added changes so that the build:watch command works properly. Now it is needed an additional plugin.

I've made a merge request that:

1. Compiles any asset from a component's src folder into the component. For example: web/components/chart-element/src/chart-element.ts -> web/components/chart-element/chart-element.js
2. Only replaces assets at library info alter when the dev mode is enabled.

Please review, thanks!

omarlopesino → created an issue.

We can fix it alternatively using Paragraphs legacy widget instead of paragraphs stable.

Thanks for the work on the module and the fast response time! I tried this module in a theme and it works great to view all sdcs and show their variants.

MR ready. With this change, the demo exported works great. May you review it? Thanks!

omarlopesino → created an issue.

Thanks for the feedback!

After testing the compatibility change at a Drupal 11 site, the Drush command needs to be adapted. Otherwise, when you set options that requires value, it throws an error like this:

The "--preserve-languages" option requires a value.

After doing this changes the module works as usual in D11. Those changes should be compatible with earlier Drupal releases, but if someone could test it in a previous version it would be appreciated.

omarlopesino → created an issue.

omarlopesino → made their first commit to this issue’s fork.

The change is working and tests are passing. May somebody review the latest change, so we can move it back to RTBC? Thanks!

Added this commit to support image styles URLs: https://git.drupalcode.org/project/drupal/-/merge_requests/5882/diffs?co...

Hi, this functionality works great. I think to complete this issue we should address the problem reported by #115 and #151 : the image styles are not accessible. This produces that when I access an absolute URL of a image style generated by the Image url formatter, the result is a 404 page.

In my case I reproduced with the latest version of the MR, having a private image field that has image styles.

I suggest going back to building the URL with image_style->buildUrl for image styles, and using fileUrlGenerator only to generate original image urls, and transforming the absolute url to relative.

It works for me. I've added a composer.json to be able to require the issue fork through composer.

omarlopesino → made their first commit to this issue’s fork.

I added a composer.json file to be able to require the module through composer

omarlopesino → made their first commit to this issue’s fork.

The MR !18 invokes the hook before converting the diff to JSON and saving the log, only when diffs are enabled of course.

Can you review it please? Thanks!

omarlopesino → created an issue.

Thanks both for the feedback!

About #1: Adding a hook will allow developers quickly sanitizing the values, meanwhile we prepare a definitive solution. It would also let developers add custom logic to the redaction, as maybe it needs some dynamic calculation, or a specific way to redact it.

This approach would help users less familiarized with module development / those who want to provide this redact configuration through recipes.

I will open a new issue for adding the hooks to alter diffs, independent on the purpose.

About #2: I agree as it will help to easily switch on and off the redaction. That can be saved into Drupal state, so it does not need deployments.

omarlopesino → created an issue. See original summary → .

omarlopesino → created an issue.

After reviewing this issue back, I agree that image_widget_crop is setting up "arbitrary properties" into the field value for convenience. That is the way the module is able to save the list of crops, to save it properly on entity save.

That is a specific behaviour that I think it won't be present on Drupal core, so I agree it belongs to contrib support.

However, I noticed something. This problem is happening because a contrib module is setting a property to a field value which won't be saved. In this case, that property won't be saved to database. I mean, if the entity is loaded, that `image_crop` property won't be present.

I will check if it is possible to solve this problem with other solution: loading the entity before saving the diff here, like it is done at entity update

omarlopesino → created an issue.

Released in 1.0.5. Thanks, and apologies again in case rejecting the issue have felt uncomfortable.

I have included to the MR a hook update that will update the view , replacing the configuration with the module's one. The module's main feature is the view, so it is needed to automatically refresh the view once is updated in the module.

Please note @eduardo, that the site where you are using this view will be changed. I think it won't suppose a problem, but if it does, let me know and we can think a solution if needed.

After talking with @Gedur, I have understood that filtering by date helps filtering out errors that may have been fixed in the past, and are not needed to be seen. You have tried to explain it to me but I didn't understand well.

Reopening and doing just some minimal adjustments:

• The 'relative dates' placeholder is removed, as the filter will be based on dates.
• The filter is now considering the greater or equal, and less or equal, instead greater and less.
• The labels have been renamed to 'Timestamp (from)' and 'Timestamp (to)'.
• The ids of the exposed filters have been renamed to timestamp_from and timestamp_to.

Thanks both for the contribution, changes will be consolidated and added into a new release.

Yesterday I've noticed that I can use lists selecting 'Custom Scalar + Raw'. So the module already implements what I've needed. CLosing.

I have this warning in my project. It happens when I create a bundle computed field and add I declare it into views. The problem happens because commerce promotion is trying to get the field information from entity field definitions, and not entity bundle field definitions.

I've added a 'Steps to reproduce' section at the issue.

This patch solves the issue for me. Please review, thanks!

I've checked this and it works fine. I prefer this solution rather than the previous one as it not rely anymore in the values returned by formatters, so results are more predictible. Thanks!

Moving to RTBC

?? only works when the returned value is null and ?: accepts any value considered empty (FALSE / 0...). For this case both should be good, but ?: would cover more unexpected returns. Let me know if you want me to do the change.

This has already been released, thanks!

omarlopesino → created an issue.

I confirm that Scala returns the context as it is , but the problem is that the returned json by the formatter is a plain text of the json, and not the json decoded.

Then, in the GraphQL view, instead of returning

"myJsonField": {
"foo": "bar"
}

it returns:

"myJsonField": "\<code>{\r\n  \"foo\": \"bar\"\r\n}\</co..>"

This MR allows recognizing this specific case and do the conversion.

The MR fixes the problem. it just fixes the parenthesis so each empty call is separated. Please review, thanks!

omarlopesino → created an issue.

omarlopesino → made their first commit to this issue’s fork.

All the warnings reported by static analysis have been fixed, which led to some small refactors. It should preserve the old behaviour. Please review, thanks!