Leaderboard

GistPad Manage your code snippets and developer notes using GitHub Gists and repositories. https://marketplace.visualstudio.com/items?itemName=vsls-contrib.gistfs Stumbled upon this today. I have watched the demo below by the creator. This is a really awesome tool! Other features include creating code documentation/notes, create code playgrounds right within VSC, interoperates with codepen, etc. Watch the video below, right to the end. Quality is not the best (it was a live stream) but it is worth it.

Ignore me, I'm an idiot. I had caching turned on for the template I was testing. ? I have come across another problem though. I have a ProFields table field with a text and two checkbox fields. I'm looping through the rows like this: <tr> <th scope="row">{{ row.field_field }}</th> <td> {{ row.field_match }} </td> <td> {{ row.field_training }} </td> </tr> field_field renders OK, but with the checkbox fields in the template, I get "field_training|match does not exist or is not callable in this context". But if I add {{ page.field_status.first.field_training }} outside my loop, I get the correct output.

Hi Moritz, I was following your Using Twig with ProcessWire article today to set up a site for using Twig and have come across a strange problem. When I first started, I quickly created some templates and added a few words in them to see if they were rendering correctly. Then I began working on the site properly. Everything was going fine until I tried to test a page in responsive view. Suddenly, everything I'd been adding to my twig templates had disappeared and I was being shown the small amount of dummy text I'd started with, like a cached version of the very first page rendered. I found that switching to responsive mode had logged me out of PW and it wasn't until I logged back in that everything I'd been working on displayed again. The being logged out when switching to responsive mode is weird enough, but a separate issue, (setting $config->sessionFingerprint to false fixes it) but do you know what might be preventing my pages displaying correctly unless I'm logged in?

Can't read it due to heise+, yet interesting to see it there. Posted yesterday... I wish we knew if the author Daniel Berger is around here somewhere. The comment section is Gold as always. Maybe we should comment there as well. https://www.heise.de/forum/heise-online/Kommentare/WordPress-Alternative-Websites-flexibel-gestalten-und-verwalten-mit-ProcessWire/Bitte-nicht/posting-40820682/show/ Use Google Translate to read the whole comment - you will enjoy it. Don't really know what the comment author is talking about. It's at least not about the ProcessWire I know.

Page Reference Default Value Most ProcessWire core inputfield types that can be used with a Page Reference field support a "Default value" setting. This module extends support for default values to the following core inputfield types: Page List Select Page List Select Multiple Page Autocomplete (single and multiple) Seeing as these inputfield types only support the selection of pages a Page List Select / Page List Select Multiple is used for defining the default value instead of the Text / Textarea field used by the core for other inputfield types. This makes defining a default value a bit more user-friendly. Note that as per the core "Default value" setting, the Page Reference field must be set to "required" in order for the default value to be used. Screenshot https://github.com/Toutouwai/PageReferenceDefaultValue https://modules.processwire.com/modules/page-reference-default-value/

@r.loeber, I'm not sure why the "Default value" option that is available for most Page Reference inputfield types isn't available for Page List Select, Page List Select Multiple and Page Autocomplete, but I made a module that extends default value support to these inputfields:

OK, I think I know what the problem is. SessionCSRF.hasValidToken() doesn't use the argument passed to $form->processInput() to get the CSRF token. It references $input->post no matter what was passed to processInput(). And with an AJAX request $input->post is empty; it seems like it should use the argument passed to $form->processInput(). (Actually, it checks for extended HTTP headers when it's an AJAX request but if they aren't present it then directly references $input->post.) The solution is to set an HTTP header X-tokenname where tokenname is the CSRF token name and the value for the header is the CSRF token value. It's odd the $form->processInput($arg) does take field values from $arg but it doesn't take the token from $arg and instead directly references $input->post.