🇷🇺Russia @i-grou

Well, I've tried to uninstall a module and install it again - results are the same. When I use Inspector/Console (Ctrl+Shift+I) I can see a canvas instead of image. But when I look at the page source (Ctrl+U) I can see normal img tag with direct url in it.

And it's not surprising actually. As I've checked the source code of your module and can clearly see that it relies on js library. So the source html was never meant to be protected.

As a conclusion I can say that this module offers good protection for images from average users. At the same time it provides zero protection from tech-savvy guys. Maybe you should note it somewhere in the module description.

Thanks for that fix @g.mustapha, now there is no anything pointing to the real image in the Page Inspector tool:

At the same time I can still see the direct image url in the page source:

Basically it means that there is no protection for the image, as it's possible to get to the page source and get any image from there (it's also easy to write a script for that). Are there any other ideas to implement in the nearest future to achieve real protection?

i-grou → created an issue.

Have the same issue on my site. Any suggestions how to fix it?

i-grou → created an issue.

i-grou → created an issue.

Thanks @sakthi_dev. But what do you suggest for 10.x users?

i-grou → created an issue.

Great!
Have created the 1.0.x-dev release, so you can use it now. Will release 1.0.1 soon.

Hi @aman_lnwebworks, thanks for the MR!

Looks like some entity doesn't provide any db table (weird). As it does not make sense to generate config without a table I've modified the DbaConfigGenerator::generateConfigEntity() to quit in such cases. Could you test it please before we merge the MR?

i-grou → made their first commit to this issue’s fork.

i-grou → created an issue.

Done, check please.

Added new dependencies to trucie.libraries.yml, check now please.
By the way is it enough to add just core/drupal as it already has core/drupalSettings as dependency?

Thanks @vishal.kadam for your review.

1. feature/TRC-3 and feature/TRC-2

1. feature/TRC-3 and feature/TRC-2 are wrong names for a branch and should be removed. Release branch names always end with the literal .x as described in Release branches.

These branches are used to meet development rules used in our company. They have nothing to do with release, eventually they will be merged to 1.0.x branch and then removed. Here in the description I've mentioned that 1.0.x - is the branch we need to check. Or am I missing something?

2. Fix phpcs issues

1 | ERROR | [x] The PHP open tag must be followed by exactly one blank line

Since we have a php 8 using the declare(strict_types=1) becomes a standard. I undestand that old standard was like this:

<?php

declare(strict_types=1);

Maybe in the past the declare() directives were rarely used and it was totally fine to have a blank line after php tag.
But things are changed, nowadays in all sorts of contrib packages I can see the shorten form:

<?php declare(strict_types=1);

As we have to add a declare(strict_types=1) line to every php file this shorten form makes sence and tend to become a new standard.
As this does not affect any performance and is not a threat from security perspective I'd suggest to keep as is.

FILE: trucie/src/Processor/TrucieImporterProcessor.php
-------------------------------------------------------------------------------
FOUND 1 ERROR AND 12 WARNINGS AFFECTING 13 LINES
-------------------------------------------------------------------------------
 174 | WARNING | [ ] Unused private method processExplode()
 189 | WARNING | [ ] Unused private method processImplode()
 204 | WARNING | [ ] Unused private method processFloatval()
 238 | WARNING | [ ] Unused private method processIntval()
 267 | WARNING | [ ] Unused private method processMbStrtolower()
 296 | WARNING | [ ] Unused private method processMbStrtoupper()
 325 | WARNING | [ ] Unused private method processUcfirst()
 354 | WARNING | [ ] Unused private method processPregReplace()
 383 | WARNING | [ ] Unused private method processStrtotime()
 412 | WARNING | [ ] Unused private method processDate()
 441 | WARNING | [ ] Unused private method processTrim()
 476 | WARNING | [ ] Unused private method processEntityLookup()

Actually these methods are used (see process()):

      ...
      $method = ($processor['type'] ?? '') ? 'process' . $this->makeMethodName($processor['type']) : '';
      if ($method && method_exists($this, $method)) {
        $value = $this->{$method}($value, $processor);
      }

Maybe I could change private to protected or public, but this does not make sense as all these methods should not be available outside.
So we can ignore these warnings.

3. FILE: assets/js/form_trucie_importer.js

})(Drupal, drupalSettings);

Not sure I understand what exactly is wrong here. This is a typical way to do things in js, even some core js files has this.
Could you give more explanation on that?

FILE: trucie.libraries.yml

  dependencies:
    - core/once
Specify correct dependencies to avoid the unnecessary loading of files that are not needed and ensure all necessary dependencies are included for scripts to function properly.

Not sure I understand what exactly is wrong here. The once() js function coming from core is heavily used in this module, so I need this dependecny.
Could you give more explanation on that?

All other issues are fixed, check please.

Thanks @vishal.kadam. I've already read the checklist and ran phpcs. Hope it's fine, waiting for review. Will be glad to any feedback.

i-grou → created an issue.

Not sure if this would help someone, but in my case controller expected to recieve a service that does not exist and that was the cause of the issue.

See __construct() and create() in example below (the my_module.content_magnifier service was not defined yet):

<?php
class FantasticController extends ControllerBase {

  public function __construct(private readonly $contentMagnifier) {
  }

  public static function create(ContainerInterface $container) {
    return new static(
      $container->get('my_module.content_magnifier'),
    );
  }

  public function page(): array {
    return $this->contentMagnifier->build();
  }

}

Thanks @MegaChriz for your reply and suggestions.

I think I'll go ahead with Trucie (True Content Import) → module for now as it fully meets my needs.

i-grou → created an issue.

i-grou → created an issue.

Thanks @everkuil for your question. I've ran some tests and checked the source code - looks like drupal.form-single-submit built-in behavior does the same job (using the same principle) as webform_single_submit. So answering to your questions:

1. This module is no longer necessary (for Drupal 7.98+)
2. This module may interfere with new drupal behavior, but it should not break anything. Either webform_single_submit or drupal.form-single-submit would be executed first and prevent duplicate submission.

I've ran some more tests and it turned out that patch above not working as expected. Hope it would be fixed in the next release.

Tried patch #78 and it works fine for export, but somehow $section_data->getValue() (in LayoutSectionItemNormalizer->denormalize()) produces an error when importing node with individual layout (using content_sync module):

Error: Call to undefined method Drupal\layout_builder\Section::getValue() in Drupal\layout_builder\Normalizer\LayoutSectionItemNormalizer->denormalize() (line 30 of /var/www/rtc.ccuptest.co.uk/web/core/modules/layout_builder/src/Normalizer/LayoutSectionItemNormalizer.php).

So to workaround it I've added a check if method exists, if not - then using $data['section'] instead works fine.
Maybe it's better to debug SectionData class, but I got no luck with this (in 15 min), maybe someone else can handle it. Or maybe it's related ot my drupal version - 8.8.4. Meanwhile we can go ahead with this patch.