Leaderboard

ProcessWire 3.0.146 contains about 22 commits (relative to 3.0.145) and these commits are largely focused on resolving reports from the processwire-issues repository. However, there have also been several improvements and related additions. One of these additions was a foundational upgrade that adds support for Fieldtype modules to use a custom class for Field objects. This will open more possibilities for improved Field/Fieldtype-specific APIs. Several have asked for improvements in the APIs of Repeaters and other fields, so this is a step that begins the lay the tracks for moving in that direction. Traditionally the API calls for working with Fields and Fieldtypes have not been nearly as simple as those that work with Pages, so this will be an upgrade that narrows and eventually eliminates that gap, longer term. On the core side, I currently plan on using this to improve the API for Repeaters, Comments and Options fields, and perhaps others. Outside of the core, ProFields will eventually take advantage of custom Field objects as well. As usual, none of this will break any existing code, but it will add simplicity for those that work with Field/Fieldtype APIs in ProcessWire. As for other changes in 3.0.146, I think last week’s ProcessWire Weekly did a great job of covering them, so if you are interested be sure to check that out. Next week is partially a holiday week here in the US, so I’ll be on a little bit of a reduced schedule, but will still be working on the core. I’m also releasing a new module into the ProDevTools set of modules next week, so I’ll tell you more about that one in next week’s blog or forum post. Thanks for reading and have a great weekend!

Hello. I'd somewhat rewritten WireMailMailgun a while back, to implement some more features and implement PW coding guidelines etc. My version has been somewhat in limbo, although there's been various discussions in the thread linked above. I've decided to release my version as a separate module called WireMailgun, as it has breaking changes and a slightly different implementation. I've also got it using the email validation v4 endpoint. For simple usage, either module will do what you need it to do. If you need to do some more advanced things e.g inline images or adding data, this module will help you with that. Here's the readme... WireMail Mailgun Extends WireMail to use the Mailgun API for sending emails. Installation Download the zip file at Github or clone the repo into your site/modules directory. If you downloaded the zip file, extract it in your sites/modules directory. In your admin, go to Modules > Refresh, then Modules > New, then click on the Install button for this module. API Prior to using this module, you must set up a domain in your Mailgun account to create an API key. Add the API key and domain to the module's settings. Usage Usage is similar to the basic WireMail implementation, although a few extra options are available. Please refer to the WireMail documentation for full instructions on using WireMail, and to the examples below. Extra Methods The following are extra methods implemented by this module: Chainable The following methods can be used in a chained statement: cc(string|array|null $email) - Set a "cc" email address. Only used when $batchMode is set to false. Please refer to WireMail::to() for more information on how to use this method. bcc(string|array|null $email) - Set a "bcc" email address. Only used when $batchMode is set to false. Please refer to WireMail::to() for more information on how to use this method. addData(string $key, string $value) - Add custom data to the email. See https://documentation.mailgun.com/en/latest/user_manual.html#attaching-data-to-messages for more information. addInlineImage(string $file, string $filename) - Add an inline image for referencing in HTML. Reference using "cid:" e.g. <img src='cid:filename.ext'> Requires curl_file_create() (PHP >= 5.5.0) See https://documentation.mailgun.com/en/latest/user_manual.html#sending-inline-images for more information. addRecipientVariables(array $recipients) - Add recipient variables. $recipients should be an array of data, keyed by the recipient email address See https://documentation.mailgun.com/en/latest/user_manual.html#batch-sending for more information. addTag(string $tag) - Add a tag to the email. Only ASCII allowed Maximum length of 128 characters There is a maximum number of 3 tags allowed per email. addTags(array $tags) - Add tags in a batch. setApiKey(string $apiKey) - Override the Mailgun API Key module setting. setBatchMode(bool $batchMode) - Enables or disables batch mode. This is off by default, meaning that a single email is sent with each recipient seeing the other recipients If this is on, any email addresses set by cc() and bcc() will be ignored Mailgun has a maximum hard limit of recipients allowed per batch of 1,000. Read more about batch sending. setDeliveryTime(int $time) - The (unix)time the email should be scheduled for. setDomainName(string $domain) - Override the "Domain Name" module setting. setRegion(string $region) - Override the "Region" module setting. Valid regions are "us" and "eu" Fails silently if an invalid region is passed setSender(string $domain, string $key) - Set a different API sender than the default. The third argument is $region which is optional A shortcut for calling setDomainName(), setApiKey() and setRegion() setTestMode(bool $testMode) - Override the "Test Mode" module setting. setTrackOpens(bool $trackOpens) - Override "Track Message Opens" module setting on a per-email basis. Open tracking only works for emails with bodyHTML() set setTrackClicks(bool $trackClicks) - Override "Track Message Clicks" module setting on a per-email basis. Click tracking only works for emails with bodyHTML() set Other send() - Send the email. Returns a positive number (indicating number of emails sent) or 0 on failure. validateEmail(string $email) - Validates a single address using Mailgun's address validation service. Returns an associative array. To return the response as an object, set the second argument to false For more information on what this method returns, see Mailgun's documentation. getHttpCode() - Get the API HTTP response code. A response code of 200 indicates a successful response Examples Basic Example Send an email: $mg = $mail->new(); $sent = $mg->to("user@domain.com") ->from("you@company.com") ->subject("Message Subject") ->body("Message Body") ->send(); Advanced Example Send an email using all supported WireMail methods and extra methods implemented by WireMailgun: $mg = $mail->new(); // WireMail methods $mg->to([ "user@domain.com" => "A User", "user2@domain.com" => "Another User", ]) ->from("you@company.com", "Company Name") ->replyTo("reply@company.com", "Company Name") ->subject("Message Subject") ->bodyHTML("<p>Message Body</p>") // A text version will be automatically created ->header("key1", "value1") ->headers(["key2" => "value2"]) ->attachment("/path/to/file.ext", "filename.ext"); // WireMailgun methods $mg->cc("cc@domain.com") ->bcc(["bcc@domain.com", "bcc2@domain.com"]) ->addData("key", "value") // Custom X-Mailgun-Variables data ->addInlineImage("/path/to/file-inline.jpg", "filename-inline.jpg") // Add inline image ->addTag("tag1") // Add a single tag ->addTags(["tag2", "tag3"]) // Add tags in a batch ->setBatchMode(false) // A single email will be sent, both "to" recipients shown ->setDeliveryTime(time() + 3600) // The email will be delivered in an hour ->setSender($domain, $key, "eu") // Use a different domain to send, this one in the EU region ->setTestMode(true) // Mailgun won't actually send the email ->setTrackOpens(false) // Disable tracking opens ->setTrackClicks(false); // Disable tracking clicks // Batch mode is set to false, so 1 returned if successful $numSent = $mg->send(); echo "The email was " . ($numSent ? "" : "not ") . "sent."; Validate an Email Address $mg = $mail->new(); $response = $mg->validateEmail("user@domain.com", false); if($mg->getHttpCode() == 200) { echo $response->result == "deliverable" ? "Valid" : "Not valid"; } else { echo "Could not validate"; } I hope it is useful! Cheers, Chris

