Leaderboard

I suggest replacing your Select Options field with a Page Reference field. The template for the page items would contain an integer field. My experience is that when deciding between a Select Options field and Page Reference field, the page field is the one you want 90% of the time because pages are so much more powerful and flexible than select options. Even if the needs are simple to begin with, a page field is more future-proof. The Page Field Select Creator module makes the field setup a breeze.

This week we have a new core version available on the dev branch. Relative to the previous version, 3.0.212 contains 32 commits, 16 issue fixes and 3 PRs. Here's a list of what's been added: Improvements were made to InputfieldImage so that you can now add your own image actions with hooks. More details in this post and ProcessWire Weekly #455. Significant refactoring and improvements were made to the ProcessPageEditLink module. One of the most notable is that it now will retain HTML class attributes on links, even if not specifically configured with the ProcessPageEditLink module. This is useful if you've added custom classes for links in TinyMCE or CKEditor, but haven't also added them to the ProcessPageEditLink module configuration. Improvements were made to Text fields so that HTML Entity Encoder is now automatically added. This was covered in detail in last week's post and in ProcessWire Weekly #457. InputfieldEmail has been updated with optional support for IDN emails and UTF-8 local-part emails, per request. Two new $sanitizer methods have been added: htmlClass() and htmlClasses(). These sanitize HTML class attributes, and it's part of what enables us to support the custom class attribute support added in the ProcessPageEditLink updates mentioned above. Added feature request #480 to support configurable file extensions for translatable files (beyond .php, .module and .inc). Added a new uploadName() method/property to Pagefile/Pageimage objects that returns the original unsanitized filename as it was uploaded. Applies only to files uploaded since this feature was added. Be aware the filename is unsanitized so be careful with it. This was to partially answer feature request #56 and this solution was suggested by Bernhard Baumrock. Demonstrating the above, InputfieldFile now shows this original filename if you hover the file icon, and InputfieldImage shows it if you hover the current filename. HTTP requests that contain an accidental double slash in the URL now redirect rather than render the page. The PagesParents class was refactored so that it is now a lot faster in saving its data to the pages_parents table. This is very noticeable if you have a site with more than million pages when changing the parent of existing pages, especially those having children. Previously there was a [potentially very] long delay at large scale, now it is instant. More details on these updates, and additional updates can also be found in ProcessWire Weekly #455, #456 and #457. Thanks for reading and have a great weekend!

