Leaderboard

@ukyo - thanks for your work on this! Please don't take this as a criticism - it's an honest question - why did you decide to not extend WireMail? I am sure you have a good reason. I think there might be other reasons as well, but the first limitation I see is that Tracy's Mail Interceptor won't work with this, nor will the new Mail Debugger module. My other question is about your choice to make InputfieldHelper a requirement. I read through the support thread for that module and I still don't get it. I am sure I am missing something and it is probably very useful for certain tasks, but I do think it will be a barrier for getting people to install your WirePHPMailer module, especially when there is already three other working mail modules. Perhaps if you could better explain the advantages to this over those other mail modules, it might help. Cheers!

Several nice improvements over the last few days: 1) Major improvements to panel zIndex behavior - this should make things much less annoying - no more trying to get your panel of interest to be on top of another one. Mousing over the panel icon should now always bring it to the top, but with already open panels, now they only get promoted to the top if you click somewhere on the panel. Before it was onmouseover which made it quit annoying at times. Also panel order is remembered when reloading the page. 2) Console panel will no longer disappear if you use the keyboard shortcut to run code without having clicked somewhere on the panel first - much friendlier. 3) ESC key to close all open panels - I am finding this really handy already. I don't think this interferes with any other use of the escape key, but let me know if anyone thinks this should be optional. 4) Add test email address option to the Mail Interceptor panel - this was mentioned in another thread, but added here in case anyone missed it. If no address is entered, it behaves how it always did - it prevents the email from being sent and instead captures and displays what would have been sent. If you add a test email address, in addition to it's normal behavior, it also sends the email to the test address (but still not the original recipients). 5) Various bug fixes - especially in the Request Info panel when viewing certain module settings pages. As always, thanks for any feedback on these new features!

Thank you @horst for everything you have done for images in PW - you deserve way more recognition than you are getting!

I'd like to have more people see this as well. I'll let another moderator pin this if they see fit, but in the meantime we have 30 new stars since this post - much appreciated to everyone who took the time, but I am sure we can do much better! I promise I won't gratuitously bump this again

More updates! Here is what was added since my last post: FieldtypeDatetime now supports format argument. Which allows you to pass PHP date format string and retrieve your datetime values formatted the way you want. Besides FieldtypeDatetime fields, the built-in fields created and modified are also support new format argument. FieldtypeOptions is now supported. first and last fields on PageArray types are now supported. As per @eelkenet's request. See above post for details on those. Finally, now there is a way to add support for any fieldtype you want via third-party module. What you need to do is create a module with the name exactly as the fieldtype you want to add support for with "GraphQL" prefix. So for FieldtypeMapMarker it would be GraphQLFieldtypeMapMarker. Then you need to add three required methods and install it. This will automatically add GraphQL support for your desired fieldtype and it will be available in your GraphQL api. Checkout the documentation and an example module for reference.

PHPMailer for ProcessWire v3. Module Directory - Github repo I am author of WireMailPHPMailer. Old module using PHPMailer v5 and its extend WireMail base class. No more update will come for old version, but its still working :). This module using PHPMailer v6 and not extending WireMail base class. This module integrating the PHPMailer mailing library into ProcessWire v3. Usage almost same with original PHPMailer library (no need to include PHPMailer files). Here is a simple example usage : Using directly PHPMailer library $mail = wire("modules")->get("WirePHPMailer"); $mail = $mail->mailer(); $mail->addAddress("email@domain.ltd", "Someone"); $mail->isHTML(true); $mail->Subject = "WirePHPMailer"; $html = "<h1>WirePHPMailer</h1>"; $text = "WirePHPMailer"; $mail->Body = $html; $mail->AltBody = $text; $mail->send(); Using module like classic WireMail $mail = wire("modules")->get("WirePHPMailer"); $mail->from("from@domain.ltd") ->fromName("A From Name") ->to('email@domain.ltd') ->subject('A Message Subject') ->body('A Message Body') ->bodyHtml("<h1>A HTML Message Body") ->send(); Note : This module requires InputfieldHelper, PHP>=5.6.0, ProcessWire>=3.0.0 module.

So I made a mistake by not taking into account the ProcessWire's module naming convention. I totally forgot the fact that if module name starts with Fieldtype it becomes a fieldtype and PW will treat it like any other fieldtype. Like it would try to let you add a new field with that fieldtype. Which we do not want for our GraphQL extension modules. I already faced bugs because of this on admin side. So naming rule for GraphQL extension modules will be changed from suffixing the name with GraphQL to prefixing the name with GraphQL. So it is GraphQLFieldtypeMapMarker instead of FieldtypeMapMarkerGraphQL. Other than that, everything is the same as before. I'll also update the previous post to reflect this change. Sorry if this causes inconvenience to anyone. The updated version of ProcessGraphQL that works with new rules is available for use in latest release.

