Leaderboard

Forked this module a few days ago and ended up in a complete rewrite. Still under development and testing but working properly here. What is different? Do not worry about page naming. The root page is defined via ID. Full multilanguage support * take in account $template->slashUrl settings take in account LanguageSupportPagenames::useHomeSegment settings Fallback to default 404 page if custom 404 is not set Throws exception in case of misconfiguration Access of pages residing in a MultisitePageTree for other domains other than the corresponding root page is disallowed except for superuser Pages inside a MultisitePageTree accessible only via the modified url if called from the corresponding domain (throws 404 instead of unexpected redirects) Page paths are set via hook in Page::path() instead of modifying the return of Page::render() Crosslink support via the RTE (CK Editor) Link plugin Page view links in admin with correctly modified urls * under conditions: see next post! Feedback welcome. Have a try: https://github.com/kixe/Multisite/tree/kixe

I created a simple playlist

@Robin S, thanks for the links. I fixed or cheated it in a bit different way. In the success function of the AJAX Post, I check for the reply if it is success or not. If it is equal to success I redirect to the same page with a query behind the normal URL. In the file I check if the query is in the URL and if so I push the file as a download. The only thing insecure to this method is that if you know the query you can still get the file without a serialnumber. Anyway, it works for the time being, hopefully this helps someone else

PHP has a useful array_chunk function: it is used to split an array into a number of smaller arrays ('chunks') of a size you specify, which are returned to you in a new array (i.e. an array of arrays). ProcessWire doesn't provide a method for WireArrays that is the equivalent of array_chunk, but we can add a new method for this in hook. In /site/init.php... // Add a new 'chunk' method to WireArray, the equivalent of PHP's array_chunk $wire->addHookMethod('WireArray::chunk', function($event) { $wire_array = $event->object; $size = $event->arguments[0]; if( !((int) $size > 0) ) throw new WireException('WireArray::chunk requires an integer $size argument greater than zero'); $array = array(); $count = count($wire_array); for($n = 0; $n < $count; $n += $size) { $array[] = $wire_array->slice($n, $size); } $event->return = $array; }); Now we can use this new chunk() method on any WireArray to return an array of smaller WireArrays. Remember that many array-like objects in PW are WireArrays, including PageArrays, Pageimages and Pagefiles. An example using a PageArray of 'workshop' pages. We are running a series of workshops and there is only time for four workshops per day, so we want to divide the workshops into groups of no more than four and put each group under a heading... // Get all workshop pages $workshops = $pages->find("template=workshop"); // say this returns 12 pages // Split the workshops into PageArrays of no more than 4 pages each $chunked_workshops = $workshops->chunk(4); // an array of 3 PageArrays of 4 pages each foreach($chunked_workshops as $key => $chunk) { // $key is the zero-based index of the array $num = $key + 1; // Output a heading followed by the workshop links echo "<h3>Day $num</h3>"; echo $chunk->each("<p><a href='{url}'>{title}</a></p>"); // $chunk is a PageArray } Another example, this time using images. Say we want to divide the images into groups of three or less - maybe they are to be arranged into rows or we are giving the groups some special styling. // Say this page's 'images' field holds 8 images // Split the images into Pageimages objects of no more than 3 images each // 8 does not divide evenly by 3 so the last Pagesimages object will contain only 2 images $chunked_images = $page->images->chunk(3); foreach($chunked_images as $chunk) { echo "<div class='image-group'>"; // $chunk is a Pageimages object foreach($chunk as $image) { echo "<img src='{$image->size(300, 300)->url}'>"; } echo "</div>"; }

While a relatively quiet week due to travel, the 3.0.62 version has been merged from dev to master, plus a few other small updates in this week's blog post: https://processwire.com/blog/posts/pw-3.0.62-master/

