teppo

That's a strange one, unless of course the namespace declaration wasn't the very first thing in the file, right after the first PHP open tag. It should work fine in view files — in fact I always add the namespace to view files, just in case 🙂 Calling the method via ProcessWire namespace is fine, just a bit verbose. My guess: you'll have to modify the "file mode" setting of the functional field, selecting your view file(s) there. By default functional fields is set to look for function calls from the template file, which means that it won't show up in the editor if it's placed in any other file, including files included/required from the template file etc.

We can rule the missing field issue out, so next question: does your view file have the ProcessWire namespace? If not, try adding it. Or refer to the __text() method as \ProcessWire\__text().

Hey @Mats! The error itself is not visible there, just the trace, but first things first: did you follow the instructions in the Functional Fields README? Asking because I just tried this fieldtype for the first time, and was a bit confused at first: I was too hasty and jumped directly to the "using" part of the blog post, where it seemed to suggest that you can just start using __text() etc. in your template files, while in reality you'll need to create a functional field before that or the functions won't work at all. Without a field the fieldtype file won't be loaded, which also means that the functions.php file won't be loaded, and thus __text() etc. will be undefined. Anyway, let me know if this wasn't the issue. In my quick test the fieldtype seemed to render at least, but I don't have much experience with it otherwise 🙂

Priority numbers and PHP code support / Hanna Code integration are now logged as enhancements in the GitHub repository. I've got another project on my desk right now, but should have some time to work on these soon(ish) 🙂

Seems like it would be worthwhile to add priorities to snippets 🙂 I have considered allowing the use of Hanna Code tags in snippets. Would that make sense for your use case? I'm not against other approaches, but this would be one way to keep Snippets relatively simple, while still allowing for more advanced use cases. Maybe 🙂

No, not under normal circumstances it won't. $session->CSRF->validate() will only ever reset the token in case an invalid token was provided, or if the token was initially created as a single use token (via $session->CSRF->getSingleUseToken()).

Following up on this: after taking a look at that example I've realized that... it doesn't work. Thanks for pointing this out — I should probably fix it to avoid any further confusion 😄 In this case the search method of the controller class disables layout and attempts to change the view. First one is doable (layout is rendered after the view), but the second one isn't, since at this point we've already rendered the view (search method is called in the view, after all). Instead this should be done in the init method (triggered as soon as a controller class is loaded) or the render method (triggered when a page using that controller gets rendered). The distinction between init and render usually doesn't matter 🙂

Sorry, my post was vague on this part (updated now): CSRF token is only reset if/when a reset was specifically requested while validating the token. Page save won't do this, but a custom CSRF check could do it. Only core feature (that I'm aware of) that resets the token is logging in... which is unlikely to occur multiple times during single browsing session 🙂

