teppo

Since it's presumably a one time thing, I would at least consider going with Apache rewrites for the old URLs. This should have better performance, and it should also be quite easy to handle. You might be able to do this with some simple rules assuming that the old slugs are directly converted to ProcessWire page names, and if not, you could set up a RewriteMap file instead (https://httpd.apache.org/docs/2.4/rewrite/rewritemap.html).

Well, that was... interesting 🙂 I can only guess that someone somewhere used ProcessWire to build a really, really complex website (it's very much doable, and I've come across a few of those as well), and that's what this person is actually writing a review for. When you're not particularly familiar with ProcessWire or its inner workings, it's easy to take a look at a specific implementation and assume that it represents the entire platform (both in good and bad). As always it'd be interesting to hear a bit more about the specifics that led to such outburst, but as it stands, this review provides little value for anyone.

What wbmnfktr said. Also it might be a good idea to check that .htaccess is actually in use: I usually check this just by inserting something obviously broken there; if the site still works, the whole .htaccess file is likely being ignored 🙂 Note: you don't have to restart Apache after .htaccess changes, they will work (or not work...) instantly.

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 😅