Jump to content
Pierre-Luc

WireMail Mailgun

Recommended Posts

@jens.martsch - ok thanks for the report;

I haven't tested all elements of the new version – have you tested any other features, like the "dynamic domain" etc?

The main reason it has not been updated is because full testing of compatibility hasn't been done by me yet, and i was concerned about current users upgrading and possibly things failing silently...

Also I think the new version has a PW minimum requirement (3.0.123), and i haven't checked to see if the module config specifies, this, or what PHP versions the module is compatible with and putting in a minimum php version.

Share this post


Link to post
Share on other sites

Hey @Macrura I haven't tested "dynamic domains" because I don't use them, but the region setting for "EU" domain and also tracking for message open and clicks, which are working fine.

I also committed another patch for strange display behaviour in outlook: https://github.com/chriswthomson/WireMailMailgun/pull/14

Share this post


Link to post
Share on other sites

ok thanks, i'll be back on heavy module development in about a week or 2 and will be able to finally merge the versions and test and get this all sorted..

  • Like 1

Share this post


Link to post
Share on other sites
18 hours ago, jens.martsch said:

Hey @Macrura I haven't tested "dynamic domains" because I don't use them, but the region setting for "EU" domain and also tracking for message open and clicks, which are working fine.

I also committed another patch for strange display behaviour in outlook: https://github.com/chriswthomson/WireMailMailgun/pull/14

Hi @jens.martsch - I've merged your request.

I'd always thought that was the correct behaviour because if you send from a domain that isn't what you have in Mailgun (e.g. @test.com when @mg.test.com is your verified domain) then the "on behalf of" is the correct result. However, if one line fixes that, that's great!

Cheers,

Chris

  • Like 1

Share this post


Link to post
Share on other sites

@jens.martsch - thinking through it a little more, I think the addition of h:sender should only happen if the "from" domain is different to $this->domain. I'll pop that in place soon. I'd wondered whether using this would effect the DKIM auth etc but a few quick tests suggest that it doesn't 🙂.

@Macrura - I've been thinking about the Dynamic Domain setting, which I'd implemented based on your version but didn't give it much thought. Does it actually work without specifying the API key for the different domain? I wonder whether this could be removed and the following be the way to send from a different domain?

<?php

$mg = $mail->new();
$sent = $mg->to($to)
	->setDomainName("mg.differentdomain.com")
	->setApiKey($differentApiKey)
	->setRegion("eu") // If the region is different
	//->setSender("mg.differentdomain.com", $differentApiKey, "eu") // Alternative, region optional
	->subject($subject)
	->bodyHTML($message)
	->send();

Cheers,

Chris

  • Like 1

Share this post


Link to post
Share on other sites

On my account, i have many domains, all use same API key.

As I explained earlier in this thread, the only way to have send log entries go to the correct place in MG is to use the dynamic domain setting.

Sure, if you are able to use the API when sending, then using setDomainName() works, however API is not used when Form Builder is sending out emails from WireMail, or many other scenarios where mail is being sent by the system;

Without the dynamic domain setting enabled, your logs will be all messed up in MG, anytime FB auto responses are sent. Also, dynamic domain setting ensures you don't have to use setDomainName(), because even then, you'd still have to figure out which domain name to send from using the same code that is provided by the module...

 

 

Share this post


Link to post
Share on other sites

@Macrura - Thanks for the info. I wasn't thinking outwith explicit calls to WireMailMailgun, so that makes sense. I'll probably still add the setSender() and setRegion() functions though, might be useful to have.

Cheers,

 

Chris

  • Like 1

Share this post


Link to post
Share on other sites

How can I separate the api $mail->new call to the default wireMail when the MailGun Module is installed?

I use MailGun for the ProMailer Module, but have a few instances on the site, where mails are sent through the API. For instance the contact form now is using mailgun as well, but I don't want that. Is there an option to set the mailer to the default wireMail?

  • Like 1

Share this post


Link to post
Share on other sites

The Tracking of Mailgun did not work on my installation. I had to change the following:

private function clickTracking()
	{
		return ($this->trackClicks == 1) ? true : false;
	}

private function openTracking()
	{
		return ($this->trackOpens == 1) ? true : false;
	}

Don't know why it's a problem though. I'm using ProcessWire 3.0.123.