just wanted to let you know that i found a very nice jsdiff library today that is ideal for this usecase (line-based diff): https://github.com/kpdecker/jsdiff/ i'm not sure any more if a module like this would make sense, though. i built a module that makes adding and removing fields and templates very easy: public function ___upgrade($from, $to) { // define variables $fat = $this->wire->modules->get('FieldsAndTemplatesHelper'); $pages = $this->wire->pages; // upgrade if($from < $to) { // 001 if($from < 1 AND $to >= 1) { $this->message("upgrade v001"); // create templates and fields $t_clients = $fat->createTemplate('clients'); $t_client = $fat->createTemplate('client'); $f_domain = $fat->createField('domain', 'text'); $f_nossl = $fat->createField('nossl', 'checkbox'); // early exit if anything went wrong if(!$t_clients) return; if(!$t_client) return; if(!$f_domain) return; if(!$f_nossl) return; // apply settings $t_clients->noParents = -1; $t_clients->childTemplates = [$t_client->id]; $t_clients->childNameFormat = 'title'; $t_clients->save(); $t_client->noChildren = 1; $t_client->parentTemplates = [$t_clients->id]; $t_client->save(); $t_client->fieldgroup ->add($f_domain) ->add($f_nossl) ->save(); // create page $p = new Page(); $p->template = $t_clients; $p->parent = 1; $p->addStatus(Page::statusHidden); $p->addStatus(Page::statusLocked); $p->name = $p->title = 'MyClients'; $p->save(); } // 002 if($from < 2 AND $to >= 2) { $this->message("upgrade v002"); } [...] in many occasions it would not make much sense to have the diff-tool because you would have to change the code anyway, eg: $t_clients->childTemplates = [$t_client->id]; and all the correct names of the options can easily be inspected via code inspector: so... i guess i will not take this further or are there other opinions?

If you are loading the page that contains the form but the form has not been submitted then none of the form inputs will be in the post data. So that has no impact on anything you are doing with $input->post. If the form has been submitted then the form inputs will be in the post data - a form input might be empty but there will still be a post variable for it. So you can check for the presence of any post variable, empty or not, like this... if($input->post->my_input !== null) { // ... } Doing it this way you don't have to add anything extra to your form, but if you have several different forms with different inputs you need to adjust the test so you are always checking for a post variable that matches the name of an input if that form. Alternatively you could add a hidden input to all your forms - for instance, you could call it 'form_page_id' and put the ID of the page containing the form in it. Then you can use the same test on every form... if($input->post->form_page_id) { // ... }

Thanks @thomasaull that would be great! There is an amazing new tutorial https://auth0.com/blog/vuejs2-authentication-tutorial/ if you don't mind having the users saved on Auth0. After all, Auth0 is the company behind the JWT website so they should implement it properly and you can obviosuly still keep all users in sync with ProcessWire db. But regarding Rest API I'd rather use GraphQL instead because that seems more flexible.

Sounds good. I recently read some stuff about JWT, maybe I'm gonna give it a shot trying to implement it with a default REST Api… Not sure if I got the time though… This articles has some overview info: https://www.sitepoint.com/php-authorization-jwt-json-web-tokens/ And this is a library for doing the stuff in PHP: https://github.com/firebase/php-jwt

Hello! I've been migrating a Joomla site to PW. As I was at it, I could not help notice that the text of the articles I was importing into PW was messy. The site owner confessed that he simply pasted his text from MS Word into Joomla's editor, which resulted in very dirty HTML full of inline CSS and custom class names. So this got me thinking of tools I could use to clean this dirty HTML. After some search I stumbled across a handy PHP tool named htmLawed developed by Santosh Patnaik. What I liked about htmLawed was its flexibility in filtering and cleaning HTML. My goal was to strip off the style attributes from <p>'s in my HTML, which was way below htmLawed's capabilities. It can do a lot more -- reading the list of features got me hooked up! The htmLawed download contains just two files: the software itself, and a script to measure performance. Including htmLawed in a PW template is a matter of one include(), and after that you are ready to go. Using any HTML formatter adds a certain memory footprint, so using htmLawed for outputting each and every piece of HTML might not be the best idea; but nevertheless it's a handy and flexible tool for sanitizing and beautifying any HTML before saving it in your PW page. htmLawed is free, well-documented and flexible. Give it a try if you feel you need more control over HTML that your users post. http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/

Thanks @thomasaull ATM I am waiting for GraphQL module support for RepeaterFields before I integrate it in processvue. I'll implement the JWT login later on because I haven't used it before so I need to learn how it works, but it is definitely on my list of things to do. I don't know how JWT should integrate with GraphQL too, I'll probably ask @Nurguly Ashyrov if he has any idea of how I should integrate it. There's also the problem that GraphQL allows you way too much freedom on what kind of query you can perform on the client, to prevent that I've got to implement persisted queries.