If I use Tracy to do a test dump in FieldtypePage::wakeupValue (which is where the stored IDs are loaded into a PageArray) then it seems that this method executes regardless of the visibility of the field in Page Edit. And it's not Page Edit that's the main problem anyway. If you have a field then presumably you want to work with that field, but whenever you do... $page->my_pr_field ...then all the pages are loaded to memory. So for instance if you want to add a page via the API... $page->my_pr_field->add($p) ...then you are automatically loading all the pages to memory. @bernhard's suggestion and @teppo's module are good workarounds but I think it's important to get a core solution to this. PW has an "everything is a page" philosophy, so pages can be any unit of data, not necessarily a viewable page of content. And Page Reference fields are the fundamental way to make connections between pages in PW. So when you have thousands of pages that need to have connections to thousands of other pages then you have to start looking beyond the core fieldtypes which is a limitation for PW. Sometimes you can do what @wbmnfktr suggested and reverse the connection, putting the PR field in the other template to reduce the number of pages stored per field. But this isn't always possible. In terms of concrete examples, imagine you were using PW to build some kind of Spotify-like database that tracks users' listening habits. There could be thousands of users who listen to thousands of songs, so either way you cut it you want to store thousands of pages in a PR field.

New Version Release: 1.0.3 - Improves performance for FieldtypeFile & FieldtypeImage fields. @dragan Looking forward to your feedback. I'm still very curious how you managed to get 6s response time from GraphQL. Let me know how the latest version works for you. @nbcommunication That's great to hear! Any involvement is absolutely welcome. If you have your module available on github or some other place I would love to look at your approach and maybe steal some ideas ?. Also, if your implementation is different than mine I would encourage you to finish it. We will only benefit from different approaches.

I actually see I did that already ?So feel free to leave out the static method call above and let me know if it works.

