Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by teppo

  1. This is related to the Wireframe::page() static utility method (https://wireframe-framework.com/docs/static-utility-methods/) but not specifically covered in the docs, I think. This is also one of the things I struggled trying to explain briefly in the changelog πŸ™‚ The general idea is that since Wireframe works through the Alternate Template Filename setting of templates, in earlier versions you couldn't do things like $pages->get(1234)->setLayout(null)->render() and expect the output to come from a Wireframe view UNLESS the Alternate Template Filename for the template this page uses had the alt filename pointing to a Wireframe bootstrap file (i.e. /site/templates/wireframe.php). After this update the syntax mentioned above will β€” in most cases at least β€” work right out of the box. And even in cases where it won't work (such as when you're fetching data from ProcessWire via a command-line script), Wireframe::page(1234)->setLayout(null)->render() will almost certainly work. Typical use case for me are pages that are not supposed to be directly accessible, like a contact page that lives under a shared "bucket" (e.g. /data/contacts/lastname-firstname/) and is only ever made visible when rendered as part of another page's markup. If I only need to output a few fields from the page I can do that directly in the view file for the containing page, but if I need to reuse this data all over the site, I prefer to define a view file for the contact (e.g. /site/templates/views/contact/embed.php) and render it using that: <!-- some page that lists contacts --> <?php foreach ($page->contacts as $contact): ?> <?= $contact->setLayout(null)->setView('embed')->render() ?> <?php endforeach; ?> Hope this makes more sense πŸ™‚
  2. Heya! Just released Wireframe 0.9.0. Here's the changelog for this version: ### Added - New EventListenerTrait. Currently used by Components only. Adds support for listening to and emitting events. - Support for Renderer modules for adding templating engine support for view files, component view files, etc. - New Page methods Page::viewTemplate(), Page::getViewTemplate(), and Page::setViewTemplate(). - New method Component::getData() for manually defining the data passed to the component view. ### Changed - Controller::init() and Controller::ready() are now hookable methods. - Component::setView() and Component::getView() are now final methods, preventing accidental overrides. - Layout file is no longer necessary; if it's missing, the page can be rendered using just a view file. The component system is a bit more mature now, and there are a couple of new features: Component::on('event-name', callable $callback) can be used to listen to events emitted by a Component instance, and in a Component class events can be emitted with $this->emit('event-name', array $args). This is mostly just syntactic sugar on top of the hook system, but it seemed fun and potentially useful, so... πŸ˜… The Component base class extends WireData, so by default what gets sent to the component view when a component is rendered is the internal $data array. Since 0.9.0 it's possible to alter this behaviour by implementing getData() method which returns the data that the component should expose to its view. Another "big" update is support for renderers. These are add-on modules that add support for different rendering / templating engines to Wireframe, and the first example is the Wireframe Renderer Twig module. I haven't really used a templating engine in a while so it's possible that I've missed something important, but in my limited tests the Twig engine seemed to work quite well right out of the box. I'll likely add a separate module for Latte at some point, just to make sure that the logic works for other engines as well πŸ™‚ By the way, it looks like I forgot to post here about Wireframe 0.8.0. It was released last month, and here's the related changelog entry: ### Added - Support for Components, along with a new static factory method Wireframe::component($component_name, $args). - Support for rendering pages that have not been "routed" to Wireframe using the altFilename template setting. - New static getter/factory/utility method Wireframe::page($source, $args). - New static utility method Wireframe::isInitialized(). ### Changed - Wireframe::$initialized is now a static property. This was a necessary change so that Wireframe::isInitialized() could be implemented effectively. On a related note I'm considering tagging the next release as 1.0.0. We've been using Wireframe on production sites for a while now, and I can't recall any truly breaking changes so far, so I think it's already quite stable πŸ™‚
  3. That's correct. It's a bit of a nuisance, admittedly, but I don't consider it a huge issue. It's a whole different deal when we're talking about other bundled classes – in the case of Wireframe, for an example, I already have View, Component, Controller, and Config, which would be very likely to cause issues if they weren't namespaced. In fact most of my own recent modules come with a Config class... πŸ˜› Honestly: I would probably leave the module name as-is for the time being, but at some point in the (perhaps near) future add a custom namespace and declare 3.0.150 as a dependency. But obviously it's your call – if you want to do your best to avoid any issues right now, renaming would be a safe bet. It'll force existing users to likely reinstall, but that's unlikely to become a massive issue. 50-50 πŸ™‚
  4. That's true, and one reason why historically all module files have been declared in the ProcessWire namespace – another being that most modules don't need that many classes to begin with. In cases where a module makes use of non-module classes, I would definitely recommend defining a separate (i.e. something other than ProcessWire) namespace for those πŸ™‚ (This part is also well supported, so no need to wait for 3.0.150.) Just for an example, here's how I've handled this in Wireframe: Here's the classLoader setup: https://github.com/wireframe-framework/Wireframe/blob/6530b96/Wireframe.module.php#L297:L317 In this case Wireframe "core classes" live in the /lib/ directory: https://github.com/wireframe-framework/Wireframe/tree/master/lib While namespaces are often enough to tackle the issue of clashing traits and classes, it's also a common recommendation for traits and interfaces to be named differently: SomeNameTrait, SomeNameInterface, etc. PSR also recommends (or requires, really) this approach.
  5. Thanks @nbcommunication, makes sense! If I happen to find time for this I might send you a pull request for this feature, but no pressure – I've got plenty of stuff on my plate as well, and even if I do send such a PR, it's perfectly fine if you don't think the suggested solution is good enough... πŸ˜›
  6. Hey @nbcommunication! Just wondering: do you think it would make sense to implement picture support into this module, or do you see that as a completely unrelated thing? πŸ™‚ The background is that I'm currently looking into ways of handling webp+srcset. Since IE and Safari don't support webp, a fallback is necessary, yet none of the .htaccess fallback solutions are (in my opinion) really up to the task. Every solution I've found so far comes with drawbacks that would eventually cause issues for our clients. Best solution so far seems to be <picture> with fallback <img> element. I could build a (very simple) markup module that just outputs the picture element for me (it's not a whole lot of boilerplate, but still a bit bothersome to write all over the place), but then it occurred to me that since I'm going to need this module anyway, wouldn't it be awesome if I could just call Pageimage::render() and this module would handle the rest. What do you think? πŸ˜…
  7. 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).
  8. teppo

    ProcessWire on the web

    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.
  9. 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.
  10. 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.
  11. 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!
  12. 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? πŸ™‚
  13. 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).
  14. 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/.
  15. 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.
  16. teppo

    ProcessWire on the web

    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.
  17. 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 πŸ™‚
  18. 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 πŸ˜‰
  19. teppo

    ProcessWire on the web

    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.
  20. 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 />"; }
  21. 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 πŸ˜…
  22. 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 πŸ€·β€β™‚οΈ
  23. 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 πŸ™‚
  24. 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.
  25. 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 πŸ€”
  • Create New...