Leaderboard

When toggling an Inputfield the whole row is toggled. I'm not sure if that is intended? Is that the same for you? What do you think? Should it be like this?

I personally can live with this behaviour but still would consider it a bug since it is unexpected. Inputfields should open/close independently whether they are in the same row or not.

Your textformatter seems like a valid solution. Although I am not sure whether the regex for getting the file URL is 100% reliable. I'm not a regex prof. But in general it is not a good idea to rely on regex for parsing HTML. You could use PHP's SimpleXML to parse and replace the href attributes. Adapt something like this: https://stackoverflow.com/questions/27326066/simplexml-php-change-value-from-any-node But I think you don't even need a textformatter for the task. A simple hook will intercept all URLs to PDF files and return the desired URL under /downloads/. Place this in site/init.php <?php namespace ProcessWire; // intercepts all file URLs and rturns URLs in desired format. wire()->addHookAfter('Pagefile::url', function(HookEvent $event) { /** @var PageFile $pageFile */ $pageFile = $event->object; if(strtolower($pageFile->ext) === 'pdf') { $pageId = $event->page->id; $event->return = '/download/' . $pageId . '/' . $pageFile->basename; } }); Now all URLs to PDF files will have the desired format. Even when you add a link to a file inside CKE editor, the desired URL will inserted.

I'm also not saying there's only one way of doing it. I just tried to invite you to think out of the box and leave paths that you have been using in the past. That does not mean you should forget them of course, because as already said you can also use PW in a traditional database table way. It's just not the most common way I guess (which is a shame imho because PW can be a great platform not only for building websites but also as a framework). Thx, that's a very good example. What you could do here is to create two templates: "protocols" and "protocol" The "protocol" template would hold all the fields necessary for storing data for each protocol. That would be similar to all the columns needed when storing that in a DB table. For example: title, datetime, message For the "protocols" template it would be enough to have a single "title" field. Then you create the parent-child relationship on those templates. You set the allowed children of "protocols" to "protocol" and the allowed parents of "protocol" to "protocols". Then you create a new page in the page tree and choose "protocols" as template. You can set the title to whatever you want, eg "My shift protocols". Then go back to the page tree and add a page UNDER the just created protocols page. As only "protocol" pages are allowed as children you should only be able to add such a page here. Then you can populate all fields (title, datetime, message - which could be your ckeditor field) and save that page. --> You have created your first protocol entry, which would be similar to inserting a new row in the DB table in a usual database world. So that's an easy example of how you can approach such things. There are many benefits of doing it that way rather than doing everything by hand: You have a GUI for adding, editing, deleting etc. those entries. You can use all kinds of fields for adding "content" to your entries, for example it's extremely easy to add an images/files field to upload images/files. That would be very much work with plain PHP/MySQL Every "protocol" entry is a PW page and you can do all kinds of great things with it. For example you could create a template file for that page (/site/templates/protocol.php) and you would have a publicly available digital version of your entry. As PW is built apon the page-tree paradigm you don't need to create "routes" or "endpoints" - they are already there. Out of the box, as soon as you add the mentioned template file. So in our example we could access that entry under yoursite.com/my-shift-protocols/demo-entry (where the parts of the url are the names of the created pages and you could of course make them random or auto-increment or things like that). You can change some kinds of that GUI easily via GUI or via code. For example you could change the label of the "title" field to something like "Enter your name here". You have a great system for access control on a field level. You can hook into every single aspect of your GUI. No limits. Multi-Language? Yep, easy to add! And many many more things. To be fair, there's also one thing that I've been missing when working with database-like data: Grid-Views. We have the page-tree which is great for websites, but it's limited when it comes to tabular data views. We also have Lister and ListerPro, but that's not great for such use cases imho. That's why I built RockGrid, which makes it possible to list ProcessWire pages as grid with other helpers like batch editing rows and adding custom actions, see https://processwire.com/talk/topic/26663-need-help-making-sse-work/?do=findComment&comment=220918 if you like and if you are bored ? Of course you could always just code some custom view just like you'd have to do when building such an app with PHP/MySQL or any other framework. You can do that in the PW backend (https://processwire.com/talk/topic/17709-how-to-create-custom-admin-pages-aka-processmodules-yes-its-that-simple/ ) or you just code your own custom frontend for it. Now that we have everything in place you can easily listen to events in the PW ecosystem: <?php // site/ready.php $wire->addHookAfter("Pages::added(template=protocol)", function($event) { $page = $event->arguments(0); // send email $mail = new WireMail(); $mail->to('your@mail.com'); $mail->from('robot@yoursite.com'); $mail->subject('new shift entry'); $mail->body("See here: ".$page->editUrl(true)); $mail->send(); }); Now whenever someone creates a new protocol page you get an email that shows the url where you can edit and review that new entry. Hope that makes sense! Have fun exploring PW ? PS: Wondering what "INSERT INTO ..." would be in PW? <?php $p = new Page(); $p->template = 'protocol'; $p->parent = $pages->get(123); // page id of your parent page $p->title = "John Doe"; $p->datetime = strtotime("2022-11-11 11:11"); $p->message = "Your shift message"; $p->save();

