Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by teppo

  1. Depends a lot on the use case: if you already know the title of the page you're going to pick (and only have a single item named like that), autocomplete is nice. Otherwise it can be pretty useless (as a selection mechanism): in some cases I've actually had to open a separate tab to browse to the page in the page tree just to find a name I can then type in an autocomplete field ๐Ÿ˜…
  2. Definitely an interesting topic! We've developed a few PWA's for our clients recently, and I'd say that they've been very well received โ€” but, to be fair, they've been a) services for existing members and b) basically apps that wouldn't work (well) as regular websites, so that option was out of the question. When it comes to native vs. PWA, in our case PWA seems like the obvious choice: easy to use and efficient to maintain, upgrades are effortless, and obviously the web platform is "our thing" (more than native anyway) ๐Ÿ™‚ Some "random" websites (news sites, blogs, etc.) are now offering the option to install, but to me that feels a bit weird: unless it's a service I'm going to use regularly and there's a clear benefit for me in installing it, I don't really see the point. In fact it can also be a little intimidating: why do I need to install this service to use it? Again I think it boils down to the question of "would it work as a regular website": if the answer is "yes", then perhaps it should just be that ๐Ÿคทโ€โ™‚๏ธ (Sorry to hijack the thread, by the way!)
  3. Opened an issue for this here: https://github.com/processwire/processwire-issues/issues/1083. It's great that http to https redirects are finally in place (assuming that this was intentional), but it appears that it's going to be an issue for the core.
  4. Thanks @Mikie! I'll definitely look into the table part. There's no built-in way to get the entire index at the moment, but it might make sense to have one -- though what you're doing sounds like a perfectly good way to solve this for the time being. Anyway, I'll look into this as well. Just for the record, the renderResultsJSON method was added primarily to solve client side search needs (but I'm guessing that's not exactly what you're after) ๐Ÿ™‚
  5. Hey Pete, Thanks for looking into this! Note that this (probably) same issue is also discussed in the issues repository (https://github.com/processwire/processwire-issues/issues/1058). That issue lists some related threads here on the forums ๐Ÿ™‚
  6. 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 ๐Ÿ™‚
  7. 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 ๐Ÿ™‚
  8. 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 ๐Ÿ™‚
  9. 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.
  10. 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... ๐Ÿ˜›
  11. 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? ๐Ÿ˜…
  12. 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).
  13. 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.
  14. 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.
  15. 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.
  16. 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!
  17. 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? ๐Ÿ™‚
  18. 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).
  19. 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/.
  20. 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.
  21. 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.
  22. 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 ๐Ÿ™‚
  23. 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 ๐Ÿ˜‰
  24. 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.
  25. 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 />"; }
  • Create New...