Share this post


Link to post
Share on other sites
On 6/2/2019 at 1:38 PM, Schwab said:

How can I separate the api $mail->new call to the default wireMail when the MailGun Module is installed?

I use MailGun for the ProMailer Module, but have a few instances on the site, where mails are sent through the API. For instance the contact form now is using mailgun as well, but I don't want that. Is there an option to set the mailer to the default wireMail?

Hi @Schwab - I'm not sure how this can be done, although given that there are a number of WireMail extension modules out there, I'm sure it must be possible and discussed previously. Might be worth having a look through the threads for WireMail SMTP etc to see if there is any info there.

4 hours ago, Schwab said:

The Tracking of Mailgun did not work on my installation. I had to change the following:


private function clickTracking()
	{
		return ($this->trackClicks == 1) ? true : false;
	}

private function openTracking()
	{
		return ($this->trackOpens == 1) ? true : false;
	}

Don't know why it's a problem though. I'm using ProcessWire 3.0.123.

I'm assuming this is @Macrura's version on the module repo - these methods came from the original "plauclair" version. I removed them entirely from my version as they were unnecessary, and didn't look like they would work anyway, given that trackClicks and trackOpens should be booleans (technically integers, but evaluate as either true or false).

I updated chriswthomson/WireMailMailgun last week with fallbacks etc, tested on 2.7.2 and above. Ended up moving straight onto another task and completely forgot to post!

  • Like 1

Share this post


Link to post
Share on other sites

Thanks @nbcommunication again for your continued work on this!

I should be able to work in next week and sort this whole thing out, with testing of dynamic domains and other functionality for QA.

As mentioned previously, the only reason I have not updated it is because I suspect that people may be running business-critical infrastructure with this module and any interruption to communication via email would be best to avoid.

And specifically you can see that a lot of people (including me) are not fully clear about how the Wiremail system works;

@Schwab's question illustrates this issue – you can't choose parts of the system to use different Wiremail implementations unless you have access to the API; Even then i'm not sure how the core selects which Wiremail module to use. For example, if you have WMMG installed and only want to use that from API calls, but also want to have WMSMTP running for Formbuilder, i don't think that is currently possible, though perhaps some hook magic would be the solution here...

Usually if I install WMMG on a site, I assume all mail will then be routed through the relevant Mailgun account, including Formbuilder submissions, as well as any custom email sends from modules, tracy notifications etc.; I have not played with having 2 separate Wiremail modules installed, because last time i tried that, it didn't seem to work though i don't have notes about why or what the issues were; I do know that different Wiremail modules were using different method names for the same thing, like attachments and that became tricky to manage when switching between WM modules...

 

Share this post


Link to post
Share on other sites
3 hours ago, Macrura said:

 

@Schwab's question illustrates this issue – you can't choose parts of the system to use different Wiremail implementations unless you have access to the API; Even then i'm not sure how the core selects which Wiremail module to use. For example, if you have WMMG installed and only want to use that from API calls, but also want to have WMSMTP running for Formbuilder, i don't think that is currently possible, though perhaps some hook magic would be the solution here...

Usually if I install WMMG on a site, I assume all mail will then be routed through the relevant Mailgun account, including Formbuilder submissions, as well as any custom email sends from modules, tracy notifications etc.; I have not played with having 2 separate Wiremail modules installed, because last time i tried that, it didn't seem to work though i don't have notes about why or what the issues were; I do know that different Wiremail modules were using different method names for the same thing, like attachments and that became tricky to manage when switching between WM modules...

 

I made a quick test to try the different options to get an instance of WireMail.

Like https://processwire.com/api/ref/wire-mail/ tells us, there are three options:

$m = $mail->new(); // option A
$m = wireMail(); // option B
$m = new WireMail(); // option C

With WireMailMailGun installed, option A and B are going out with WireMailMailGun.

Option C uses the native WireMail.

So for anyone using WireMailMailGun and wanting to send mails outside of MailGun, new WireMail() is the way to go.

  • Like 2

Share this post


Link to post
Share on other sites
6 minutes ago, Schwab said:

With WireMailMailGun installed, option A and B are going out with WireMailMailGun.

Option C uses the native WireMail. 