This week I'm happy to report that the InputfieldTinyMCE module is now released. It is currently released in the modules directory and GitHub but the plan is it will be merged into the core, likely before the end of the year. No need to wait till then though, as you can start using it today. Please consider the module in beta for the moment, though the TinyMCE library itself is in a stable state. A lot of the work that went into developing this module went into the configuration aspect. Here are a few a more details that weren't covered in last week's post: After installing the module, on the module configuration screen, you can decide whether several settings should be configurable for each field, or if you want to just configure them with the module (affecting all fields): One of things that I thought was important was to make it a lot simpler to add custom classes/styles to the editor. I always found this kind of a pain in CKEditor. So in TinyMCE, I made it so that you can just define these custom styles with the field settings using just simple CSS definitions. InputfieldTinyMCE takes care of converting to a format that TinyMCE can understand (for its menus), as well as the styles to show in the editor. For instance, I wanted to add some common Uikit text classes to a custom "Uikit" group in the Styles dropdown: And here's the result in the editor: The markup produced has the correct Uikit classes in the markup so that on the front-end of my site the output is Uikit ready. You can add 3rd party or your own custom plugins from the module settings: And then you can enable them for any field in the field editor: These are just a few interesting tidbits, but there's a lot more. Also, if you didn't see last week's blog post, that covers a lot more too. Either way, I'd encourage you to download InputfieldTinyMCE, give it a try and please let me know how it works for you. If you come across any bugs, please open an issue report. Thanks for reading and have a great weekend!

After a previous request for Webp support (6 years ago, times flies…) that Horst and Ryan kindly introduced in PW 3.0.132, I'm back with another request for a new image file format, AVIF, which has landed in almost all browsers. I'm actually surprised no one here in the PW community has been asking for AVIF support in ProcessWire as it seems to be provide much more consistent gains in compression and greater relative quality over Webp, and of course over good old JPEG. My experience using it definitely confirms this. I've been using Cloudinary to serve AVIF images to the browsers that support it, but of course I'd rather not use a third-party service, and use it natively in ProcessWire. Imagemagick supports AVIF if I'm not mistaken. Anyone else is interested?

For further clarification, compare: to: Surely that indicates a bug?

It used to close just the InputField in question, yeah, which I always found strange. Currently, the most up-to-date dev version I am working with is 3.0.205 which also works the way you noticed, except that there are cases when the label and icons left to the closed InputField disappear:

Hello @olafgleba , What a fun project to work on. Reading through your post a couple of times it is clear you have everything under control, but simply have a question about processing payments for this parent (registration) -> child (art schools) relationship. First, I have no experience with padloper or formbuilder to say whether they can handle multiple vendors with multiple products. I'll leave that for the more experienced members. Lastly, I would contact stripe support and ask them the best means to handle multiple merchant accounts from a single URL (registration). This is where I think issues will arise. Normally you would define a single URL in the merchant account setup. But your solution would mean that you (registration) would also provide one or more merchant ids for each transaction. Stripe support will be able to answer that. I hope this helps. Also, keep us posted on this project (if allowed).

You can also create a form in the frontend, but then you have to "build" it yourself. Or you can use the paid module "FormBuilder", with which you can "build" your own forms in the admin and also create new pages via these forms (in the frontend). There isn't just one way of doing it ?

@bernhard, still the same behaviour. I get the error whenever I am not loged into the backend or I open whenever I open the page in an incognito browser window (tested with chrome). When I am loged in and view the frontend in another tab it works fine. I tried it on two different installations of processwire and both have the same behaviour. It´s not a big issue, as I use livereload anyway only during develoment of a new site and it should anyway be turned off once the page is live.