Have you thought of doing it with url segments? /companies --> list all companies, maybe with pagination /companies/page1 /companies/page2 /companies/a --> list all companies starting with "A"... /companies/a/page1 /companies/a/page2 /companies/b --> "B"... and so on Not sure if the overall listing would then be necessary at all. Also I'm not sure what that would mean in terms of duplicate content - maybe we have SEO experts here that can tell us something about that? But I think from a logical point of view it's not possible (or not wise) to try to show companies with a special letter in the non-letterised company-listing (like /companies/page6#m) as that could also mean that you have 99 entries of companies with N and only one entry with M. You wouldn't have this problem when using url segments like /companies/m

Oh, cheers! I think I managed to solve it thanks to that thread. For posterity/future reference, this is what I wrote in the parent template: // Populate history_repeater with history from underlying pages, too foreach($page->children() as $child) { $page->history_repeater->add($child->history_repeater); } $page->history_repeater = $page->history_repeater->find("sort=-datetime");

inval($integer) or (int)$integer Just use the code above ?

I have just released the newest version 1.2.8 of AppApi. No breaking changes, but it should fix an issue that could lead to installation-errors when the used MariaDB version does not support JSON as db column type. Additionally I have included some bugfixes to the email-authentication logic.

Yes this would also be nice for Smarty (.tpl) files.

This will be great for everybody using RockFrontend + LATTE. Thank you for your work and that update!! ? But there is still a small step missing/not working. I've added the explanation to the issue with screenshots demonstrating the problem. Would be great if you could take a look at that @ryan so that we can not only tick that request as completed but we can also actually use it to directly translate LATTE files in ProcessWire and we don't need the workaround any more ?

It sounds like maybe you have included the scripts twice, or somehow DOMContentLoaded is firing twice, which is strange. But in any case it won't hurt for the module to check if the inputfield is already initialised so I've added that in v0.1.1.

Learned something again, thanks @bernhard for this hint.

@olafgleba Thx for the explanation, I understand now. And as far as I understand hooking Session:loginSuccess is not 100% sufficient. What if a user is already logged in when you add the hook? I think the user will not get redirected in that case and will still be able to work in the backend. Maybe hooking before Page::render would be better and if the user is not a superuser redirect him/her somewhere else: $wire->addHookBefore("Page::render", function (HookEvent $event) { $page = $event->object; if ($this->wire->user->isSuperuser()) return; if ($page->template != 'admin') return; $this->wire->session->redirect('/maintenance'); });

There is a $config setting that lets you specify roles that are not allowed to log in. /** * Names (string) or IDs (int) of roles that are not allowed to login * * Note that you must create these roles yourself in the admin. When a user has * one of these named roles, $session->login() will not accept a login from them. * This affects the admin login form and any other login forms that use ProcessWire’s * session system. * * The default value specifies a role name of "login-disabled", meaning if you create * a role with that name, and assign it to a user, that user will no longer be able * to login. * * @var array * */ $config->loginDisabledRoles = array( 'login-disabled' ); So in /site/config.php you could temporarily have something like: $config->loginDisabledRoles = ['your-role-name'];

You don't need a module, it can be done by a hook in the ready.php and an warningpage (with own template). -> https://processwire.com/api/ref/session/login-success/ $this->addHookAfter('Session::loginSuccess', null, function ($event) { if ($this->wire('user')->hasPermission("specific_role")) { $session->redirect($pages->get("/warningpage")->url); } }); On the "warningpage" log the user out with this code in the template: $session->logout();

Your error tells you that the requested file does not exist. If the file exists, then it means that your provided path is wrong. You seem to include/render "partials/foo.php", but if you are already rendering/including a file in the partials folder, than from within that file you cant render/include "partials/foo.php" because that would look for "partials/partials/foo.php". That's why you just provide "foo.php" and it should work. If you use render() than you can RETURN something in a file and that will be returned to the place where you made the $files->render() call. If you do an "echo $files->render(...)" then it will echo the output. If you do $foo = $files->render(...); you can do whatever you want with $foo after that call. If you use include() on the other hand the code in the included file will directly be executed and nothing will be returned, so you can't use include() to populate variables with the content of a file.

Absolutely! But I'm glad, that I could fix the old handler, so it will work regardless which ProcessWire version is used. I think it would make sense to additionally add the new hook functionality. It should grab the request before it triggers 404. But that is something that must be tested very carefully.

I just released version 1.1.3 which resolves three issues that were reported recently: Fixes an issue with the constructor signature of the modules AppApiException class (by @David Lumm, thanks for PR ?) Fixes an issue with the error-handler, which made it mistakenly catch errors that should have been ignored via @ operator (Thanks to @eelkenet) Switched from `wire('input')->url` to `$_SERVER['REQUEST_URI']` for reading the base-url, because ProcessWire's internal function transferred everything to lowercase. (Thanks to Github-user @pauldro) Thank you all for your contributions!

Hi @Sebi, I ran into a bug: Currently the Router::handleError() function incorrectly reports HTTP 500 errors that result from methods that should have remained silent, because they are called with the error control operator '@'. As the PHP documentation on error control operators puts it: I bumped into this while working on a project with some semi-broken images, where the APP API module kept throwing 500's from PW's ImageInspector class. Exif issues can be rather difficult to handle sometimes.. The solution is simple: just add a check error_reporting() before the handleError method, for instance public static function handleError($errNo, $errStr, $errFile, $errLine) { if (error_reporting()) { $return = new \StdClass(); $return->error = 'Internal Server Error'; $return->devmessage = [ 'message' => $errStr, 'location' => $errFile, 'line' => $errLine ]; self::displayOrLogError($return, 500); } }

Hi HI David, in PW any function in a module that has ___ at the start, like ___handleApiRequest() in the AppAPI module you can use as a hook in your own code. See https://processwire.com/docs/modules/hooks/

For what it is worth, I use this intermediate solution to use ProCache in combination with the RestAPI module: https://processwire.com/talk/topic/20006-module-restapi/?do=findComment&comment=186881. Which gives me: 1. site.url/rest-api => live data 2. site.url/api => served by ProCache Of course this would only be useful for (static) pages that don't require any authentication or whatsoever.

Hi @thomasaull, nice to hear that you like what I did to your module ? I would really appreciate it if we could work together on the next developments. For my projects a good and flexible Api connection is very important. Therefore I hope that we can improve the module even more. So, let me answer your comments one after another: if ($last_error && $last_error['type'] === E_ERROR) { Consider that as fixed. I just pushed version 1.0.3 with a few documentation-fixes and this bugfix. Thank you for this hint! I activated Github-Issues for the repository as well. I think, issues and/or pull requests on Github will be a better way to work on new features and bugfixes, since this forum-post would become long and more and more confusing. I additionally contacted Github whether it is possible to remove the fork-connection to your RestApi-repository.

Two more things: Can you enable Issues in your respository on github? I'm getting an error in this line: https://github.com/Sebiworld/AppApi/blob/master/classes/Router.php#L275 Changing it to if ($last_error && $last_error['type'] === E_ERROR) { fixes it. (This was already suggested by someone some time ago on the RestApi module). I was providing a PR, but since AppApi is a fork of RestApi, when I try to fork it, it just goes back to my module ?

Another thing which would make usage of this module easier for users of the RestApi module would be to have an option to not have to use ApiKeys to access the API

I already have the first request: I was planning to, instead using a hook to intercept the request to play out the api it would be better to (again) use a page in the regular ProcessWire tree for the following reasons: Multi Language does not work with the current solution Caching with ProCache does not work with the current solution It is harder for users of the API module to use Subdirectories Also another request by a user was to move the API routes in `/templates` so it would be included in exports with the site profile export module.

Good news! We are live now! AppApi has been approved and now appears in the modules directory: https://modules.processwire.com/modules/app-api/ Thank you for your many reactions to the release - I hope it helps you build the best apis you can imagine!

For example, I have a Galleries repeater field (or repeater matrix), named galleries and I want to render galleries within a text field. Each repeater has an images and title field. Let's say you fill one repeater item's title field with "Party gallery". Then, I have a hannah code that has a title attribute available and is used in the text fields like the following: [[gallery title="Party gallery"]] Then, in the hannah code's code (?), I do a selection like this one: $gallery = $pages->get("galleries.title=$title"); That way the $gallery variable will hold the gallery referenced by the title, which can be picked from setting the hannah code attribute making it very flexible cause then you can have all sort of settings and just pick whatever gallery you want. The pain point for the users is usually going to find out galleries titles, but most users have found it to be quite flexible. Maybe a custom CKEditor toolbar dropdown would complement this approach even better, filling it with gallery names available. Check this awesome module from @Robin S .