Leaderboard

Pete and I have been using Postmark in some PW based projects at reasonable scale (>13k emails a month) and have found it to be an exceptionally good API-based transactional email provider with fast delivery times and great availability. It seems strange that there is no WireMail offering (as far as we know of anyway) that supports Postmark, so we thought we'd throw one together in case anyone else in the community wants to give Postmark a try. NB: This is not the code we use in our production systems, just a rainy-day project to fill a gap in the WireMail ecosystem. However, it should be sufficient to get you going with Postmark. We hope you find it useful and please let us know if you find any issues. WireMailPostmark module on Netcarver's github account. Screenshot from my test account:

These last few weeks I've been working on integrating a ProcessWire installation with the Fareharbor API for a client. Other than the authentication part (which is as simple as it gets), I've found this API to be one of the more time consuming ones to work with. It's not so much that the API is difficult to use, as much as it is just a time sink, taking a long time to reorganize the info it provides into something useful for our needs. And likewise taking a long time to prepare information to put back into it in the format it requires. My best guess is that it is an echo of an existing back-end API, projecting internals rather than tailoring a simpler public API to them. Perhaps it's an interface optimized for the some internal legacy system rather than the external consumers of it. Or perhaps it already is a lot simpler than what's behind it, and its interface has been carefully considered (even if it doesn't feel that way), who knows. To be fair, no API is perfect, and this particular API does provide a working and reliable interface to some pretty complex data, and an immense amount of power. It's good to work with lots of different APIs, from easy-to-painful, as it helps to clarify paths to take (and to avoid) when authoring new APIs. I ended up building an adaptor module in ProcessWire just to give this particular API a simpler interface that was more useful to the needs we had, and that is now saving us a lot of time. It reminded me of one reason why ProcessWire was built in the first place, to create a simple interface to things that are not-so-simple behind the scenes, and I think we've been pretty successful with that. We'll keep doing that as ProcessWire continues to mature, evolve and grow, as we always have. In terms of core updates, commits this week were similar to those from the last couple of weeks: a combination of issue fixes, a PR, feature requests and minor improvements. We are now 17 commits past 3.0.211, but I'm going to wait till next week before bumping the version to 3.0.212, as there's a little more I'd like to add first. Thanks for reading this update and I hope that you have a great weekend!

Where I am: Edit Page -> Settings -> Parent -> "+Change". Edit Field -> Page Reference field -> Input tab -> "Selectable pages (Select the parent of the pages that are selectable)" -> "+Change". ... and possibly other locations where the Page Tree is used. Quality of life improvement: When modifying Parent Pages (Edit Page) or Selectable pages (on a Page Reference field) and I press "+Change" to change the Parent Page, it would be nice if the current Parent Page came into focus without effort. Current solution: As an editor, I am required to find the Parent Page / "Page Reference parent page" manually which makes me think ("where did I put that page?"), takes a bit of time ("click, click, click"), and is hard on a larger site with a deep structure. The unmet goals are: I instantly see the context for the current Parent Page. I can effortlessly select another Parent Page. Constraints: Large website makes it hard to navigate and get a view of the Page Tree. I don't want to pick an incorrect Parent Page. It's sometimes difficult to see if I choose the right parent. The Parent Page must be in the current "Page Branch" ("/foo/bar/baz/" -> "/foo/quz/baz/"). I don't always need to see/browse the full Page Tree. Sometimes a lot of parent pages are unnessarily shown (larger websites with 4-5 levels of pages). Better: When I open the Edit Page / Edit Field page and click "+Change", I want the tree structure to expand (in a modal?) and bring the current Parent Page into focus. It's one of those small things that help create a smooth user experience. Additional thoughts: The displayed Page Tree only shows the current Page Branch; this might optionally be specified on the Template. Hide "unneeded" parent pages in a larger websites with 4-5 levels of pages (how?). Perhaps you have additional ideas that might improve working with Parent Pages when editing a page or a field?