seems sort of inconsistent; i guess when using new WireMail() it sets up an object separate from the WM classes..... (?) maybe an undocumented feature...

Share this post


Link to post
Share on other sites
1 hour ago, Macrura said:

seems sort of inconsistent; i guess when using new WireMail() it sets up an object separate from the WM classes..... (?) maybe an undocumented feature...

This is related to https://github.com/processwire/processwire-issues/issues/733. Simply put new WireMail() specifically instantiates a WireMail object, not WireMailMailGun object, so this is (kind of) expected behaviour 🙂

Share this post


Link to post
Share on other sites

so it seems that modules that send email should always have a way of specifying which WireMail module to use. In other words, Formbuilder should have a setting which scans the installed WireMail modules, and allows the user to select which one to use for FB mails sent; Same for something like ProMailer.

The behind-the-scenes selection of which mail module gets used seems to be causing confusion among users, hence the questions on this thread and the issue #733.

It also seems possible to have multiple WireMail modules installed which would not conflict with each other, if you always specifically called the module you want to send with, instead of Option A, B or C.  I have not tested this theory, but i guess at some point soon there should be some codification of the whole thing...

 

  • Like 1

Share this post


Link to post
Share on other sites
11 hours ago, Macrura said:

so it seems that modules that send email should always have a way of specifying which WireMail module to use. In other words, Formbuilder should have a setting which scans the installed WireMail modules, and allows the user to select which one to use for FB mails sent; Same for something like ProMailer.

Depends: you could provide such option, but don't really have to. FormBuilder, for an example, simply makes use of the wireMail() function, so you're automatically using an installed ("third party") WireMail module instead of the default one (if one can be found – and if multiple are installed then the first one found).

When the WireMail module type was introduced all examples used this function, either directly sending messages using it, or instantiating a new WireMail object by calling it without arguments ("$mail = wireMail()"). Basically you should only ever use "new [WireMail class name]()" if you want to select a specific WireMail module instead of letting ProcessWire make that choice for you.

  • Like 1

Share this post


Link to post
Share on other sites

But what if you (like @Schwab) want a form to not use 3rd party module?

On 6/2/2019 at 8:38 AM, Schwab said:

I use MailGun for the ProMailer Module, but have a few instances on the site, where mails are sent through the API. For instance the contact form now is using mailgun as well, but I don't want that. Is there an option to set the mailer to the default wireMail?

If you were coding the contact from then yes, you'd be able to bypass the 3rd party module, but else you have no control over modules that always call the 3rd party WM module; And what if you have a few 3rd party modules installed and want to have control over which one is used and when, not using the API....

Share this post


Link to post
Share on other sites

Hey,

Launched a site today with a form that sends attachments and it turned out that our production server doesn't have mime_content_type() 🙁

https://github.com/chriswthomson/WireMailMailgun/pull/17

I've added a private method getMimeType() which checks first for mime_content_type(), then finfo_open(), then falls back to inferring based on file extension if neither exist.

This is based on https://www.php.net/manual/en/function.mime-content-type.php#87856 and https://gist.github.com/Erutan409/8e774dfb2b343fe78b14#file-mimetype-php

Also, a WireException is now thrown if an attachment has been added using WireMail::attachment() but curl_file_create() doesn't exist.

Cheers,

Chris

  • Like 1

Share this post


Link to post
Share on other sites

Hi all,

Is there any means to force MailGun as the wireMail 3rd party module?

