Leaderboard

This week I’ve been working on updates for ProcessWire 3.0.168 as well as a new Stripe payments module for FormBuilder. In the core, the ProcessPageView module that handles all requests got a pretty significant refactoring. While it was largely focused on optimization, I also just like to go in every few years and rewrite stuff in high traffic modules like this to keep the module fresh, as well as keep my mind fresh on how it all works. I find there’s often room to do something better. The ProcessLogin module also got some upgrades this week that are primarily focused on maintaining the contents of a request URL in the admin between guest and admin user states. Now it can retain most query strings in a request URL after login. There’s still more to do in 3.0.168 so the version bump isn’t being made this week but may be ready next week. So far there are also a couple of GitHub issue resolutions and $sanitizer method improvements as well. On the FormBuilder side, we have the Stripe payments Inputfield, but since that module has been built, Stripe has released new APIs to handle SCA payments (soon required for EU transactions). With these types of payments, as I understand it, a multi-factor type process takes place where the user confirms the transaction with their credit provider. So it changes the payment flow quite a bit… enough that I’ve found the current Stripe payments module can’t really be adapted for it, at least not in a reliable way. That’s because the new API requires that the payment take place interactively before the form is submitted, since the user has to manually confirm it outside the form. So this will inevitably lead to cases where a payment has been charged but the final form isn’t submitted for one reason or another. Maybe it would work most of the time, but it just doesn’t seem like a reliable transaction flow to me. For this reason, I’m building a separate module for FormBuilder that provides a better alternative for the SCA transactions. With this module, the user submits the form, but FormBuilder saves it as a partial/pending form submission. Following form submission, the user goes through the SCA payment process with Stripe. When that completes, Stripe sends a webhook to FormBuilder that converts the form submission from pending to completed, at which point emails are sent, FormBuilder actions executed, etc. So it's Stripe that submits the final form, rather than the user. I’ve got a lot of work still to do here, but since a few people have contacted me looking for SCA support with Stripe payments, I just wanted to keep you up to date and let you know it’s in progress. The existing InputfieldFormBuilderStripe module will of course continue to be developed as well, as most regions outside the EU do not require SCA. Thanks for reading and have a great weekend!

This is a bit of a border case on this forum, I know — but it's also such a great event that I wanted to share it anyway: https://wpaccessibilityday.org/. In short this is a currently ongoing 24 hour streaming video / webinar event with loads and loads of accessibility focused talks. I'm writing this right after the first talk, so you haven't missed much if you jump in now (and again, it's a 24 hour event, so there's a lot more to come). Direct link to the stream: https://www.youtube.com/watch?v=X0BcKR2Go1E. Some of the talks are obviously pretty WP centric, but based on the schedule I'd say that the majority of the content should apply to just about all regular websites, as well as content management platforms in general ?

Hey folks! Just wanted to mention that ProcessRedirects 2.0.0 is now out. As far as I can tell it should fix most of the issues that have been reported here, as well as those reported via GitHub. This is a major update and the module now requires ProcessWire 3.0.112+ and PHP 7.1+, so please keep that in mind if and when updating ? Here's a kind-of-a-changelog for this release from the PR that got merged earlier today: In case anyone is wondering why update this module now even though we already have a very powerful alternative (Jumplinks), the thing is that this module still serves a purpose: it's super easy to use, and does what it needs to do — no more, no less. Powerful features can be a double-edged sword, as they also tend to increase complexity, at least to some extent. When it comes to "power users", Jumplinks is by far a superior tool, but for regular content editors who just need the occasional shortlink (or something similar), this module is often just the right fit. Hope that makes sense. Anyway, I still have some relatively minor additions in mind that I'd like to add to the module (assuming that Antti thinks they are a good fit), but again, for the most part this module already does what it needs to. Power users will likely feel more at home with Jumplinks ? If you find a bug or have a feature in mind that this module really needs to have, feel free to open an issue at the GitHub repository. Thanks!