So I've been a bit busy this morning refactoring and brooming. A man is busy of late, but hey, gotta make some time for these things eventually. Anyways, couple of things I've done so far: Updated the underlying sitemap package. Refactor: split some code out into concerns, added support helpers, added return types and fixed up doc blocks. Dropped support for PW 2.8 and PHP < 7.1 (should be 7.2, but fine for now) Manually pulled in the merge request with an additional static method to add the language support hooks. I don't really have a good test case to work with, but this is the idea: use MarkupSitemap; wire()->addHookAfter(MarkupSitemap::getAdditionalPages, function ($event) { $page = $event->arguments(0); $language = $event->arguments(1); MarkupSitemap::applyLanguageSupportHooks(); // Add additional pages }); It should internally track whether or not they've been added, but I've simply not tested it yet, so can't say for sure. ?That aside though, surely I can add the hooks directly in ___getAdditionalPages? If you'd like to give it a spin, please check out the develop branch directly.

RockAwesome ProcessWire Fieldtype to easily choose FontAwesome Icons Usage Install the module. Set paths in the Inputfield's settings page. Add a RockAwesome field to any template (or change an existing TEXT field). Preview https://modules.processwire.com/modules/fieldtype-rock-awesome/ https://github.com/BernhardBaumrock/RockAwesome

Just gave it a try — works like a charm! Thanks for merging so quickly. A thought on the hook name: would it make more sense to call it getAdditionalPageUrls (including "urls") to clarify it's returning additional URLs for a specific page? One might need a hook at some point to get additional pages independent of any other page (who knows why), which would then appropriately be called getAdditionalPages.

@Mike Rockett @teppo I created a merge request on GitLab. Happy to get some input on that. It includes an example implementation and an updated readme section on dynamic URL segments. One thing that I couldn't figure out is creating alternate-language URLs inside the hook. The LanguagePageNames module doesn't create the hooks for Page->localHttpUrl() if the requested page results in a 404 error (which it always does when generating the Sitemap since that's what triggers it). That's why the Sitemap module manually adds those hooks when initializing. However, even when the module has been initialized and the hooks should have been added by that point, localHttpUrl() is not available on any Page object inside the hook. I worked around that in my previous project by doing the same as the Sitemap module and adding the localUrl methods manually. It's however far from an ideal solution to have to add all that boilerplate. Any ideas? wire()->addHookAfter('MarkupSitemap::getAdditionalPageUrls', function ($event) { /* get arguments */ static $hooksAdded = false; if (!$hooksAdded) { foreach (['localUrl', 'localHttpUrl', 'localName'] as $pageHook) { $pageHookFunction = 'hookPage' . ucfirst($pageHook); wire()->addHook("Page::{$pageHook}", null, function ($event) use ($pageHookFunction) { wire('modules')->LanguageSupportPageNames->{$pageHookFunction}($event); }); } } $hooksAdded = true; /* add URLs */ }); I started working on the video element feature, but that's not as straightforward as I thought.

Just for the record (not saying that it would be the best solution overall), FieldtypePageIDs also has certain benefits if/when the problem is loading too many Page objects into memory. It could be worth looking into in this sort of situation ?

I'm glad you believe @Robin S if you didn't want to believe me ? Just create a custom $page method that does your logic, then you have your own performant API. That should get you started: $wire->addHook("Page::readByUser", function($event) { $result = $this->database->query("SELECT id,templates_id FROM pages LIMIT 5"); $ids = $result->fetchAll(\PDO::FETCH_OBJ); $user = $event->arguments(0); d("check for user $user"); $event->return = $ids; }); d($page->readByUser($user));

Haha, I spent last week working on a GraphQL API module built upon the webonyx library! Not wasted time though, I think I've probably implemented a few things that would be welcome additions (e.g. WireCache for $pages->find()). When I get a chance I'll have a look at the new version of this module and see whether I can suggest any additions. Cheers, Chris

@AndZyk, a Page Reference field doesn't scale well because all pages are loaded into memory and there is no ability to limit the loaded pages or paginate the inputfield in admin. Back in 2016 Ryan said it was likely that pagination would be added to several core fieldtypes but it hasn't happened yet: https://processwire.com/blog/posts/fieldtype-pagination/ The Page Reference fieldtype/inputfield is the one that would benefit the most from this. I have an open request for this that you could add your voice to: https://github.com/processwire/processwire-requests/issues/13

This is a really nice module, but why is the fully working version only in the 'dev' release? EDIT: Having said that, I now find I have the same problem as the previous poster. It all works fine on my Dev machine. But in the live environment it is blank. EDIT 2: In my case, the problem was simple - just forgot to upload the additional lines in the <head> - i.e. <?php $map = wire('modules')->get('MarkupLeafletMap'); ?> <?php echo $map->getLeafletMapHeaderLines(); ?> Is that your problem @Leftfield?