@eydun what browser are you using? It's a mp4 file and should work on most browsers. EDIT: The forum seems to have problems with mp4 files. I added it to youtube instead..

Apologies for my rude response, @gebeer. No problem. Hope this week is better for you. My session stuff is still not fixed after solving the user/permission issues. This thread cleared up most of my PW session questions, so it must be something dumb in my script/templates.

There was a bug when editing the slider block (from PageGridBlocks module) in modal window. This is now fixed. Please try the lates version of "FieldtypePageGrid". You can add items to the slider from the children tab. Here I am adding an image but you can add every allowed template (configurable via permissions): Note: this block uses glide.js, a small and flexible vanilla JavaScript slider and carousel.

@Gideon So You are right there was a bug with the modal editing. This is now fixed. Please try the lates version of "FieldtypePageGrid".

It is odd that modern browsers do not support email validation following RFC 6530 out of the box. Popular PHP/JS libs like https://github.com/egulias/EmailValidator and https://www.npmjs.com/package/isemail/v/3.2.0 do support it. Seems like we would have to come up with a custom email input JS validator to make this work in the GUI. That is certainly something that @ryan would have to implement. Not sure how other CMS/Frameworks support this feature. But would be awesome if ProcessWire did.

Sorry if I was rude. I apologize. Had a bad day yesterday... From your other thread about Apache and suExec configuration it seems that most of the session stuff might also be user/permission related.

I have drafted a new PR for this feature. The backend implementation is simple enough. The description strings for sure need some work. See here: https://github.com/processwire/processwire/pull/259 It turns out, this is more complicated than anticipated because the browser validation fails. In order to test the new feature, I have to change the <input>'s type to text or the browser won't allow sending the form.

Edit: Solution is at the end of this comment, after a few educational dead ends. ? @gebeerI use EasyApache4; just standardized automated upgrade/changes on a VPS with a few PW websites that have been running fine for years. I have not improvised anything, not made any manual configuration changes. Of course there is a misconfiguration somewhere. I'm trying to find out where and created this thread to find out if anyone had seen something similar after PHP config changes. Here's one via a Google search - also uses CentOS, but with Apache vs Nginx issue, so problably not relevant. Thanks for the file permissions link. I'll see if I can fix my problem with that, but they're not clearcut instructions what ownership and permissions each folder/file should have. I see my Apache now runs as 'nobody'; I think it used to be/should be 'myusername'? My PW sites were installed as 'myusername' and all folders/files are owned by that 'myusername'. Edit: EasyApache apparently "updates" user settings or PHP handlers (?) and you have to turn that off? Here is a possible way to make Apache run as 'username' instead of 'nobody', I think, from 2012, so not risking that one... WHM has Apache mod_userdir Tweak where only 'DefaultHost (nobody)' has 'Exclude Protection' selected and all my other hosts/website have 'myusername'. No clue what to do with that info. Can I change DefaultHost to 'myusername' anywhere? There's this file on my CentOS server: # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! # DO NOT EDIT. AUTOMATICALLY GENERATED. USE INCLUDE FILES IF YOU NEED TO MAKE A CHANGE # !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! # # Direct modifications to the Apache configuration file WILL be lost upon subsequent # regeneration of this configuration file, or an Apache update. # # To have your modifications retained, you should create/edit administrator-specific # include files: # # /etc/apache2/conf.d/includes/pre_main_global.conf # /etc/apache2/conf.d/includes/pre_virtualhost_global.conf # /etc/apache2/conf.d/includes/post_virtualhost_global.conf ... # These are hard-coded values that are required by cPanel & WHM PidFile /run/apache2/httpd.pid User nobody Group nobody ... Tried changing 'nobody' to 'myusername' in pre_main_global.conf, empty file with only this: User myusername Group myusername And then run these two commands from root in SSH to rebuild httpd.conf and restart Apache: /usr/local/cpanel/scripts/rebuildhttpdconf /usr/local/cpanel/scripts/restartsrv_httpd One site that was giving me nasty 500 server errors is suddenly back, but that could also be because I changed permissions on all folders to 777 - bad for security... <?php echo exec('whoami'); ?> is still giving me 'nobody' as Apache user. Apache mod_userdir Tweak in WHM still has 'DefaultHost (nobody)'. Another clue here: 'If you install the suEXEC module, the system executes PHP applications as the user that owns the VirtualHost that served the request. If you uninstall the suEXEC module, the system executes PHP applications as the nobody system user.' mod_suexec is an Apache Module that can be enabled in EasyApache4. Enabling that seems to fix most issues I had. <?php echo exec('whoami'); ?> now give the correct 'myusername'. Edit: There is also another Apache Module mod_suphp that may be required to fix issues with some scripts.