Have to agree with this. The biggest benefit with WireMail modules is that they unify the way email is sent within ProcessWire, and thus allow both third party modules (like Tracy, Mail Debugger, and a number of others) and built-in core features to a) automatically benefit from installed WireMail modules, and b) hook into that process in a consistent way if need be. I'd say that unless you've got a very good reason not to extend WireMail, you really should. That being said, thanks for your work on this module.

You don't need to set GET parameters or URL segments. (which is not exactly the same b.t.w.) Install LanguageSupportPageNames module and configure it for your needs. go to home page and set names for the home page. Use 'it' for default language and 'en' for english. Don't use 'home'. Don't leave empty. Access language code from $pages->get(1)->name for current user language and $pages->get(1)->getLanguageValue($language, 'name') for specified language. Get the URLs with $pages->get(1)->localUrl($language)

Hear, hear!

current state: https://github.com/processwire/processwire/commit/8fe1eb13f4cbc85c6d5dad093fc559c438c92667#commitcomment-27795259 - sadly I will not have more time this week.

Just wanted to let everyone know that I sent out an email to everyone who purchased Recurme with the updated Recurme Module Package. Thanks again to everyone who tested the changes and feedback. Especially @adrian

The key thing is that you changed hosts and now are having issues getting mail to work properly. You need to read up and review how mail is processed at your new hosting company. After finding out how mail works at the new host, you may have to make a few changes to your WireMailSMTP configuration screen to get things working. Additionally, your new hosting company should be able to verify that needed ports are opened (not blocked) for your account. Good luck.

Glad you made friends with Tracy > My PW version is 3.0.61 That might be the problem. I would definitely recommend upgrading to the latest dev version. Many of us are using it on production sites and it will likely become 3.1 stable this week or next.

Following on from my discoveries mentioned here, I have forked the Indexer Module referred to. Couple of reasons for this - Contrary to my thinking at the time of writing the post linked above, there was a deprecated/removed function in one of the files used. (Absolutely no idea why that wasn't apparent originally - must have been some code that isn't always called.) The module was set up to use executable parsers on the server for preference and only included a PHP parser for PDFs, not .doc, .docx etc word processor files. This is probably not optimal for shared hosting use as including your own executables is rarely, if ever, an option. The fork's repository is at https://github.com/DBPreston/Processwire-site-indexer. I have fixed the error due to use of split(), which was removed from PHP 7.0, and added a .doc parser so that it will now parse word processor files as well as PDFs and updated the module config page to reflect that. In the small amount of testing I have done so far, it seems to be working. Neither parser is perfect and the whole mode of operation of the module (adding a 'keywords' field to every page) may not be perfect for every use case, but it is certainly very useful in some instances. I should be very grateful if anyone has the time to give it some further testing, forking, pull requests etc.

I don't have any reason for not extending base WireMail class. This is why i updated module and now module extending bas WireMail class. Now you have 2 usage types: 1. Use directly PHPMailer class 2. Use extended send method For InputfieldHelper requirement, its easy to create configurable modules with this module and usable module for many cases, i won't remove requirement of this module. Like i mentioned, i am author of WireMailPHPMailer, i am not caring about module usage statics, if someone need PHPMailer module, they can use it. - I tested swift mailer module (smtp) - I tested base WireMail class (smtp) - I tested mailgun (curl) I am not prof. of mail sending but when i make simple mail send tests with same settings (mailgun not included), https://www.mail-tester.com/ test result not ok for me (problem with DKIM). My test result with PHPMailer 10/10, this is why i am using PHPMailer library with my modules.

I think it depends on what you do exactly. The example above: Objects : 794 / Execution time : 0.69733490943909 seconds Compared with this (titles autojoined): foreach ($pages->find('template=families') as $fam) { foreach ($fam->children() as $model) { foreach ($model->children() as $size) { echo ($fam->title . ' ' . $model->title . ' ' . $size->title . '<br>'); } } } Objects : 794 / Execution time : 1.6172688007355

