🇺🇸United States @cameron prince

cameron prince → created an issue.

While the features provided by this patch might be useful, in order for them to be added to the module, they would need to configurable, i.e. no hardcoded field names.

I going to close this as "works as designed" for now. Feel free to reopen if you'd like to continue working on it.

I'm not sure what the intention of this patch is. It is worded as if it's a fix, but it seems to create a new file for stand-alone operation. I also believe it may be outdated now with the new version of the Spatie library.

Closing as outdated. Feel free to open a new issue if this is still needed.

Closing this as outdated based on #7. Feel free to open a new issue if this is inaccurate.

The patch was tested on a vanilla Drupal installed and worked as expected. Patch code looks good.

Thank you!

Thanks for the MR!

Thanks for the MR!

I approve this request, but I lack permissions needed to make it happen.

Nice to see this merged. Thank you.

This one's been a long time coming! Thanks, Jess!

Looks good. Merged and closing as fixed. Thank you!

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

I've reviewed and tested this patch as well. The code looks good. It cleanly applies to the dev branch and appears to work as intended.

+1 for merge. Nice work!

The module will be minimally maintained for the foreseeable future as I use it on my own site. During my last update work, I looked into making commerce_printful D11 ready, but core commerce itself wasn't ready. I have other priorities at the moment, but will get to this eventually. I'd be happy to review MRs if you'd like to contribute. I would also be open to co-maintainership once you've proven yourself.

Thanks,
Cameron

swirt → credited cameron prince → .

Thanks for the patch!

I don't think this module would be able to replace that. This module is very simple and just populates an image field with the first page of the PDF.

Thanks for the MR. Release incoming.

This has been merged and 1.0.5 cut. Thanks!

I'm not in a place where I can troubleshoot this right now, but you can try this:

drush php-eval '\Drupal\field\Entity\FieldStorageConfig::loadByName("commerce_product", "printful_reference")->delete();'

Okay, I would suggest appending that type to the existing one instead of removing the check all together.

cameron prince → created an issue.

It was intentional to limit the available choices to text-based fields as this is how the comparison is made with the input. If we remove this check, we might need to cast the value to string before it's compared. I'm curious as to what field type you're using it with.

Here's an example event subscriber which might work for you:

/**
 * Provides the DocumentOcrDestinationEventSubscriber class.
 */
class DocumentOcrDestinationEventSubscriber implements EventSubscriberInterface {

  /**
   * The event subscriber to function mapping.
   */
  public static function getSubscribedEvents() {
    $events['document_ocr.task_create_desination_before'][] = ['setDestination'];
    return $events;
  }

  /**
   * Sets the Document OCR destination.
   */
  public function setDestination($event) {
    // Add code to look up the node to save to.
    $nid = 1234;
    if ($node = $this->entityTypeManager->getStorage('node')->load($nid)) {
      $event->setEntity($node);
    }
  }

}

The other alternative is to either override/extend or decorate the Document OCR process service.

cameron prince → created an issue.

@obiwankenobi, could you please post an example event subscriber which overrides the destination as this issue describes?

This could hopefully be an alternative to ✨ Save results on the same node id Active .

Thanks!

The rector fixes in 📌 Drupal 10 Compatibility Needs review cover this problem, but don't use dependency injection.

The updated patch should be applied after the patch from #3366764.

Thanks for the patch!

Fixed and created the 1.0.4 release. Thanks!

swirt → credited cameron prince → .

It already uses strip_tags. This is what was added:

$body = Html::decodeEntities(strip_tags($body->__toString()));

Maybe the functions need to be reversed to alleviate your concerns, i.e. decode entities before stripping tags so that any decoded items that become tags are then stripped, too.

As for the other logic issues with the UI you've pointed out, they existed before my involvement. I added the negate feature and the limit per hour to what was already there. I agree it could be better.

The enable option allows you to disable the functionality of the module globally for certain environments via settings.php without uninstalling the module. In my case, I have a settings.local.php which disables it in my local development environment which I don't wish to receive emails from.

I think the issue description is pretty clear. The emails are sent as plain text, not HTML. This was added so that contents of the emails are more legible and don't include HTML code or encoded entities.

As the content isn't being rendered as HTML, I don't really get the security concern. If there is a better or more appropriate way, I'm all ears.

@LRWebks, regarding #12... How was the watchdog_mailer_history table created during the upgrade? And if it wasn't, you wouldn't likely see the error until an attempt was made to log the error.

@Anybody, could you please rebased the patch? It's not currently mergeable.

Moving this request to the Drupal.org project ownership issue queue.

Project page link: https://www.drupal.org/project/pdf_preview_image →

This was added in 2.0.7.

cameron prince → created an issue.

cameron prince → created an issue.

cameron prince → created an issue.

Both current maintainers were again contacted today via the d.o contact form.

cameron prince → created an issue.

Looks good! A new release will be created. Thank you everyone.