Important update: I've just updated to module to version 2.0.0 which fixes the issues with the API requests and makes the module work correctly again. However, the module now requires ProcessWire 3.0.167 or above! Read on below for an explanation. Since publishing this module, I ran into several problems with API requests not working correctly. I found that the reason was both an issue with the way the module formats it's API requests, as well as some issues with ProcessWire's cURL implementation, which means that some requests wouldn't work correctly (namely PUT and DELETE requests). I then submitted a pull request to the ProcessWire core which fixes those issues, which were thankfully accepted by ryan. The fixes are now live and available in ProcessWire 3.0.167, and I've updated the TrelloWire module to fix some internal issues as well, so the module should now work correctly once again. Unfortunately, this means that ProcessWire versions below 3.0.167 won't work correctly. New options: Switch the network implementation used by the module There's a new configuration option available that you can use to force the module to use cURL, fopen or socket connections respectively. Check out the documentation for usage information! If you can't update to 3.0.167 ... You can still install and use the module on older ProcessWire versions (though the installation will ask for confirmation if you are below 3.0.167). The module will try to use fopen to connect to the API on any ProcessWire installation below 3.0.167, but I can't promise it will work correctly. You can also try socket connections using the configuration option above, but I couldn't get it to work in my test environment. Let me know if you need support or something isn't working for you! @maddmac Just tagging you to let you know you don't need to use the dev branch from Github anymore ?

I'm not surprised that 1000 repeater items in a field is slow to load. My suggestion is to replace your repeater field with child pages.

Typical. Just as I submit the topic, I find the solution. Turns out I just made a CamelCase boo boo with the filename: Defaultpage.php had to be DefaultPage.php. Sorry to waste your time.

I think the only field that works this way is @kongondo 's Media Manager.

Hello all, sharing my new module FieldtypeImageReference. It provides a configurable input field for choosing any type of image from selectable sources. Sources can be: a predefined folder in site/templates/ and/or a page (and optionally its children) and/or the page being edited and/or any page on the site CAUTION: this module is under development and not quite yet in a production-ready state. So please test it carefully. UPDATE: the new version v2.0.0 introduces a breaking change due to renaming the module. If you have an older version already installed, you need to uninstall it and install the latest master version. Module and full description can be found on github https://github.com/gebeer/FieldtypeImageReference Install from URL: https://github.com/gebeer/FieldtypeImageReference/archive/master.zip Read on for features and use cases. Features Images can be loaded from a folder inside site/templates/ or site/assets Images in that folder can be uploaded and deleted from within the inputfield Images can be loaded from other pages defined in the field settings Images can be organized into categories. Child pages of the main 'image source page' serve as categories mages can be loaded from any page on the site From the API side, images can be manipulated like native ProcessWire images (resizing, cropping etc.), even the images from a folder Image thumbnails are loaded into inputfield by ajax on demand Source images on other pages can be edited from within this field. Markup of SVG images can be rendered inline with `echo $image->svgcontent` Image names are fully searchable through the API $pages->find('fieldname.filename=xyz.png'); $pages->find('fieldname.filename%=xy.png'); Accidental image deletion is prevented. When you want to delete an image from one of the pages that hold your site-wide images, the module searches all pages that use that image. If any page contains a reference to the image you are trying to delete, deletion will be prevented. You will get an error message with links to help you edit those pages and remove references there before you can finally delete the image. This field type can be used with marcrura's Settings Factory module to store images on settings pages, which was not possible with other image field types When to use ? If you want to let editors choose an image from a set of images that is being used site-wide. Ideal for images that are being re-used across the site (e.g. icons, but not limited to that). Other than the native ProcessWire images field, the images here are not stored per page. Only references to images that live on other pages or inside a folder are stored. This has several advantages: one central place to organize images when images change, you only have to update them in one place. All references will be updated, too. (Provided the name of the image that has changed stays the same) Installation and setup instructions can be found on github. Here's how the input field looks like in the page editor: If you like to give it a try, I'm happy to hear your comments or suggestions for improvement. Install from URL: https://github.com/gebeer/FieldtypeImageReference/archive/master.zip Eventually this will go in the module directory, too. But it needs some more testing before I submit it. So I'd really appreciate your assistance. Thanks to all who contributed their feedback and suggestions which made this module what it is now.

