teppo

We're using a similar approach: install ProcessWire via Composer and then use post-install-cmd and post-update-cmd to copy the wire folder from vendor to web root. It would be preferable not to have to do the whole post-[install/update]-cmd step (or have entire wire directory in public directory for that matter) but to be honest this works quite well. Some files in wire need to be web accessible, so I'm not aware of any clean way around this. To be clear this is about installing and/or updating ProcessWire on a site that has already been set up. As for setting up a complete, new ProcessWire setup via Composer... I've no experience about that. Technically you could install ProcessWire via Composer and then copy everything from vendor/processwire/processwire/ to your web root, but for my use cases that has never really made sense ?

I've not heard of this module being discontinued, probably just some sort of a mishap. If you're interested in ProDrafts, I would recommend sending a PM to @ryan.

Technically speaking best approach would be to block the IP as early as possible: preferably via firewall (on local machine or before it), but if that's not possible then Apache config, and if that's not possible either then .htaccess. Blocking access early means that more unwanted traffic gets blocked out, and it is also better for performance ? That being said, I just updated https://processwire.com/modules/page-render-iprestriction/ to support a list of blocked IP addresses. This module can block access to your site, but note that it won't attempt to protect your static files, so again other alternatives are generally speaking preferable.

Thanks for the update, link fixed!

Just to be clear, which version of ProcessWire are you using? The implementation for populating pages_parents has changed a few times even in recent versions. Anyway, my understanding is that pages_parents should contain every page that has children — but again, the implementation has changed a few times, and earlier versions (before 3.0.165?) were not entirely reliable. Meanwhile the very latest dev version has another approach that fixes scalability issues that were introduced around 3.0.165, but this version is considered experimental ?

https://processwire.com/modules/lister-native-date-format/ is great for formatting lister dates, by the way. You can configure preferred default format for native date fields and switch format on the fly ?

@adrian, I've got one more request (kind of). Earlier you added composer.json, but didn't yet push the project to packagist.org. Would be nice if you could add the module there as well, otherwise it can only be installed by adding the GitHub repository directly. Thanks in advance! ?

Brilliant, thank you Adrian!

Not really. I've had some issues in the past, mostly related to disk cache getting out of sync or somehow the module compilation itself messing up the code (but such cases have been super rare). Mostly it just feels unnecessary and a bit "off" to have a separate copy of the code and then have the system abstract that layer away. If I could, I would likely disable module compilation entirely from my/our projects (just like template compilation), but there are indeed still some modules that depend on it, so for now it's a no-go ?

One more thing: I'm wondering if there's some use case where current way of getting properties via eval is necessary? I don't see anything technically wrong with that, but would feel better not using eval at all, and it tends to get flagged by security audits etc. This seems to achieve largely similar results, at least in latest PW version: $replacement = $p->get(implode('.', $properties)); Again my use case for this module is very limited for now, so may be missing something important.