A few days ago one of my sites stopped sending WireMailSMTP e-mails (couldn't connect to smtp.mailgun.org). There'd been no changes but I took it as an opportunity to switch over to this MailGun module that I use on several sites. 

When I'm using either FormBuilder, or my own code with '$message = wireMail();' for example, it doesn't use the MailGun module. Instead it tries to send using standard Wiremail which is picked up both on wiremaillogger and in cPanel. 

I simply cannot get it to call MailGun. Has anyone had this issue? I'm running PHP 7.1.

Thanks.

EDIT: It seems the issue is caused by the WireMailBranding module I still had installed. Uninstalling the module fixed this. It was never marked as compatible with 3.0 but did work until I updated to the latest MailGun module. I'll look further into it and see if there's a simple fix.

Share this post


Link to post
Share on other sites

@nbcommunication @Macrura

Sorry to bother, but could someone clarify what's the current state of this module? This thread contains posts about two separate versions, which are apparently not compatible – if the official version is still the one from Macrura, I think we should split posts about the "other version" to another thread if possible. Note that if that is to be done, it should really be released as a new module.

.. unless the plan is to make that the official version?

I'm currently starting a new project with this module, and had a bit of trouble figuring out which version to install 🙂

On 6/5/2019 at 3:30 PM, Macrura said:

But what if you (like @Schwab) want a form to not use 3rd party module?

That's a good point! To me it sounds like implementing a "Mailer picker" for each module separately would result in awful lot of duplicate work/code, though perhaps it would indeed be a reasonable feature for at least some of them (such as FormBuilder). I have never been in this situation, i.e. I've always used one mailing method per site, so not sure what would be the best approach.

One option would be providing a hookable method for sending the message, in which case this part could be overridden if deemed necessary 🙂

Share this post


Link to post
Share on other sites
1 hour ago, teppo said:

though perhaps it would indeed be a reasonable feature for at least some of them (such as FormBuilder)

FormBuilder has just such a setting:

2019-09-05_224155.png.c9d0d0e4a02556725eaaa7f5dd51e2bd.png

Although strangely if I change this setting it doesn't stick and always returns to "Auto-detect" - might be a bug.

For controlling the WireMail mailer used by other modules perhaps the recently released Mail Router module could be a solution. Although the module that is sending the mail can't be detected directly, for some circumstances you could perhaps use a prefix in the subject line (e.g. "Form submission: ...") that could determine which WireMail mailer is used.

  • Like 1

Share this post


Link to post
Share on other sites

@teppo

the modified version by @nbcommunication is supposed to replace the current version, but I was trying to find time to test it before replacing the code so as to not potentially have users upgrade and then have broken installations.

I just came across a problem with the current version, in that one of my business-critical sites suddenly seems to have lost the ability to send attachments using existing 'official' version;  so now i need to work on that - time is the only challenge now, but hoping to get to this within a minimum of the next week...

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, Macrura said:

the modified version by @nbcommunication is supposed to replace the current version, but I was trying to find time to test it before replacing the code so as to not potentially have users upgrade and then have broken installations.

I just came across a problem with the current version, in that one of my business-critical sites suddenly seems to have lost the ability to send attachments using existing 'official' version;  so now i need to work on that - time is the only challenge now, but hoping to get to this within a minimum of the next week...

Thanks for the update! No worries, take your time – my current use case isn't particularly time-sensitive. I'm just happy to know what the long(er) term plan with the module is 🙂

Share this post


Link to post
Share on other sites

Hi,

The main breaking change with my version of the module is that Cc/Bcc is ignored if batch mode is set to on. Seemed absurd to me that an email sent to multiple addresses individually would be sent each time to any cc/bcc addresses set. 

The latest version is compatible with 2.7 onwards.  I implemented fallbacks for things (e.g. textTools) not present in the 2 branch. It also has more features and I've been using it in production without issue since I first posted it. However, I've not been using it for much more than sending simple emails. It's fully tested though 🙂 

I'd recommend using it if starting a new project, but I'm reluctant for it to be the main directory module as any users upgrading could encounter problems with their existing implementation. They'd be easy to fix, but that's not the point. I don't use any of the Pro modules that it integrates with (FormBuilder, ProMailer), and wouldn't want to interrupt "power" users of these.

Perhaps my version should have a different name? WireMailMailgun3 and I could remove the fallbacks for the 2 branch?

Cheers,

Chris

  • Like 1

Share this post


Link to post
Share on other sites

Hi,

I see Mailgun have updated their API to version 4. I'm going to implement this then submit my version to the directory as a separate module - no idea what to call it though... maybe WiremailMailgunApi.

Cheers,

Chris

EDIT: turns out that it is only the email validation that's been updated to version 4...!

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Gadgetto
      SnipWire - Snipcart integration for ProcessWire
      Snipcart is a powerful 3rd party, developer-first HTML/JavaScript shopping cart platform. SnipWire is the missing link between Snipcart and the content management framework ProcessWire.
      With SnipWire, you can quickly turn any ProcessWire site into a Snipcart online shop. The SnipWire plugin helps you to get your store up and running in no time. Detailed knowledge of the Snipcart system is not required.
      SnipWire is free and open source licensed under Mozilla Public License 2.0! A lot of work and effort has gone into development. It would be nice if you could donate an amount to support further development:

      Status update links (inside this thread) for SnipWire development
      2020-01-21 -- Snipcart v3 - when will the new cart system be implemented? 2020-01-19 -- integrated taxes provider finished (+ very flexible shipping taxes handling) 2020-01-14 -- new date range picker, discount editor, order notifiactions, order statuses, and more ... 2019-11-15 -- orders filter, order details, download + resend invoices, refunds 2019-10-18 -- list filters, REST API improvements, new docs platform, and more ... 2019-08-08 -- dashboard interface, currency selector, managing Orders, Customers and Products, Added a WireTabs, refinded caching behavior 2019-06-15 -- taxes provider, shop templates update, multiCURL implementation, and more ... 2019-06-02 -- FieldtypeSnipWireTaxSelector 2019-05-25 -- SnipWire will be free and open source Plugin Key Features
      Fast and simple store setup Full integration of the Snipcart dashboard into the ProcessWire backend (no need to leave the ProcessWire admin area) Browse and manage orders, customers, discounts, abandoned carts, and more Process refunds and send customer notifications from within the ProcessWire backend Complete Snipcart webhooks integration (all events are hookable via ProcessWire hooks) Integrated taxes provider (which is more flexible then Snipcart own provider) Useful Links
      SnipWire in PW modules directory (alpha version only available via GitHub) SnipWire Docs (please note that the documentation is a work in progress) SnipWire @GitHub (feature requests and suggestions for improvement are welcome - I also accept pull requests) Snipcart Website  
      ---- INITIAL POST FROM 2019-05-25 ----
       
    • By d'Hinnisdaël
      Happy new year, everybody 🥬
      I've been sitting on this Dashboard module I made for a client and finally came around to cleaning it up and releasing it to the wider public. This is how it looks.
      ProcessWire Dashboard

      If anyone is interested in trying this out, please go ahead! I'd love to get some feedback on it. If this proves useful and survives some real-world testing, I'll add this to the module directory.
      Download
      You can find the latest release on Github.
      Documentation
      Check out the documentation to get started. This is where you'll find information about included panel types and configuration options.
      Custom Panels
      My goal was to make it really simple to create custom panels. The easiest way to do that is to use the panel type template and have it render a file in your templates folder. This might be enough for 80% of all use cases. For anything more complex (FormBuilder submissions? Comments? Live chat?), you can add new panel types by creating modules that extend the DashboardPanel base class. Check out the documentation on custom panels or take a look at the HelloWorld panel to get started. I'm happy to merge any user-created modules into the main repo if they might be useful to more than a few people.
       Disclaimer
      This is a pre-release version. Please treat it as such — don't install it on production sites. Just making sure 🍇
      Roadmap
      These are the things I'm looking to implement myself at some point. The wishlist is a lot longer, but those are the 80/20 items that I probably won't regret spending time on.
      Improve documentation & add examples ⚙️ Panel types Google Analytics ⚙️ Add new page  🔥 Drafts 🔥 At a glance / Page counter 404s  Layout options Render multiple tabs per panel panel groups with heading and spacing between ✅ panel wrappers as grid item (e.g. stacked notices) ✅ Admin themes support AdminThemeReno and AdminThemeDefault ✅ Shortcuts panel add a table layout with icon, title & summary ✅ Chart panel add default styles for common chart types ✅ load chart data from JS file (currently passed as PHP array) Collection panel support image columns ✅ add buttons: view all & add new ✅
    • By Robin S
      This module is inspired by and similar to the Template Stubs module. The author of that module has not been active in the PW community for several years now and parts of the code for that module didn't make sense to me, so I decided to create my own module. Auto Template Stubs has only been tested with PhpStorm because that is the IDE that I use.
      Auto Template Stubs
      Automatically creates stub files for templates when fields or fieldgroups are saved.
      Stub files are useful if you are using an IDE (e.g. PhpStorm) that provides code assistance - the stub files let the IDE know what fields exist in each template and what data type each field returns. Depending on your IDE's features you get benefits such as code completion for field names as you type, type inference, inspection, documentation, etc.
      Installation
      Install the Auto Template Stubs module.
      Configuration
      You can change the class name prefix setting in the module config if you like. It's good to use a class name prefix because it reduces the chance that the class name will clash with an existing class name.
      The directory path used to store the stub files is configurable.
      There is a checkbox to manually trigger the regeneration of all stub files if needed.
      Usage
      Add a line near the top of each of your template files to tell your IDE what stub class name to associate with the $page variable within the template file. For example, with the default class name prefix you would add the following line at the top of the home.php template file:
      /** @var tpl_home $page */ Now enjoy code completion, etc, in your IDE.

      Adding data types for non-core Fieldtype modules
      The module includes the data types returned by all the core Fieldtype modules. If you want to add data types returned by one or more non-core Fieldtype modules then you can hook the AutoTemplateStubs::getReturnTypes() method. For example, in /site/ready.php:
      // Add data types for some non-core Fieldtype modules $wire->addHookAfter('AutoTemplateStubs::getReturnTypes', function(HookEvent $event) { $extra_types = [ 'FieldtypeDecimal' => 'string', 'FieldtypeLeafletMapMarker' => 'LeafletMapMarker', 'FieldtypeRepeaterMatrix' => 'RepeaterMatrixPageArray', 'FieldtypeTable' => 'TableRows', ]; $event->return = $event->return + $extra_types; }); Credits
      Inspired by and much credit to the Template Stubs module by mindplay.dk.
       
      https://github.com/Toutouwai/AutoTemplateStubs
      https://modules.processwire.com/modules/auto-template-stubs/
    • By Mike Rockett
      Jumplinks for ProcessWire
      Release: 1.5.60
      Composer: rockett/jumplinks
      ⚠️ NOTICE: 1.5.60 is an important security patch-release for an XSS vulnerability discovered by @phlp. It's HIGHLY RECOMMENDED that all Jumplinks users update to the latest version as soon as possible.
      Jumplinks is an enhanced version of the original ProcessRedirects by Antti Peisa.
      The Process module manages your permanent and temporary redirects (we'll call these "jumplinks" from now on, unless in reference to redirects from another module), useful for when you're migrating over to ProcessWire from another system/platform. Each jumplink supports wildcards, shortening the time needed to create them.
      Unlike similar modules for other platforms, wildcards in Jumplinks are much easier to work with, as Regular Expressions are not fully exposed. Instead, parameters wrapped in curly braces are used - these are described in the documentation.
      Under Development: 2.0, to be powered by FastRoute
      As of version 1.5.0, Jumplinks requires at least ProcessWire 2.6.1 to run.
      View on GitLab
      Download via the Modules Directory
      Read the docs
      Features
      The most prominent features include:
      Basic jumplinks (from one fixed route to another) Parameter-based wildcards with "Smart" equivalents Mapping Collections (for converting ID-based routes to their named-equivalents without the need to create multiple jumplinks) Destination Selectors (for finding and redirecting to pages containing legacy location information) Timed Activation (activate and/or deactivate jumplinks at specific times) 404-Monitor (for creating jumplinks based on 404 hits) Additionally, the following features may come in handy:
      Stale jumplink management Legacy domain support for slow migrations An importer (from CSV or ProcessRedirects) Feedback & Feature Requests
      I’d love to know what you think of this module. Please provide some feedback on the module as a whole, or even regarding smaller things that make it whole. Also, please feel free to submit feature requests and their use-cases.
      Note: Features requested so far have been added to the to-do list, and will be added to 2.0, and not the current dev/master branches.
      Open Source

      Jumplinks is an open-source project, and is free to use. In fact, Jumplinks will always be open-source, and will always remain free to use. Forever. If you would like to support the development of Jumplinks, please consider making a small donation via PayPal.
      Enjoy! 🙂
    • By Robin S
      Add Image URLs
      Allows images/files to be added to Image/File fields by pasting URLs.

      Usage
      Install the Add Image URLs module.
      A "Paste URLs" button will be added to all image and file fields. Use the button to show a textarea where URLs may be pasted, one per line. Images/files are added when the page is saved.
       
      https://github.com/Toutouwai/AddImageUrls
      https://modules.processwire.com/modules/add-image-urls/
×
×
  • Create New...