teppo

I wouldn't really call this a problem, though ? Page::render() is not an isolated process, and this is by design. If you define functions in template files – or files you potentially include multiple times – you should always wrap them in "if (!function_exists('your-function') { ... }". Or, alternatively, split them into a separate file that gets included only once per execution with include_once or require_once.

Sounds like a HTML Purifier issue: http://htmlpurifier.org/phorum/read.php?3,7744. Can't really say more than that right now – never seen this issue before. Edit: /site/assets/cache/MarkupHTMLPurifier/ contains .ser files that are related to this issue. You could try clearing those out – though be sure to back them up first, just in case they can't be automatically recreated!

If the issue is that stub files are not being synced from the server to your local environment, you can just go to the module config on your local develoment site and change the class prefix to something else (say, tpl2_) and then restore it to whatever it was (such as tpl_). Every time you change this variable stub files are removed and then recreated, so this way you can force the module to create local stub files for you. Does that make sense? ?

I think providing an option for this would indeed be sensible ? While testing the module I found it quite simple to regenerate the template stubs content on the local environment – this way there's no real need to sync stub files, and if you've got a full environment locally you can do this just by changing the prefix for something else and then restoring the old value. I'm currently running a slightly modified version of the module with a regenerate option in module config; seemed like a good idea at first, but not sure anymore. Might send a PR and let Robin decide ? Also, just in case there are other VSCode users here, a couple of pointers for getting things up and running: If you've excluded the /site/assets/cache/ directory (I had), you'll have to change the exclude setting. Sadly VSCode doesn't support full glob syntax, but ignoring everything except certain subdirectories is still doable with a hacky workaround (more discussion here) : "files.exclude": { "**/site/assets/cache/{[^A],?[^u],??[^t],???[^o],????[^T],?????[^e],??????[^m],???????[^p],????????[^l]}*": true, }, Suggested syntax for var (/* @var tpl_basic_page $page */) won't work, since VSCode expects valid PHPDoc syntax. Use /** @var tpl_basic_page $page */ instead. I'm using the PHP Intelephense plugin (bmewburn.vscode-intelephense-client), and after resolving aforementioned inconveniences things are working just fine ? Edit: sent a PR for the regenerate stubs option (https://github.com/Toutouwai/AutoTemplateStubs/pull/4).

Brilliant! I never got into the habit of using Template Stubs (mostly since at the time I didn't use an IDE that would've benefitted from it) but I'm definitely going to give this module a try now ? One thing I'm wondering, though, is the directory for the stubs. Unless I'm misreading this, currently it needs to be under the AutoTemplateStubs module directory? This is a bit of a problem for me: first of all (as a matter of principle, mostly due to security concerns) I never allow PHP to write into the modules directory, so this would require some tweaking on a per-directory basis – and second of all it would force me to run these files through version control and a deploy process (which could also be seen as a good thing, but for the time being I would prefer to avoid that). Would you consider adding a config setting for storing these files somewhere else? That "somewhere else" could be a folder under cache, perhaps /site/assets/cache/AutoTemplateStubs/.

Out of curiosity, how tight is the coupling between this inputfield and LoginRegisterPro / a specific form in it? ? I'm working on a project that will require front-end uploads. It's not a huge deal – I can handle that in other ways as well – but just wondering if I could possibly use this new inputfield for those. These uploads would have nothing to do with the LoginRegisterPro module specifically, but I might still find good use for it on this particular project.

Before you get too excited, I'd like to point out that it's hard to say how much of the GUI in the video is related to ProcessWire – a lot of the URLs go to .php files, etc. Looking at their references I can see some ProcessWire–ish stuff, but honestly I couldn't say for sure what the platform is. I can only assume that the folks behind the blog know something I don't... ? Anyway, it seems that this is a hosted solution.

Seemed (loosely) relevant: ... and since @wbmnfktr mentioned synthwave earlier, I have to throw a bunch of actual favourites in: Scandroid, Zombie Hyperdrive, and Carpenter Brut. All synthwave music, but each band has its unique approach or "theme". Synthwave in general is a great fit with programming ?

Heya! Just wanted to drop in to mention that this was a difficult one: I'm interested in this topic in general, but you kind of lost me at Delphi (Pascal). Although, that being said, the Embarcadero website makes their platform look interesting (and looking around a bit, I see folks advocating for it), so might still come around. Anyway, just wanted to clarify why I voted for "not really interested". Wish there was a "mildly interested" or "could be persuaded" option ?

It's just a small mention, but web-ostajanopas.fi ("web buyers guide", a Finnish blog managed by consult company North Patrol) recently listed most popular ecommerce platforms used by bigger Finnish companies, and ProcessWire found its way to the top 10 with a ~3% market share ? https://web-ostajanopas.fi/2019/06/17/datakatsaus-isojen-kotimaisten-verkkokauppojen-teknologiat-vuonna-2019/ Just last month they did a separate mobile speed comparison of the top 10, and here ProcessWire was the fastest of the bunch (although admittedly the key finding in their study was that, generally speaking, the mobile performance of Finnish ecommerce sites is pretty bad). It seems that the data for PW is largely due to one product: the ecommerce platform from Oscar Software, which (according to North Patrol) was built on top of ProcessWire.

Perhaps something like this? $session->history = is_array($session->history) ? array_slice(array_unique(array_merge([$page->id], $session->history)), 0, 4) : [$page->id]; And when you're displaying the history, just skip over current page: foreach ($session->history as $page_id) { if ($page_id == $page->id) continue; $p = $pages->get($page_id); echo "<a href='{$p->url}'>{$p->title}</a><br />"; }

Hey @alexmercenary! Which version of VersionControl are you using? I can see where the error is coming, and I don't think that line of code should've worked in years. Committed a fix, but the modules directory entry is not updated yet, so it may take a while for this to show up in the built-in module installer (seems that I've lost my password for this module and can't update it manually in the directory, I'll have to guess that first...) Not sure why this popped up only now, though – so hopefully I didn't break anything with the fix ?

Great to hear that it's working now ? As I mentioned above, in my case FileCompiler issues have usually been a result of something other than the Apache user (www-data, i.e. web requests) starting up (bootstrapping) ProcessWire and/or creating directories/files on the disk. Cron scripts or some scripts you might('ve) run manually on the server. So if you have scripts that could've bootstrapped ProcessWire or performed actions on (cache)files of the site, there's one possible culprit at least. Of course it could also be some strange server-side issue, or a configuration change somewhere (though you did say that such changes shouldn't have happened, so this does seem unlikely). You mentioned changing something in Hanna Code; while I can't think of a direct connection right away, it does seem like a curious coincidence. Hanna Code writes files under cache as well, but it really shouldn't have any effect on FileCompiler... but it could be a combination of multiple things, who knows ?‍♂️

ProcessRedirects missing the namespace definitely sounds like a FileCompiler issue. It's an old module and I'm pretty sure that even the latest versions don't have namespace defined (on mobile so can't check right now), but in such cases FileCompiler should kick in and store the compiled, namespaced version under cache ?

Mostly a guess, but similar issues have occurred when FileCompiler cache is empty, and then it gets populated by some cron script, after which the web server user (www-data or something else, depends on the server) doesn't have access to it. I'd start by a) making sure that FileCompiler is enabled (site config, it's enabled by default) and b) clearing FileCompiler folder under /site/assests/cache/ and making sure that it's writable for your apache user.

Hey Ryan. Great summary, thanks (and congrats!) Just noticed that the Packagist version is lagging behind – it's still showing 3.0.123 as the latest master. Would be great if you could give it a little nudge ? Seems that the connection between the GitHub repository and Packagist isn't working quite as expected, and clearly it's not just limited to the dev branch. Perhaps it needs to be re-approved or something ?

I'm definitely interested in "modularizing" this part, or alternatively adding support in some other easy-to-enable way. Modules would be a logical solution, but on the other hand it could be even nicer if there was a way (perhaps via Composer) to skip the module part, install the engine, and be done with it. Might be too much to ask, but who knows, maybe I could still make it work out of the box for a couple of popular engines or something ? I had a quick read about Smarty before posting here, and my initial impression was that it was somewhat obsolete – though now that I've actually checked out their site, it seems that it's at least receiving regular updates, so perhaps that text was a bit opinionated (what a shocker – someone on the Internet might not have been objective ?‍♂️) They mentioned Smarty being slower these days (apparently it used to be categorically faster than Twig or something), and also talked about it "not being secure by default" (which, I assume, was referring to not automatically escaping content). Not sure how much of those is really true either. I must admit that right now I'm inclined to favour Twig, though, even if for the reason that – in my opinion – a templating language that allows PHP kind of misses the point. I get why one might want to do that, but the way I see it, that eliminates a couple of major reasons to use a templating language in the first place... and suggests that perhaps PHP might've been a better choice in the first place ? Back in the days I wrote a blog post comparing PHP and Twig, but let's not go there now – opinions and all that ? I'll definitely take a closer look at your tutorials, thanks for reminding me of these! And yes, I do think that Twig support would make sense. Honestly the main reason I've included Blade at the top of my list is the Laravel connection: if Blade support could make it easier for someone to move from Laravel to ProcessWire, that'd be a nice little bonus ? I can definitely see your point. Wireframe itself currently requires PHP 7.1, and officially I've recommended going with one of the supported PHP versions, which at the moment means at least 7.2. PHP 7.1 was EOL'd at the beginning of December, so technically using it is no longer recommended (although if it came with a supported Linux distro, it might still be receiving security updates.) As such, I don't think that any of these frameworks is really going too fast – but I do appreciate your point of view and the info you've dug out (I had no idea which versions were supported) ? You're also right in that it's problematic if the engine isn't well supported. The problem with Blade is that I'd like to support it (due to the Laravel connection), but the official releases are not standalone. As such, it would have to be one of the "unofficial" spin-offs, which I'll admit is not an ideal situation. I've experienced this first hand in the past (with Dust). Twig and Latte definitely have the upper hand here. Markup Regions is on my todo list, but I can honestly say that I haven't given it much thought yet. I can see how that would make certain things easier, but I'm also afraid that it'll make it very, very hard to figure out what's going on – mixing Wireframe concepts (layouts, placeholders, partials, and components in particular) with markup regions seems like it could be powerful, but there's a truckload of confusion ahead if one dares to dive too deep into that particular rabbits hole ? Thanks everyone for your comments so far! At the moment I'm leaning towards Twig as the first experiment, then Latte (if all goes well), and finally Blade. Unless some new information shows up, that is. Apparently there haven't been that many major changes in this field lately – I used Twig with some Zend Framework projects back in the days, and by the looks of it it's still going strong ?

Hey folks! I've been thinking of adding templating engine support for Wireframe, preferably in a way that supports multiple templating engines (module per engine, or some other way to set up the preferred engine), but realise that I don't really have the foggiest which engines folks prefer these days. I'm sure some of you are way more knowledgeable than me in this regard, so I'd lie to ask for your suggestions and/or opinions first ? My current list looks like this – loosely ordered by how much weight I'm thinking it should have: Blade (part of Laravel – standalone from https://github.com/jenssegers/blade) Twig (https://twig.symfony.com/) Latte (https://latte.nette.org/) (Dust PHP) * Anything I'm missing? What about the order, does it make sense? ? * Dust lingers on the list mainly because it's the last templating language I've used. It's a JS thingy ported to PHP, not very popular as far as I know, and not very well maintained, so not sure if it's really worth the trouble.

Just a quick heads-up that I've made a couple of updates to MarkupMenu recently: ## [0.8.0] - 2019-12-25 ### Added - Support for passing in a prepopulated PageArray of menu items via the menu_items option. ### Fixed - Fixed an issue where include option root_page wasn't being properly reset (since 0.7.0). ## [0.7.0] - 2019-12-18 ### Added - New hookable method getItems(). ### Changed - Method renderTreeItem() made hookable. 0.7.0 made it possible to hook to the point when menu items are fetched (for an example if you need to inject a new item or remove an item at some specific point), and 0.8.0 added support for passing in a pre-defined PageArray to use as the first level of menu items (the need for this came up on a project where a menu was manually defined using a Page Reference field.)

I can't claim with a straight face that I would've wholeheartedly agreed with every single addition made during the past few years, but neither can I agree with this statement. The truth is that whenever I work with pre-3.x versions of ProcessWire, it reminds me just how much more powerful the system is now. Keeping the system evolving and maintaining the balance is a difficult task, and I think Ryan has done a terrific job in that regard. I guess my point is that more features doesn't automatically equal bloat. Sometimes more is just more: more options and more power. That's all.

I would recommend doing this on the front-end: when the close button is clicked, hide the box and set a cookie. Check the cookie on page load (with JavaScript) and only show the box if the cookie isn't set. This is all pretty simple, and you can likely find a pre-built solution with a bit of googling. If front-end implementation isn't, for whatever reason, possible, you can also also set the cookie with PHP (if you're running ProcessWire 3.0.141 dev or later, check out $input->cookie) or use $session to remember that the user has closed the box. This will, though, require that you pass the request to PHP first – for an example the "close button" could actually be a link to something like "/?close_the_box=1" which then triggers required PHP code in your home template, or you could perform this query with JavaScript when the button is clicked. Hope this helps a bit.

Hey folks! I've been a bit quiet here, but that's mostly because I've been busy building stuff with ProcessWire and Wireframe ? Just wanted to give a quick heads-up for a new feature called components that I'm currently testing (it's in the dev branch of the module already), in case anyone wants to comment on it before it gets merged to the master branch. Wireframe components are classes extending an abstract base class (\Wireframe\Component), and they can either render output directly by implementing the render() method, or they can be rendered using a separate Component View file. This is probably a familiar concept to most, but the general idea is that while partials ("dumb" files with no way to process params, and no clean way to separate code from markup) are enough if you just have some relatively static snippet that you need repeatedly, components add an extra layer where you can a) specify which params they accept, b) process those params, and c) include any additional "business logic" that should be triggered when the component is rendered. Here's a simplified example of how this comes together: /site/templates/components/Card.php (class for the Card component) <?php namespace Wireframe\Component; /** * Card component */ class Card extends \Wireframe\Component { /** * Constructor method * * @param \ProcessWire\Page $item Page related to current Card. */ public function __construct(\ProcessWire\Page $item) { // Pass properties to view $this->title = $item->title; $this->summary = $item->summary; $this->image = $item->get('image|hero_image'); } } /site/templates/components/Card/default.php (default view for the Card component) <?php namespace ProcessWire; ?> <div class="card"> <?php if ($image): ?> <img src="<?= $image->size(640, 480)->url ?>" alt="<?= $image->description ?>"> <?php endif; ?> <h3><?= $title ?></h3> <?php if ($summary): ?> <p><?= $summary ?></p> <?php endif; ?> </div> ... and for fetching and rendering the component, there's a little static helper in the Wireframe module class: <?php foreach ($cards as item): ?> <?= Wireframe::component('Card', [$item]) ?> <?php endforeach; ?> Note that Wireframe::component() actually returns an instance of the component class, not a string, but since \Wireframe\Component::__toString() calls \Wireframe\Component::render(), what we're doing here is essentially the same as echoing out the result of (new \Wireframe\Component\Card($card))->render() ? So, anyway, that's basically what I've been working on here. I'd be happy to hear if you have any comments on this addition – I haven't yet merged it to master since I'm still experimenting with it, and I'd like to avoid as many breaking changes in the master branch as I can. So far this has worked great for me, but to be honest my requirements have been pretty basic. Thoughts?

Hey @verdeandrea! Questions related to ProCache should be posted to the ProCache VIP support area here on the forums. When you bought ProCache you should've gotten access to this area, but if you didn't, please send a message to Ryan. The modules/plugins area of the forum is intended for third party module support threads (one per module), so I'm moving this thread to general support. Please let me know if you want it moved to the ProCache support area instead ?

To be fair PHP 7.4 has only been out for a few weeks. I'm not advocating sticking with old versions for any longer than is necessary, but as with most software, going with the cutting edge version of PHP is a bit of a risky move. I'd recommend giving it a few more weeks at least ?

Not familiar with Azure service apps (?) but a 500 error should always leave a log trail. I'd definitely start by hunting down those log entries and see from there how to go further – it's difficult to say much more based on this alone, sorry.