Hey @adrian! Might be a strange use case (considering that it doesn't seem to be supported yet), but I'd like to use this module for a field that's locked (non-editable). Looks like hooking into Inputfield::render won't work in this case, while Inputfield::renderReadyHook does work. To be honest I'm not sure what else that might change/break ? I've made that change locally since this is indeed something I need, and so far it seems to work (though not much testing done yet). Also... have you considered updating the module to PW3? I mean adding the namespace, mainly, so that module compile wouldn't be needed. And it would be great to have this module installable via Composer. Food for thought ??

As someone who does a lot of local development, sometimes with no Internet access or extremely slow one (e.g. while travelling), this would not be preferable. Having everything available locally guarantees that things work as expected. Also it guarantees that the version I have can't be compromised by malicious actors. Assuming, of course, that it was safe in the first place ? Personally I don't have an issue with Ace, but if Monaco (or something else) does similar things with less overhead then why not ?

So, I'm currently having a conversation with ChatGPT about a new module ? Feels weird to be honest: it's quick to answer, especially at first seemed absolutely certain that every answer was the correct one, and kept making obvious mistakes. But that being said: I could've taken the initial code, made a few changes here and there, and it would've been a functional module. Now, after some iterations, it's looking almost perfect. One problem I'm having is that the bot keeps stopping halfway through the answer. When I tried to confront if it about that, this is how it responded: Not sure we're quite on the same page here ? Anyway, it looks like I might be able to take the code provided by the bot, polish it a bit, and put it in use. Sure it required us a dozen tries or so to get here, I had to patiently keep pointing out mistakes and suggest actual hookable methods instead of the non-existing ones that it pulled out of thin air, but that is very impressive nevertheless. I can definitely see how this would be useful for something a little simpler ?

If the error message is pointing to the correct line, then this does not look like a PHP 8 issue. That line should be valid in PHP 7.4 or any later version. I would double check that you're running the code on correct PHP version, and also that this is an actual error you get while running the code (not just in your code editor, where the check may potentially be performed by locally installed PHP or something along those lines). There may, of course, be other PHP 8 incompatibilities in the library ?

Been over a year since last update, so another quick heads-up: MarkupMenu 0.11.0 adds support for menu items as an array (as an alternative for the module figuring the menu structure out from current and root page, or reading it from a PageArray) and template strings as callables. Needed these two for a project I'm working on ? echo $modules->get('MarkupMenu')->render([ 'current_page' => $page, 'menu_items' => [ [ 'title' => 'Home', 'url' => '/', 'id' => 1, ], [ 'title' => 'About', 'url' => '/about/', 'id' => 29, ], [ 'title' => 'Parent', 'children' => [ // ... ], ], ], 'templates' => [ 'item' => function($item) { return empty($item->url) ? '<span>{item.title}</span>' : '<a href="{item.url}" class="{classes} {class}--level-{level}">{item.title}</a>'; }, ], ]);

No, but looks interesting ?

Hey @Sten, Sounds like your field (moment) may be configured to output a date that strtotime doesn't understand. You could test by seeing what "echo $event->moment" returns; is it "2023-04-03 18:30:00" or something else? Anyway, one way to resolve this would be to replace "$moment=strtotime($event->moment)" with $event->getUnformatted('moment'). This will return a timestamp, so strtotime is no longer required.

Short answer is "no", at least not for now ? SE populates a search index for a piece of content (page) and compares provided query string against said index. It's a tool for handling "regular" site search, from indexing to front-end rendering. The index is a textarea field, so complex queries (advanced text search) and a few special cases ("link:https://www.processwire.com") are supported, but the module has little to do with facets/filters. On a loosely related note, in recent projects I've been leaning towards implementing filters/facets on the front-end based on static data generated by the backend and cached on disk. The main reasons are performance and scalability: real-time search using ProcessWire can be pretty quick, but won't achieve the speed of a front-end only implementation. This is especially tempting approach when the amount of data is relatively small (i.e. you don't have to deal with tens of thousands of pages (or more) with numerous searchable properties each.) Which approach makes most sense — and how vigorously the search should / needs to be optimized — depends on the case at hand ?

Hey @Mats, In this case you're setting view directly on the View object, so you should read it from there as well: // in controller $this->view->setView('buy'); // in view file echo $this->getView();

Both parts of the site look really nice! Tiny display issue with "do you recommend this tour":

Hey @Spiria — just a heads-up that I have merged your post to the Menu Builder support thread. Official support thread is the best way to reach module author. Looking back to the report in 2021, it looks like that earlier report might've just gone unnoticed.

Looks like MarkupHTMLPurifier used to skip tel: links in the past due to HTML Purifier not supporting them. This bypass was removed in 3.0.137, so after that version tel: links have likely had to adhere to stricter rules. I would likely go with this option, to be honest. But perhaps someone else knows how to customize Purifier — I've tried it once or twice, but eventually had to give up ?

I don't think there's any obvious way around this: PHP considers namespace declarations and use statements (aliasing/importing) on a per file basis. (Technically this could be achieved by some sort of file complication scheme, but in my opinion issues with that approach would easily outweight potential benefits.) It's a matter of preference of course, but I often use full namespace (e.g. \Wireframe\Lib\Utils::some_method()) in my views. Just feels more intuitive to me, even if it does add a bit of verbosity ?

See the first bullet point under "Docker desktop may be used for free as part of a Docker Personal subscription for": This is repeated in other documents, including the service agreement. You don't have to (and can't, that would be quite impossible) fill all the conditions for free use, just one, and use within "small companies" (or "small businesses") is one of them.

Docker FAQ seems to disagree: This is further clarified in the Docker Subscription Service Agreement: The Service Agreement is a bit messy (kind of seems like they might've updated one section and forgot another, so numerals are not in sync), but at least based on this the small business exception is still in place and applies to the desktop component as well ?