Jump to content

teppo

PW-Moderators
  • Content Count

    2,596
  • Joined

  • Last visited

  • Days Won

    66

Everything posted by teppo

  1. 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.
  2. 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 🤔
  3. 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 🙂
  4. 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.
  5. 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.)
  6. 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.
  7. 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.
  8. 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?
  9. 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 🙂
  10. 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 🙂
  11. 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.
  12. Hey there Jim, welcome to the forum! I've seen a few other reports related to the developer directory pop up lately as well. @Pete, you aware of these? 🙂
  13. A bit off-topic, but while typecasting an empty array to boolean does indeed result in false, "empty($array)" has its benefits. It's slightly more verbose, but it also won't cause a notice if $array hasn't been defined yet, and it's arguably more obvious (leading to better readability). Relying on typecasting can sometimes result in obscure issues, as well as make the code ever so slightly harder to decipher. Using "count" to check if an array is empty is a common mistake. Even if in most cases the actual performance difference is too small to really matter, there's no reason to do this 👍🙂
  14. Sad to see you go, but this seems like a reasonable conclusion in your case 😕 Regarding your issue – I've never come across anything exactly similar myself. Since we're talking about the default multi-language site profile, there's very little data to load, so my initial guess would be that the request, or perhaps the PHP process, gets stuck somewhere. In the case of PHP the file compiler (core feature originally intended to ease migration from 2.x to 3.x) comes to mind – though that probably shouldn't be the case here – while disk based sessions could be another. Of course the database connection could also be the bottleneck, but if you're sure that it's configured properly, then I have no idea how it could be that slow. MySQL slow query log could help in ruling this issue out though. If you still want to debug this further, you might want to give database sessions a try (they can be enabled by installing the Sessions / ProcessSessionDB module, which is bundled with the core package), and just in case specifically disable the file compiler by setting $config->moduleCompile and $config->templateCompile to false in /site/config.php. I have no recent experience with Windows, so not sure if something there could cause the slowdown. That being said, I do know that others are running ProcessWire on Windows, so that alone shouldn't be a problem, unless it's some rather obscure configuration issue there. If other systems are working as expected then a configuration issue sounds less likely. While WordPress admittedly caters for a number of really unlikely borderline cases (including the use of the deprecated mysql PHP extension), Laravel working as expected probably means that the environment itself is properly set up.
  15. I merged your question to the correct thread earlier, so yes – this is it 🙂
  16. Hey @DL7, just a quick heads-up: I've merged your questions into the support thread for the Admin Restrict Page Tree. The modules/plugins area of the forum is intended for module-specific support threads (one per module), and you can find the correct thread via the modules directory.
  17. Hey @Mike Rockett. I'd be happy to try, if you're busy. I've got a need for this in one of my current projects anyway 🙂
  18. Just for the record (not saying that it would be the best solution overall), FieldtypePageIDs also has certain benefits if/when the problem is loading too many Page objects into memory. It could be worth looking into in this sort of situation 🙂
  19. Another +1 from here. If a module I maintain works for something other than Uikit then that's brilliant – but if it doesn't, I won't lose any sleep over it. For quite a while I used to support the "legacy" theme, new default theme, and Reno theme, but that was a major headache. There will no doubt be sites running those older themes for quite a while, but my guess / gut feeling would be that a notable portion of those are older sites that probably aren't that actively developed anyway.
  20. Hey @Mike Rockett! I'm wondering if there's some way to add support for URL segments in the module. Any chance you might've figured this out already? 🙂 Basically in my use case there are pages that list items below them, yet those items actually live outside of the publicly viewable page tree. It's a no-brainer that they wont work right out of the box, but what I'm wondering is if we could somehow – hook or some template setting or something – inform MarkupSitemap of these "non-pages", and add them to the sitemap. I had a quick look at the codebase, and I'm wondering if this could be achieved by an optional hook in MarkupSitemap::addPages, perhaps by passing $page and $url to a hookable method after calling $this->urlSet->addUrl($url)? Seems that this way I could add a custom round of iteration and also add those URL segments as new URLs to the URL set 🙂
  21. @Mike Rockett, sorry to bother you with this again, but with version 1.5.56 of Jumplinks we're still seeing quite a few database errors: Looking at the database the column is now varchar(512), but it seems that's just not enough. On a related note: on this site "Log 404 hits to the database" isn't checked, so I'm wondering why this is still happening? This is unrelated to the database issue above, but it also seems that there might be some unnecessary / unexpected process going on in here 🙂
  22. If you're using the code you posted earlier, i.e. "$results = $pages->find(...)" and "$out.= $results->renderPager()", SearchEngine settings won't kick in at all. This is plain old native ProcessWire stuff, so you'd have to provide pager settings directly to the renderPager() method 🙂 SearchEngine pager_args only apply if you're using it's native rendering features. Though please let me know if I'm missing the point here!
  23. Hey @guy, thanks for sharing this! Unless I've missed something important, note that your module doesn't actually have to hook into WireMail::___send() – it's a WireMail module, so it should implement its own ___send() method instead. This is how WireMail modules are designed to work, and it also guarantees proper interoperability in the case that other WireMail modules are installed 🙂 See WireMailMailgun for a reference.
  24. Just released SearchEngine 0.13.0. This version adds more validation regarding the search index field: there's a warning if the field is of wrong type, an option to automatically create it if it doesn't exist (i.e. it has been removed after the module was installed), and there's a notice in the module settings screen if the index field exists and is valid but hasn't been added to any templates yet. Additionally there's a fix for an issue where FieldtypeTextareaLanguage wasn't recognised as a valid index field type in module settings. This could've resulted in the index field setting getting unintentionally cleared if/when module settings were saved.
  25. The trick is to whitelist "q", after which MarkupPagerNav automatically sticks with it. Add this after you've validated the $q variable: $input->whitelist('q', $q); Note also that if this is your literal code, you should move the renderPager call in the if statement – if $q isn't set or validated, $results will be null, and this will cause an error 🙂
×
×
  • Create New...