As @Robin S explained, there is no reason to echo anything in a context like that. If you just put any other PHP code there, that will not be executed twice (at least it should not do that for sure). Only echo() is what gets executed twice but it should not even happen once, meaning not calling echo() is the "solution". I have sites with various code being executed in that context, none of them runs twice.

I don't understand what you're saying here or what screenshot you're referring to. But my general point is that fields like Page Reference or Repeater are ultimately about storing a relationship between pages (Repeater items are pages). Rather than use a field to store the relationship, you can use the parent-child relationship. In PW, until pagination support is eventually rolled out to Page-type fields only the parent-child relationship can scale to thousands or millions of pages. But for your case this should be no big problem because the parent-child relationship can achieve what you are doing with the Repeater field. You get a nice sortable paginated list of child pages on the Children tab, and you can customise the page labels in a similar way to the Repeater item labels (see "List of fields to display in the admin Page List" in the Advanced tab of the child template). I would just stick with the Children tab, but if you wanted try more things you could look at Batch Child Editor, or listing child pages using a runtime-only inputfield with modules like this or this, or making use of Lister / Lister Pro to view and filter the child pages.

Awesome! thanks! ?

Personally, I don't allow non-superusers to see the trash and I like that they have to navigate to the Delete tab because I want them to think very carefully before they delete a page. If you want to hide Trash (as per the setting mentioned above) but want to let non-superusers trash pages from Page List then you could look at this module:

But thanks a thousand times though for the extremely quick S.O.S response @dragan !!! ❤️ Lots of love from here!

So.. for anyone else being as stupid as I: VERY luckily I had a previous .sql database export from when I moved from dev to prod site! So I exported the current site's db and compared the two .sql files. And I noticed this difference. INSERT INTO `fieldgroups_fields` (`fieldgroups_id`, `fields_id`, `sort`, `data`) VALUES (2, 2, 1, NULL) I changed '{\"flagsAdd\":32}' back to NULL. Anddd ... drumrolll..... Back was my beautiful AdminThemeBoss dearly beloved and missed PW adminarea loginscreen! (Sorry for the inconvience and S.O.S signals... But you know.. maybe someone else will be as idiotic as me one day and find this useful?)

@gornycreative - thanks for the report, i will test this and post back asap.

But for that only, you have the Children tab by default in each page, it have pagination and ajax loading

Version Update 2.0.1 The current version has got a bug fix. Thanks to @ngrmm I could discover a bug which causes that the module cannot be loaded if the MatrixRepeater field ends with the name "repeater". The code was adjusted and information about the problem was provided. All information and downloads are updated in the first post.

Depending on your needs https://modules.processwire.com/modules/process-email-to-page/ may be worth looking into. I'm not particularly familiar with this module, mind you, so don't ask me how (or if) it works ?

Is this useful at all https://gist.github.com/adrianbj/2b3b6b40f64a816d397f

I have exciting news for you: ? For the release of my module AppApi I have now also finished the section about the Ajax output of Twack. Twack and AppApi work together perfectly. The routing and authentication is done by AppApi. Twack can also render JSON instead of HTML-views. Here you can find out more about routing with AppApi: https://github.com/Sebiworld/AppApi#example-universal-twack-api And here is the description of the Ajax (JSON) output of Twack components https://github.com/Sebiworld/Twack#ajax-output

Looks like GitHub itself is down right now, so this probably has nothing to do with SettingsFactory ?