I am using it for different cases. For modules (everything from a config file) : I am not defining default values as you see here : https://github.com/trk/WirePHPMailer/blob/master/WirePHPMailer.module#L33 Getting module configs : https://github.com/trk/WirePHPMailer/blob/master/WirePHPMailer.module#L77 Settings default values : https://github.com/trk/WirePHPMailer/blob/master/WirePHPMailer.module#L78 Merging module values with defaults, building inputfields : https://github.com/trk/WirePHPMailer/blob/master/WirePHPMailer.module#L119 - Its easy to build configurable module for me, no need to set all things on different places. For creating form you can see simple example usage on README.md I am using it for creating dynamic fields for page templates on runtime by hooking ProcessPageEdit::buildForm. In screenshots Settings and General tabs added dynamically and fields inside these tabs added by a config file. Use case change up to you.

@strandoo I pushed an update to github which should feed your needs. Please checkout.

Nice work @joshuag - looks like it's all sorted here!

It's not sRGB. Perhaps consider setting up a batch process in Photoshop to convert your supplied images to sRGB profile. Setting individual imageSizerOptions in config like that doesn't work. There are two options for overriding individual options in /site/config.php... $config->imageSizerOptions = array_merge($config->imageSizerOptions, ['upscaling' => false]); ...or... $config->imageSizerOptions('upscaling', false);

Inputfield::renderReady was made hookable as Inputfield::renderReadyHook in PW 3.0.44. So the module could be updated to hook after InputfieldPage::renderReadyHook instead of before InputfieldPage::render - then it will work with repeater fields. That would add a requirement of PW >= 3.0.44, or else the module could check the PW version and hook different methods depending on the version.

Hi everyone, I know we'd all like to see ProcessWire grow in popularity (maybe not hugely, but just enough that more people know about it which can help to convince clients to go with it). It strikes me as strange that the ProcessWire Github repo still has less than 300 stars - I'd like to see us well over a thousand which should be an easy task for the forum members to achieve. I see so many other projects with lots of stars but for some reason it doesn't seem like it is something we tend to do around here, despite being a very active, friendly, and supportive environment. I also think that starring your favorite modules doesn't hurt either - I think that will also help to increase the visibility from PW and also help out module authors a little as well. If you can show your Github project has a decent number of stars it shows that you are building things that people want which can help you land a job and helps you to convince the client that you and ProcessWire are a good mix. Anyway, if you have a minute to do some starring of PW and your favorite modules, hopefully it will benefit us all a little. Thanks!

I've gone this way leveraging on shell scripts to automate things (update files in the multiple site/templates folder) and if I need to add fields or anything database related, I use Migrations module which includes a CLI to run migrations on multiple installations without going through the graphic interface.

Thanks Robin - you saved me some time figuring this out - much appreciated. I have pushed this change to my fork here: https://github.com/adrianbj/processwire-fieldtype-assisted-url

It does work with dev version 3.0.93 Thanks a lot for your assistance, @adrian

I did not modify it. I didn't even think of it, but it's a good idea. I'll do a quick update on that. Thanks!

hi @ukyo thanks for the phpmailer module - I've built one my own since I was not happy with the other options, but it was not polished enough to release it I'm not sure, though, what is the difference between your inputfieldhelper and the default module config? https://processwire.com/blog/posts/new-module-configuration-options/#using-an-array-to-define-module-configuration you can also add fields to a form via array:

You can use $pageimages->add() to add images to a field. $page->image_field->add('/full/path/to/image.jpg'); ...or... $page->image_field->add('http://domain.com/url/to/image.jpg'); But seeing as you will probably want to replace the existing image while keeping the same name you might want to use the PW admin to drop the new image onto the existing one. Not sure if there is an equivalent for doing that via the API.

