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.
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!
Confirmed! The patch at https://www.drupal.org/files/issues/2022-08-22/2850794-51.patch → resolves the error in D9.
Thank you!
cameron prince → created an issue.
cameron prince → created an issue.
Sorry, I don't know anything about this service. Feel free to reopen and submit a patch.
cameron prince → made their first commit to this issue’s fork.
Committed.
Committed. Thanks!
@trigdog, you were correct. This patch required the new API work in the other patch. Once that was merged, this patch works as intended. The drush command for regular syncing is generating an error, so I'll create a new issue for that as well as one for adding single item support to the command.
Thanks!
Here's a patch to also resolve the problem in #4.
Closing as duplicate of 🐛 Error: Cannot use positional argument after named argument in _batch_process() Fixed .
cameron prince → created an issue.