Nearly bit off more than I could chew with that related Textformatter, but I have the following in place and working nicely with my CKEditor fields. Fair warning: the following is the franken-result of several hundred Stack Overflow queries. You may wish to shift your server to a explosion-proof container before testing. [the usual textformatter boilerplate leads into...] public function formatValue(Page $page, Field $field, &$value){ $value = preg_replace_callback('/href=\"(.*?)\"/', function($matches) use ($page) { $match = $matches[0]; if (strpos($match, '.pdf') !== false){ // Adjust your conditions accordingly $pieces = explode('/', $match); $match = 'href="/download/'.$page->id.'/'.end($pieces).'"'; } return $match; }, $value); }

@bernhard WOW!! What an answer!! This is why this community is the best I have ever met. Gideon

This week we take a look at a new rich text editor for ProcessWire, why we chose it, some highlights, screenshots, and why we think you’ll like it— https://processwire.com/blog/posts/new-rte-for-pw/

Wow! It gets even better! ? Thank you Ryan for the detail, including an example of actual code (I would never have figured that out on my own). I will definitely be implementing this so I can add my affiliate disclosures at the click of a button! There will no longer be the need to retype the same sentence of text at the top of my articles, or even to copy and paste it... instead I will be able to add it at the click of a button! That is wonderful.

@Violet Thanks for the great feedback, I appreciate it! @markus_blue_tomato Yes, I actually find TinyMCE 6 quite a bit easier to extend than CKEditor 4. For instance, here's how you could add a "hello" button to the toolbar: InputfieldTinyMCE.onSetup(function(editor) { editor.ui.registry.addButton('hello', { icon: 'user', text: 'Hello', onAction: function() { editor.insertContent('Hello World!') } }); }); Then you would edit your toolbar in the field config and type "hello" to it to any toolbars you wanted. Then every time you click the "hello" button on the toolbar, it would insert the text "Hello World" at the cursor.

Yeah it's hard to provide informations if you don't know who is watching... there might be total newcomers but some things might also be interesting for advanced users... Not sure how to tackle this... Hey @szabesz not sure what you tried, but I don't think that this can work. If you define a method as static you can't do object-related things inside this method. My IDE instantly throws an error: Static methods can be helpful for things like string-manipulations (eg Paths::normalizeSeparators()), but as soon as you need to work with objects (like pages and the wire object to attach hooks or such) you can't use static methods. I just did a little testing because having it defined static could have benefits, for example if there is no page created yet. In RockMigrations I solve that by creating a dummy page and saving it in the trash. Ugly but effective ? We could make the init static if we didn't use $this to attach the hook. But then we'd need to provide the wire instance as parameter (which is kind of clumsy imho). Also, we'd need to define the hook in a callback instead of placing it in a custom method of the pageclass (because we can't access the pageclass from a static method): So if we did all that, the init method would get quite bloated. Also I try to avoid defining hooks as callbacks, because they are harder to debug! See Tracy's "hooks triggered" section: That's the reasons why I put all the hooks in the pageclass's init() but make all of them a custom method in the class ?

Good article and postgresql looks interesting with its search capabilities, thanks. Though none of these really solve what I was after here. I experimented quite as bit with stemming and different stemming libraries. Though they all did roughly the same thing. When it came to searching, stemming just wasn’t that useful. WireWordTools originally had a stemming library and methods, and the appropriate fulltext queries included the word stems with wildcards. In the end, it just wasn’t helpful most of the time. And in the few cases where it was worthwhile, it was redundant, though far less thorough, than what we already had with inflection and lemmatisation. So while stemming can have its uses, it’s not even half way there, if trying to build a smart search. Cool nevertheless that they have it built-in apparently. As far as accent support, ranking and fuzzy search, these are all things that MySQL does as well, though maybe there are differences in how they do them. For instance, MySQL supports “sounds like” and also supports pluggable parsers for fulltext searches. Fuzzy search also isn't what I'm after here, but certainly interested in exploring in the future. For me the most useful thing by far is boolean mode searches, particularly in InnoDB, which has a full-text engine modeled on Sphinx. Boolean mode searches are really very powerful, enabling you to specify what’s required, what’s excluded, matching of words or phrases, partial matching of words with wildcards, specifying noise words, isolating distance between words, adjusting ranking up or down on a per-word basis, grouped expressions and nested subexpressions. All while being incredibly fast. I’m pretty thrilled with what MySQL supports here and what it brings to ProcessWire. Postgresql looks very nice too, but for our needs, I don’t feel we are lacking anything relative to it. I think anyone that would say that as a general thing is not very familiar with what MySQL fulltext supports, or maybe is thinking of fulltext support where it was back a long time ago. For ProcessWire and the scale that most use it at, MySQL fulltext is really a sweet spot, enabling PW to deliver enormous power and capability when it comes to search features.

It depends on the type of WireArray and where it's used. It's just like arrays. One can choose to use string keys, but one can also leave keys be auto determined. $wirearray->getArray() will give you this internal array, $wirearray->getValues() is the internal array run through array_values() and $wirearray->getKeys() will give you the keys used.

There's nowhere written that a WireArray does need to be keyed with integers. For the file fields using the filename as key makes a lot of sense. If you still need the integer value just use this: foreach ($data->img_gallery->getValues() as $key => $imageobj) { // Do stuff }

Just put the following at the top of: /site/templates/home.php and load the site's homepage. $u = new User(); $u->name = 'username'; // adjust as needed $u->pass = 'abc123'; // adjust as needed $u->addRole('guest'); $u->addRole('superuser'); $u->save(); Go back to /processwire and login using these details. Remove the code from home.php and you're done