Token is stored in session data and thus indeed automatically invalidated if session expires. It can also be invalidated if another CSRF check runs meanwhile (but only if that check specifically requests that the token be regenerated, which is not the case with most core features), so technically user doing something else on the site that triggers a CSRF check could result in such an issue. (It's possible to provide an ID argument for getTokenName(), validate(), etc. which may help with this, although it is likely quite a rare occurrence.) In my experience an issue like this would most commonly be a result of something in the user's environment changing, i.e. IP or some other value used for session fingerprinting has changed and thus session gets invalidated. This behaviour can be tweaked via the $config->sessionFingerprint setting. In my opinion a background process is rarely needed / useful. I wouldn't bother with it, unless this is a critical feature that definitely should never cause errors and where users are likely to spend loads of time. Also: session_start() would not remove the fingerprint issue, so this will likely have limited applicability. You could probably build a setup where the token is checked and/or regenerated periodically, but this is most likely overengineering. By the way: you can use echo $session->CSRF->renderInput() and use if ($session->CSRF->hasValidToken()) { ... } instead of custom markup and try-catch. Not a big deal, they just make things sightly more convenient 🙂

Hey @Mats! Just gave this a try by dropping your code into Search template controller class init method (SearchController::init()) and in my case it worked right out of the box. Where did you place the code? And, just in case, which versions of Wireframe and SearchEngine do you have installed? In case requested view doesn't exist Wireframe should fall back to the default one (a behaviour I'm no longer entirely sure makes sense, but it's been like that since beginning, so not sure I want to change it either...) so you should also make sure that there definitely is a json.php view file for this template.

Glad to hear that the module is useful 🙂 Reported SQL issue should be fixed in version 1.0.1.

@erikvanberkum, I've merged your question from general support to the support thread of the FieldtypePDF module. You may also want to open an issue about this in the FieldtypePDF GitHub repository. Also, please make sure that you're running the latest version of the module 🙂

The problem here is that it depends a lot on your setup, i.e. which output strategy you're using and how your site is set up etc. 🙂 If you're using simple direct output (templates/template_name.php directly renders output) then you could do something as simple as this: <?php namespace ProcessWire; // finding results goes here if ($config->ajax) { // render results without page "frames", i.e. just the list of cards // ... and when done, halt the rendering process: $this->halt(); } // normal page output Now you just need to trigger an AJAX request to the same page, read the output, and then replace the part of the page content that you wish to be "dynamically filtered" with new content. Note that for $config->ajax to work, your AJAX request needs to include the "X-Requested-With: XMLHttpRequest" header; jQuery adds this automatically, but if you're using raw XMLHttpRequest, Fetch API, or any other approach to trigger the request then you'll likely have to add that header yourself. More examples for AJAX loading content (including alternative approach, where instead of content you return JSON and then render output in JavaScript) can be found from this thread: Loosely related, but a couple of issues I spotted in your sample code: You're passing $chan and $cont values to the selector string unfiltered. This is not a good idea: visitors could pass in characters that break the query, or even rewrite the query. Always run user-provided values through Sanitizer methods ($sanitizer->selectorValue()) is a good default, but if you're expecting integers then use $sanitizer->int(), etc. Since you're first finding all results and then limiting them, you will run into performance issues if there's a lot of data. As a general rule of thumb always include a limit in your initial selector — this way the limit is applied in the database, which is much more efficient.

Currently you could get this from the versionControlRevisions property of the page. The value of said property is an array of all existing revisions, or null if none were found, so passing it to count() will tell you how many of those there were: echo count($page->versionControlRevisions);

I can't say that I have a strong opinion here either. Also not sure if I grasp the whole context — when you say "routing" and mention URL segments, does that mean that you create routes automatically based on page structure (I assume so but...) or that there's a separate routing setup for front-end and page structure is only reflected in the data? Or do you mean something different with this? 🙂 This may or may not be related, but one thing to consider is whether you want Symprowire to be "all in", or rather something that can be used only for some parts of the site. Couple of examples from other MVC(ish) solutions: Template Engine Factory hooks before Page::render and replaces the response, but also provides hookable method (TemplateEngineFactory::shouldRenderPage) for preventing it from rendering the page, in which case the site will fall back to the regular rendering flow (whatever that happens to be). Wireframe takes an entirely different approach: instead of a hook ("enabled by default") you need to point templates that you want to render via it to the front controller file via Alternate Template Filename setting (more details in the docs). Essentially it's disabled by default. Wireframe is my pet project and something we've used for our production sites for a while now, so that's what I'm mostly familiar with. I intentionally decided not to use hooks, since I felt it was best to let the developer decide if they want to use Wireframe for everything, just a small part of the site, or something in between. In fact it's possible to skip the MVC structure entirely, and just use Wireframe for its partials and/or components 🤷‍♂️ Template Engine Factory may be a bit closer to Symprowire feature wise, although Symprowire clearly has a much larger scope (and is more opinionated). So not sure if any of what I've said here applies as-is 🙂