Leaderboard

Version 2.1.75 is out! This version comes with a new CAPTCHA, a new validator and 2 new methods. Due to a user request from @Andi, I have now added a captcha that supports a question that the user has to answer. It's a perfect contrast to all the image captchas out there and can be personalized. For example, you can ask a personal question about the company or a person, depending on the page you are running. The user must answer this question by writing the answer himself, and not by selecting a radio input. This makes the CAPTCHA very strong against SPAM. This requires you to add several accepted answers that can be compared with the value entered by the user. During the development of this new CAPTCHA, I have also created a new validator and 2 new methods for CAPTCHAS. You can read about all significant changes in the changelog.md. As always, make sure that everything works as expected and please report any problems you discover. Jürgen

@sebibu you can easily hook into https://processwire.com/api/ref/session/login-success/ and add the last login timestamp as $page->meta('lastlogin', time()) on the $user object (for example).

In a long thread of similar issues, it's often blamed on Twitter's crawler failing to load for some reason, and the cache getting corrupted. It may take a few days to clear. It (your site) worked for me today, multiple times. Ignore the grammarly icon overlay. ?

Hey Ivan, Sorry for the delay. In all honesty: usually render() is the one you want. There are very few cases where init() is better, or necessary for that matter. Behind the scenes init() is triggered as soon as a Controller class instance is created; at the end of the __construct() method. Meanwhile render() is only called when a page is, indeed, rendered. This means that render() gets called one time for each rendered page (e.g. in case you're rendering multiple pages within single request), while init() is called for each item as soon as their controllers have been instantiated. Personally I've ended up using render() pretty much all the time ? There is no built-in solution for this, but if you want to stop rendering the page as soon as you detect (in init()) that you don't want to render it, you could e.g. trigger a redirect, or perhaps call wire404(). Now, if you do use this solution, you'll want to make sure that it's not a "page being rendered within another page" type of situation, as that would be pretty problematic. Alternatively you might be able to call $this->setView() to override the default view file to something specific to an error scenario. I'm not 100% sure of this though, as its not really something I've every done ?

hi, i'd like to add another "little" argument i often use to convince clients/agencies/bosses and so on, this exact forum... a client could rightly be concerned about something that happens quite often,: if ever, for any reason we had to stop working together, will another dev be able to take care of our website? of course, all the reasons i've seen here will help with yes, pw is not that hard to learn, they are other devs working with it... but, and that's my point here, a dev who is not (yet) pw addict and will start working with will find a very good and friendly place to get help, a place where beginners are never scornfully sent to go and see elsewhere with a harsh "rtfm", this could add a comfortng reason to say, ok, let's go with it ? have a nice day

You might already know this, but I just found an easy way to have custom tooltips on inputfields: $field = $this->modules->get('InputfieldSelect'); $field->name = "example"; $field->label = "Cool Tooltip"; $field->attr("uk-tooltip", "title: My tooltip text; pos:left; delay: 200"); // this line $field->addOption("option1", "Option 1"); $field->addOption("option2", "Option 2"); Have a look here for all the options.

With the current project that I'm working on, there's eventually going to be an enormous amount of data to edit within it (in ProcessWire), and so I've been looking for ways to optimize and facilitate the editing experience. The goal is to save the people editing as much time as possible, and reduce the number of steps necessary to make common edits. This is what motivated the recent Table field updates. The is also what motivated a new module I'm working on called PageEditChildren. The PageEditChildren module takes the existing "Children" tab in ProcessWire's page editor and replaces it with a new one that lets you edit all of the child pages inline, directly from the parent page. For specific cases, such as the one shown in this video (below), this provides a more convenient way to edit multiple pages at once. It can significantly reduce the amount of back-and-forth between the page editor and the page list, or multiple page editors, keeping it all in one page editor session. Likely you would use this module to replace the "Children" tab on just some (not all) pages. Specifically, pages where the relationship between parent and children is one where they are often edited as a group. This is a fairly common use case in ProcessWire, and one where this module can save you a lot of time. From an editing standpoint, it has a lot in common with repeaters. Other modules that have some crossover are PageTable (core) when configured to create/edit children pages, and BatchChildEditor. Both use page editors in modal windows to accomplish editing children, a different approach than PageEditChildren, which keeps it all part of the single page editor. Though BatchChildEditor can edit title and status (hidden/unpublished) inline, and supports CSV export/import options, among other useful tools. All of these modules are worth consideration when there is a need to optimize the editing experience between parent and children. This is just an early preview of PageEditChildren, so I'm going to work on the module and test it out a bit more before releasing it. But it could be ready to share as soon as next week. Supporting file/image and repeater fields in this module required some minor core improvements, which are in this week's core updates. I'm interested to hear your thoughts on whether this would be useful in your sites as well? More next week. Thanks for reading and have a great weekend!

This is my first module. It is primitive, like my neighbor who loves to fire up his new Makita breaker hammer after 21:30h. Please, feel free to do whatever you want. I don't promise I will add better functionality but maybe... If you do, please ping and send me back. Thanks! It loads every page on the backend. It calculates the text width in two fields you choose on the configuration page.. If there are any updates, I will post them here. Happy ProcessWiring! PS: These measurements are specifically for desktop and Google's SERP (Search Engine Results Page). UPDATE on 15 May 2024: Google started to calculate (truncate) the meta title for 20px Arial yesterday. The Module has been updated. Here is the link to download/install the latest version: https://processwire.com/modules/seo-text-width/ EDIT: The version 0.0.5. Added two dropdown fields on the configuration page of the module. PROVE IMAGE: You can check the meta title, which was measured with 18px Arial and it was less than 512 pixels.

FieldtypeFormSelect lets you create fields to select from forms created using the pro FormBuilder module. Features: Create select fields that allow for choosing forms when editing pages Fully compatible with FormBuilder, render forms using native methods Choose which forms will be available to choose from, each field is configured individually Choose how form names will be presented in select elements Compatible with FormBuilderHtmx FieldtypeFormSelect lets you create fields like this, configured as desired. Choose which forms will be present. Including forms where names start/end or contain a value allows you to create a form select field once then use form names to help group them together, or add/remove them from form selects without editing the field. This is also a pretty simple way to allow end users to create forms that will be selectable without having to edit a field configuration. For example, this field will only allow you to choose forms having names ending with "request", so "customer-support-request" and "consultation-request" will be included, but where forms with names like "newsletter-signup" and "call-to-action" won't. Choose how you would like the form names to be presented in the select element. They can be shown as they are originally named, as spaced words, or as capitalized/spaced words. Rendering in your templates is straightforward <?php $page->select_a_form; // => A form ID, or null if no form has been selected // Render using the native FormBuilder method echo $forms->render($page->select_a_form); // Alternate method. Selected form will be rendered, if no form is selected output is null. echo $page->render('select_a_form'); Form select fields store the ID of the selected form and FieldtypeFormSelect makes use of ProcessWire's built-in field rendering to keep things simple. The fields you create will always be up-to-date with the forms as they currently exist. If a form is deleted that has been selected in one or more fields, those values will be set to null so you won't experience any issues with references to form IDs that no longer exist. Your templates and pages stay free from errors. My primary use is to have a form select field available for blocks created in the RockPageBuilder module by @bernhard. I want each section on the page to contain an option to choose any form that will open in a modal to put the power of choosing forms in the hands of the user. RockPageBuilder is not required, but makes for a powerful example. Contributions and issues are welcome on Github, or stop by here for some help! Install as a ProcessWire module Install via Composer Download from the Github repository Cheers!

I've just tried and it worked like a charm. I will go nuts

Hello @sebibu, you can find successful or failed logins under "Setup => Logs => Session" (/processwire/setup/logs/view/session/). You can search those logs for example by username. It should also be possible to search those logs with the API: https://processwire.com/api/ref/wire-log/get-entries/ Hope this helps. ? Regards, Andreas

Has thinking around this issue changed at all? Support for .webp as an upload format for images would be a game-changer for my current project (and has been requested by several previous clients).

Thanks @bernhard! Yesterday I was asking myself if my client has been active in the new system as promised and tried to find and filter a managerlog like in my CMS I used before PW. Now I installed ProcessLoginHistory for the future, but the passed data isn't there. Having that functionality in the core from the installation on would make sense for this case, GDPR and system security in general.. in my opinion. Otherwise or maybe anyway I have to use PW-profiles or similar for my new projects to have the basic extensions and customizations directly at hand.

This is really useful. Some ideas which would make it easier to understand for my editors: Would it be possible to output a rounded value? There is no extra benefit from the super accurate floating value, and they are harder to read, especially if the decimal divider is not country styled typical, but US. I would like to be able to set a threshold value in the module and store texts for it, such as "too short", "too long".

@MarkE I read the other posts, I do not see any code chunk about how you are calling your hooks. As you said it's working on /site/init.php .. .. you have to remember that calling hooks implies also a context, I mean $wire/wire() vs $this, just a thought. Please confirm / insert coin ? edit: And you might also test hook priority option, check there: Edit 2: I made you a small preview of a diff running debug true vs false, on a almost blank website, there is only one user modue installed:

Thanks, this is indeed what I was looking for (using `$page->editUrl` to link to the edit page). My final code which checks if the user can edit the referenced page: $wire->addHookAfter('InputfieldPage::renderValue', function(HookEvent $event) { $page = $event->object->value; if($page instanceof Page && $page->editable) { $event->return = "<a href='{$page->editUrl}'>{$page->title}</a>"; } });

Hi, just in case but i'm quite sure you've already checked this... have those users this checked in their role(s) ? if yes, i'm as stuck as you are ? have a nice day

I don't have a link, but some bullet points of things I like about it. Clear separation between data and presentation layers (but doesn't force you into a SPA or operate as a headless CMS although you can do that with it if you want). Excellent permissions management system at both template and individual field level. Simple object model - everything is a 'page' with 'fields' - (similar to Drupal's nodes, but without the baggage). Great admin UI for no code creation of pretty much any kind of structured data. Actively developed third party migrations module (RockMigrations) that lets you mix and match visual and code based development of object definitions. Excellent third-party debugging tool, TracyDebugger Easy to learn API (I managed to understand the basics of it within half an hour - Drupal and WordPress by comparison, I was still scratching my head after quite a few hours.) Secure Fast Things people might not like about ProcessWire: You're unlikely to be able to build a website with one-click install. There are some site profiles that may suit some scenarios, but the whole point of ProcessWire is that it doesn't second guess you and force its opinions on you. ProcessWire's only area where it is somewhat opinionated is how it stores and structures data at the SQL level. Currently it only supports mySQL/MariaDB, and normally each field has its own table in the database, although ProFields modules Table, and Combo allow more traditional database table structures. It's also relatively easy to build custom fieldtype modules with their own database schemas. Version/source control: If you don't use a third party module like RockMigrations, syncing data changes between development and production with a team of developers might be complicated. (Actual output templates are no problem)

@BrendonKozthanks mate! I have to try it. Brilliant! @bernhard Yes, for me, it is a fun little thing but very useful. Here's screenshot attached.

I've been continuing to work on the PageEditChildren module that I wrote about here last week. This week a "Clone" feature was added. You can click the Clone action and it'll create a copy of the page below the one you cloned, and then make it immediately editable before you even have to save. This Clone action is an example of an Inputfield header action, and it accompanies the Move, Pub/Unpub and Trash actions for each page in PageEditChildren. I thought this ability to add Inputfield actions seemed useful beyond just this module, so the ability has been added directly into ProcessWire's core Inputfields JS API. If you grab the current dev branch of ProcessWire, you can test it out if you'd like. You can paste these examples in your web browser's Javascript console. But in actual web development, you'd likely put these in a separate JS file that is added to your page editor with a hook. Open the page editor to any page, then open your Javascript console in your web browser, and then paste this in: Inputfields.addHeaderAction('title', { icon: 'fa-hand-stop-o', callback: function() { ProcessWire.alert('Hello World!'); } }); That should add a hand icon to your "Title" field header, and if you click it, it'll pop-up a dialog box that says "Hello World". Let's say you wanted it to show a different icon when you hover it, and also to show tooltip text via a title attribute. You can add the 'overIcon' to specify what icon to show on mouseover, and 'tooltip' to specify the tooltip text: Inputfields.addHeaderAction('title', { icon: 'fa-hand-stop-o', overIcon: 'fa-hand-peace-o', tooltip: 'Hello world', callback: function() { ProcessWire.alert('Hello World!'); } }); Above are examples of 'click' actions. We also support toggle or "on/off" actions: Inputfields.addHeaderAction('title', { onIcon: 'fa-toggle-on', onTooltip: 'Click to toggle off', onCallback: function() { ProcessWire.alert('You toggled on'); }, offIcon: 'fa-toggle-off', offTooltip: 'Click to toggle on', offCallback: function() { ProcessWire.alert('You toggled off'); } }); Toggle actions like this are primarily what is used by the PageEditChildren module to handle the Published vs Unpublished state, and Trash on/off state. Whereas "Clone" is an example of a Click action. Our callback functions in the examples above are very simple alerts, but of course you could make it do anything you want in those callbacks. Also added this week to the Inputfield JS API was an update to the Inputfields.label() function that now allows you to set the label for an Inputfield (previously it could only get the label). This is a bit of a contrived example, but since we were talking about header actions above, let's demonstrate the label() function within a header action. This example adds an action that lets you edit the Inputfield label: Inputfields.addHeaderAction('title', { icon: 'smile-o', callback: function($f) { ProcessWire.prompt('Enter new label', 'Label', function(val) { if(val) Inputfields.label($f, val); }); } }); By the way, there's a lot more to the Inputfields JS API, and it's all documented directly in ProcessWire's inputfields.js file. I'll be bumping the core dev version next week to hopefully accompany the first version of the PageEditChildren module. Thanks for reading and have a great weekend!

Welcome to the plugin-author's club, @Leftfield!

This week we have another update to the ProFields table field. A couple of weeks ago I wrote a blog post about Table v28 and the new actions features that it added. I've been working with Table a lot for my current client project, and have found these new features very useful. But I'm doing a lot of data entry in Table and found I still wanted more. Specifically, I wanted to be able to apply some of the actions directly on the row I was working in (rather than having to select it and then scroll down to the actions). Kind of like how one can click the Trash icon on any row to delete the row... I wanted to be able to apply other actions in the same way (Add, Clone, Copy, Paste). And Table v29 (released today) does exactly that. Another desire I had is for the for row-level actions to be just really simple, with not too much to look at... something folks could use rapidly without having a lot to read. This leaves several powerful and verbose features for the actions menu you saw earlier (the one that appears under the Table). Below is a video that outlines these new row-level actions. It's actually the same video from before, but I added to it for the version 29 features. So I'll try to post a link that starts at the timecode of the new stuff. But if you haven't seen this video before, you may want to rewind to the beginning. Below is the full CHANGELOG for this version: Expanded actions support so you can also execute actions directly on individual rows, which is often more convenient than selecting rows and then applying actions. Hold down the SHIFT key before clicking the row actions select and it will convert any actions that usually append rows to instead prepend rows. This works with the the Add, Clone and Paste actions when clicked at the individual row-level. It also works with the Select action for selecting multiple rows at once. The Select action is there in part for people that may not realize you can already click the sort arrows to select the row. Removed the Vex dialogs when copying or pasting and replaced them with other visual cues to indicate successful copy and/or paste. Added a new config option for disabling the DELETE (trash) icon on individual rows when individual row actions are enabled. This is because the row actions already include a delete action, so the trash icon can be redundant for some who might prefer the additional space. For all non-page selection column types, a new "Settings" option was added (named “formattedValueType”) to indicate how the value should be represented when accessed from a formatted page. Previously the API value was always the selection value. Now you can specify that it should include both the value and label (in your choice of array), or just the label rather than the value. Table v29 beta is available for download now in the ProFields download thread. More core updates are likely for next week. Thanks for reading and have a great weekend!

This week we have ProcessWire 3.0.238 on the dev branch. This version contains 17 commits containing new features (some via feature requests) as well as issue fixes. Recent updates have been nicely covered in ProcessWire weekly issues #517 and #518. Also added this week are the following: Improvements to ProcessPageClone, which now supports some new options such as the ability to configure it to always use the full clone form (a requested feature), and an option to specify whether cloned children should be unpublished or not. New $datetime->strtodate($date, $format) method that accepts any PHP recognized date string and reformats it using the given format. It also supports date strings that PHP doesn't recognize if you give it a 3rd argument ($options array) with an `inputFormat`. The existing $datetime->strtotime() method now supports an `inputFormat` option as well. The Inputfield class now has new methods: $inputfield->setLanguageValue($language, $value) and $inputfield->getLanguageValue($language), added by the LanguageSupport module. Previously there were no dedicated methods for this, so you had to manage them with custom keys containing language IDs if you wanted to programmatically use an Inputfield in multi-language mode. The ProcessWire.alert() JS method has been updated with an auto-close option (`expire` argument) that automatically closes the alert box after a specified number of seconds. InputfieldDatetime has been updated with 7 new interactively configurable settings for the jQuery UI date picker. See the screenshot below for an example of a few. Plus, its API has been updated with the ability for you to specify or override any jQuery UI datepicker option, either from PHP or JS, as requested by Toutouwai/Robin S. See the new datepickerOptions() method and phpdoc for details. Next week we've also got some more updates to InputfieldTable that take the newly added actions even further and make them easier to use. Thanks for reading and have a great weekend!

@Michael Mirula, this module is no longer being actively maintained by the author, but see @adrian's post above yours for a fix you can apply.

So at least we have more than 8800 sites using Processwire https://publicwww.com/websites/"X-Powered-By%3A+ProcessWire"/ @jmartsch take a look at this link