That is not true anymore since 3.0.208. Docs for https://processwire.com/api/ref/sanitizer/email/ options say: I have verified that sanitizer accepts with the allowIDN option set to 2. $sanitizer->email('hans.müller@müller.com', ['allowIDN' => 2]; But the occurences of $sanitizer->email() in InputfieldEmail.module and FieldtypeEmail.module need to be adjusted to allow saving of those values to the DB. We are working on an app for an international corporation and need to import around 15.000 email addresses, some of which have characters like ä, ø etc. Their mailservers support these, so we have to support them also. I'm totally not into reading RFCs, but doing some research I found that since RFC6532 (2012) internationalized email headers are a standard and even the local part of the email can be in UTF-8. For anyone who wants to dig deeper, here are some links to get you started: https://stackoverflow.com/questions/69855149/email-with-special-characters-rejected-rfc-6532-and-quoted-printable https://github.com/roundcube/roundcubemail/issues/5120 https://www.rfc-editor.org/rfc/rfc6532

I'm dying to know, am I the only one bothered by (or maybe the only one seeing??) this line under the tabs now? ?

www.herzschlag-der-erde.de made with love and Processwire ???

Hello ProcessWire Community, It is with great pleasure that I share with you the new site for our company Strangeloop Studios, a visual design lab and animation studio based in Los Angeles. We specialize in content for musical artists but have branched into VR, Broadcast, and Music Video projects as well. This is my first site using ProcessWire. I went from complete PW beginner (October 2022) to this re-design and catalog of our various projects in the space of several months. Lurking here on the forums and visiting all of the stellar work that gets shared on the Showcases has taught me a lot. Many thanks to @bernhard for the Rockfrontend module, and @flydev for their Duplicator module. I probably wouldn't have been able to get this far without those … so, many thanks for your contributions! I also appreciate the feedback to my questions in the forums from several users who have improved my understanding of PW with detailed explanations. Things I would like to improve: optimizations for image delivery Multi-language support Looking forward to building more with ProcessWire! Cheers,

Just bumped this to version 0.5.0 which adds the ability to have a sandbox server token that gets used if the site is in debug mode.

Hello, I've just released a new module called PageimageSource which effectively supersedes PageimageSrcset. I've wanted to rewrite this module for a while now, to remove some features that I feel aren't necessary (e.g. UIkit widths / portrait mode), and have a more stripped back module that is more focused on specific functionality. I'd hoped to be able to do this by having a version 2.0.0, indicating breaking changes, but PW doesn't indicate this when upgrading, so the situation where users upgrade and things break would almost certainly happen. I therefore decided to rewrite the module and release it under a different name. I don't expect to do any more work on PageimageSrcset, but will apply any fixes as required. If you are starting from scratch on a project, PageimageSource is the one to use. If you are thinking to migrate a project using PageimageSrcset to PageimageSource, this list of changes should hopefully allow you determine if it is possible: The sizes() method/property has been removed The portrait mode has been removed (still possible through settings though - see the PageimageSource README for an example) UIkit widths -> sizes has been removed All the debug stuff has been removed The render() method behaves differently. It is more geared toward a <picture> implementation (requested by @teppo) Basically if all you've used is the default configuration and the srcset property, migration shouldn't cause any issues. Pretty much any other situation isn't suitable for migration. Cheers, Chris