@thomasaull Works great! You say tomato and I say tomato One thing about putting the classes in templates rather than a module is that they can be modified to suit. I tweaked the new ApiHelper to make it more ProcessWire-ish for my own benefit - still does the same thing as your version. public static function checkAndSanitizeRequiredParameters($data, $params) { $sanitizer = wire('sanitizer'); foreach ($params as $param) { // Split param: Format is name|sanitizer method $name = explode('|', $param)[0]; // Check if Param exists if (!isset($data->$name)) throw new WireException(_("Required parameter: '$param' missing!"), 400); // Sanitize Data $parms = explode('|', $param); $sanMethod = 'text'; if (isset($parms[1])) $sanMethod = $parms[1]; if(!method_exists($sanitizer, $sanMethod)) throw new WireException(_("Sanitizer: '$sanMethod' is invalid for param '$name'"), 400); $data->$name = $sanitizer->$sanMethod($data->$name); } return $data; } Thanks for the update.

This is all super helpful, Robin. I think that imageSizerOption setup is working now. Hero. Thank you. As I'd need to re-upload all these images again to get the new options... is there a good way to do this via the API?

I think I have finally fixed this! woot woot. Thanks @adrian for all your help. I have attached a new .js file. Let me know if that works for you. rrule-gui.js

http://modules.processwire.com/modules/admin-page-field-edit-links/

module admin page field edit links

Perhaps you could use mystyles.php with JavaScript content type header and include site specific js files from there? I'm not sure if this would work though but there's a chance.

It's all in the documentation here . Please also read the last couple of post above yours. Since your site uses various languages, you need to pass render() either the ID of your menu, its Page object or an array of menu items. As per the post above yours, this limitation will be resolved in an upcoming update.

Besides the validation inside InputfieldPage there is also validation done by the specific inputfield type used in the field (e.g. AsmSelect, SelectMultiple, etc). I forgot about this. Many of these extend InputfieldSelect and so use the processInput method there. So whatever pages you are showing in the Page Reference field have to be one of the $options for that inputfield (e.g. see InputfieldSelect::isOption method). So I think your problem is coming from this part... Whatever pages you restrict to here are the only ones that will pass validation. So rather that limiting the options with this hook you might need to come up with other strategy for hiding the options. For example, hide unwanted options with JS, or trigger a change on the source Page Reference field on load so your dependent select kicks in right from the start.

Totally support and bump to "Latest Topics". EDIT: Sad it does not work . It would be great if this topic could be more visible.

The issue is that PW's .htaccess file contains mod_rewrite rules that get executed before any mod_alias redirects. This article explains: So that advice applies here - it's better to do redirects using mod_rewrite so that you can use the [L] flag to prevent other rewrite rules affecting the redirect.

I understand a little better now, but your usage is not how view permissions are intended to be used. Suppose you had a different setup for storing a user's date of birth: a text field for day and month, and a text field for year. I'm not suggesting that you do this - it's just to illustrate how view permissions typically work. In this alternative setup you might apply view permissions for the year field - so it would or wouldn't be viewable depending on role. But in your setup the "hide_year_of_birth" field is not a field that it is useful to limit the viewing of, because it only holds a 1 or a zero and not the actual value you want to hide (the year of birth). Hiding the checkbox field just confuses things IMHO, and would cause problems if any of the users with view restrictions need to edit the "hide_year_of_birth" field in their own profile (you can't edit a field that you can't view). I think instead you should create a new custom permission "view_year_of_birth" and apply it to the relevant roles. Then check for that permission (and the "hide_year_of_birth" value) to determine how the date field should be formatted.

On the topic of searchability of encrypted fields, as long as the number of encrypted pages you want to search across is not too huge you can load the pages to a PageArray and then search the PageArray. Using the auto-join tip mentioned recently here by @thetuningspoon... $decrypted = $pages->find("template=some_template", ['loadOptions' => ['joinFields' => ['encrypted_field_name']]]); $items = $decrypted->find("encrypted_field_name%=foo");

$first = $selectWatch->eq(0); $second = $selectWatch->eq(1); $third = $selectWatch->eq(2); https://processwire.com/api/ref/wire-array/eq/

A few more enhancements: It now handles local links with query string parameters - the stored link is still converted to a page ID with the query string appended. You can now also paste full http(s) links and if these are local links, they will be converted to a page ID and a local link will be returned when the value is requested.

Well, I am using this field for the first time and really wanted this functionality, so decided to fork the module here: https://github.com/adrianbj/processwire-fieldtype-assisted-url It doesn't look any different from the users perspective, but on save/sleep it stores the page ID instead of the url and then on wakeup it converts to ID back to the URL. This means that you can now move a page to a different parent, rename it, etc and the link URL will be automatically updated. It doesn't look like @wumbo is still active around here, so not sure if this will make it into the main version of the module, but it's there if others want it.

Hey @eelkenet! That seems reasonable to me. I was planning to add those fields. Didn't have time till now. I'll let you know as soon as I implement them. You won't be able to add those fields via getQuery hook btw. The getQuery hook is there for very trivial custom fields to be honest. Like your api version number, or your contact data or anything you want to send via GraphQL api without creating templates, fields and pages for it.

I can confirm the problem. When the inputfield is inside a repeater item the module tries to open the link modal for the repeater page, but non-superusers do not have direct access to repeater pages. The core link modal (opened from CKEditor) does not have this problem because in the case of being inside a repeater item it opens the link modal for the container page instead. You can apply the same logic to this module by editing InputfieldAssistedURL.module, changing line 62... $btn->attr('data-page-id', $this->page->id); ...to (edit: there could be multiple nested repeaters, so best to borrow the code from ProcessPageEditLink)... $page = $this->page; $n = 0; while(wireInstanceOf($page, 'RepeaterPage') && ++$n < 10) { $page = $page->getForPage(); } $btn->attr('data-page-id', $page->id);

Yep @ryan's method working perfect. $config->imageSizerOptions('cropping', 'north'); $config->imageSizerOptions('sharpening', 'none'); $config->imageSizerOptions('quality', 80); $config->imageSizerOptions('defaultGamma', -1);

You would think this would work, but if you test it I think you'll find that individual keys set like this have no effect. However, Ryan recently alerted me to this working alternative for setting individual keys: $config->imageSizerOptions('cropping', 'north');

For each filter you have, you create a field and add it to the product template. You also add the filters page field. Now you set up each filter field to only show if it was selected in the filters page field. http://processwire.com/api/selectors/inputfield-dependencies/#example-page You can automated the creation of the fields by hooking the page save and creating a filter field when a filter page is added.

I think this method will work even if you expand it out. I changed a few things up, but hopefully it makes sense. Product pages use "template product", all other catalog pages use "template catalog". Catalogue -- Men ---- Shoes ------ Product 1 ------ Product 2 ---- Hats ------ Product 1 ------ Product 2 -- Women ---- Shoes ------ Product 1 ------ Product 2 ---- Hats ------ Product 1 ------ Product 2 Categories (these pages only a template with a title field) -- Brands ---- Brand 1 (title only template) ---- Brand 2 (title only template) -- Type ---- Type A (title only template) ---- Type B (title only template) -- Collections ---- Collection A (title only template) ---- Collection B (title only template) catalogue.php template & product.php template (same contents) <?php /* There might be a better way to accomplish this. The only reason to have 2 templates is to give find() a way * to only return the actual product pages, and not all the parent pages as well. * * update: You may want to look into using the alternative template method: * * * With this approach you would create a real file (product.php) for the product template, * catalogue template would have no file associated, but point to product.php under the advanced settings tab. */ include("./site/templates/head.inc"); include("./site/templates/product-view.inc"); include("./site/templates/foot.inc"); product-view.inc <?php $brand = ""; $type = ""; $collection = ""; if ($input->urlSegment1) $brand = ",brand.name=".$input->urlSegment1; if ($input->urlSegment2) $type = ",type.name=".$input->urlSegment2; if ($input->urlSegment3) $collection = ",collection.name=".$input->urlSegment3; if ($input->urlSegment4) { // if Segment 4, then we know what page to get $product = $pages->get("name=$input->urlSegment4"); echo $product->title; } else if ($input->urlSegment1){ // check if we are using URL segments if ($input->urlSegment1 == "all"){ $products = $pages->find("has_parent=$input->urlSegment2, template=product"); } else { $products = $pages->find("has_parent=$page->path, template=product, . $brand . $type . $collection"); } foreach ($products as $p){ echo $p->title; } } else { $products = $pages->find("has_parent=$page->path, template=product"); foreach ($products as $p){ echo $p->title; } } Looking at example URLS to see how the selector would get populated: /catalogue/brand1/ Brand1 is a url->segment1 so the elseif evaluates to true, and the selector gets populated to become: $products = $pages->find("parent=/catalogue/, template=product, brand.name=brand1"); /catalogue/brand1/casual/ elseif evaluates to true, and the selector gets populated to become: $products = $pages->find("parent=/catalogue/, template=product, brand.name=brand1, type.name=casual"); /catalogue/brand1/casual/trendy/ $products = $pages->find("parent=/catalogue/, template=product, brand.name=brand1, type.name=casual, collection.name=trendy"); /catalogue/men/ $products = $pages->find("has_parent=men, template=product"); /catalogue/all/shoes/ $products = $pages->find("has_parent=shoes, template=product"); /catalogue/all/hats/ $products = $pages->find("has_parent=hats, template=product"); /catalogue/men/shoes/ no URL segment here, so the if/elseif are false, so we get: $products = $pages->find("has_parent=/catalogue/men/shoes/, template=product"); /catalogue/men/shoes/brand1/ Brand1 is a url->segment1 so the elseif evaluates to true, and the selector gets populated to become: $products = $pages->find("parent=/catalogue/men/shoes/, template=product, brand.name=brand1"); you get the idea. Again, untested and coded in the browser — but hopefully thought out enough to get you started.