This is to note that both current maintainers were sent messages regarding this request today via the d.o contact form on their profiles.

Cameron

cameron prince → created an issue.

Changes look good and have been merged. Closing this as fixed!

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

The change looks good and has been merged. This is my first time using the merge request way. I your code change has made its way to the dev branch, but not sure if I need to do more to credit you.

cameron prince → created an issue.

Here's the way I found to uninstall... I was running beta 1.0 on Drupal 9.5.10 and couldn't upgrade or uninstall the module.

The uninstall was dying with:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'rh_action' in 'where clause'

The solution was to login to the database and add the missing columns, which the uninstall would then immediately remove. I think adding a hasTable() check would be the proper addition to the uninstall routines to resolve this.

ALTER TABLE node_field_data ADD rh_action varchar(64);
ALTER TABLE node_field_data ADD rh_redirect_response varchar(64);
ALTER TABLE node_field_data ADD rh_redirect varchar(64);
ALTER TABLE node_field_data ADD rh_redirect_fallback_action varchar(64);
ALTER TABLE taxonomy_term_field_data ADD rh_redirect_fallback_action varchar(64)
ALTER TABLE taxonomy_term_field_data ADD rh_redirect varchar(64);
ALTER TABLE taxonomy_term_field_data ADD rh_redirect_response varchar(64);
ALTER TABLE taxonomy_term_field_data ADD rh_action varchar(64);

Keep in mind that if you enabled other submodules, you probably need to add the columns to the related entities as well. I only did terms and nodes.

cameron prince → created an issue.

Hello,

I've been trying to use this patch for some time and haven't really had any luck, so far. My goal is to place images inline with text. These are things like complex formulas or diagrams.

Here are the steps I've taken:
1) Added the latest patch from this issue
2) Created an "Inline" view mode on the image media type
3) Created an "Inline" image style
4) Created a new embed button with "Entity Inline" selected as the type
5) Selected the "Inline" view mode for the "Allowed Entity Embed Display plugins" setting of the button
6) Added the new button to the toolbar
7) Enabled the "Inline" view mode for the image media type
8) Set the "Inline" view mode to display the image using the "Inline" image style
9) Cleared cache

The issues I'm seeing are:
1) When embedding an image, the "Align" selector (None, Center, Left, Right) is still available, which doesn't make sense for an inline image.
2) After embedding an image, the "Source" button no longer works
3) The editor window does now show the image after embedding (which it wasn't doing on the previous patch), but when I save the node, the body is emptied.

I'd like to get this working and glad to help any way I can.

I'm seeing this too. Backing down to 2.0.5 resolves it.

It looks like something to do with the injection of \Drupal\Core\Mail\MailManager.

Looks good! Thanks!

cameron prince → created an issue.

Fixed at: https://git.drupalcode.org/project/betasite/-/commit/8e2f3d958d1380e3557...

Fixed at: https://git.drupalcode.org/project/betasite/-/commit/8e2f3d958d1380e3557...

cameron prince → created an issue.

cameron prince → created an issue.

cameron prince → created an issue.

cameron prince → created an issue.

cameron prince → created an issue.

cameron prince → created an issue.

cameron prince → created an issue.

cameron prince → created an issue.

cameron prince → created an issue.

We tested this again today on the servers where the source images are and it worked well. I believe this will be ready for RTBC once the MR is updated so the patch applies.

I've been testing this, but had to re-roll the patch. It looks like it's either outdated or it's trying to patch on top of another patched version instead of origin.

The export ran without error and the zip file was created when testing with about 10 nodes. The import fails with a AssertionError: Cannot load the "file" entity with NULL ID. error. I think this may be related to my setup.

I'm going to test again on another environment and will report back.

It works splendidly well! Thank you so much!

This really rocks!

I've enabled revisions on the basic block custom block type and tried again. It didn't seem to change anything. Here's the export.

Ah, you are correct... We don't have revisions turned on for custom blocks. I'll switch it on and give it a try.

Here's another test on a fresh setup. This time, I put an image in the body field and assigned it to the middle column. The two side columns have custom blocks, one with an image and the other with just text.

The image on the body is exported properly, but as you mentioned, the blocks element is empty and I don't see the image file in the export for the image in the block.

One thing to note, we're using the Layout Builder Overrides module ( https://www.drupal.org/project/layout_builder_overrides → ) which allows the default layout to be overridden per view mode, rather than only the default view mode. I wonder if this is the culprit.

Hmmm. It does seem to export the blocks themselves. They appear after importing on the fresh DB restore. It's just that the media in their bodies isn't also included in the export.

Do you think it's something with our particular structure? I'm not sure how to troubleshoot.

Here's the export I downloaded after creating the test node.

I will re-test and document to confirm. Maybe I missed something.

When you deleted the content you exported, did you also delete the media entity and its corresponding file entity?

I took the exact same steps, but instead of deleting the content manually, I reimported the DB from a backup I'd made prior to creating the content.

Thanks for the help!