teppo

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 🙂

Was a bit slow to answer, so @gornycreative pretty much covered this already, but just to be clear: in my experience most of them are still valid. Potential exceptions may, for an example, include modules that for some reason rely heavily on a certain admin theme. Overall there have been very few breaking changes in the core through the years, so most — probably close to all — modules that worked for 3.0 (or even 2.x versions) still work today, some may just look a bit off. Or there may be a core feature nowadays that solves a similar need without a need for third party module 🙂 One thing worth keeping in mind is thatolder modules typically don't have/use the ProcessWire namespace, which means that you'll have to keep FileCompiler enabled for modules. This is the case by default, so not a problem unless you've intentionally disabled $config->moduleCompile via site/config.php. I must admit that this confused me a bit. If you're just looking to see which field is attached to which page, that doesn't sound like a reason to switch entire admin theme. Admin themes are generally more about the look and feel of the admin, not so much about the features included, while this sounds like a rather specific feature. I can't remember if I've seen exactly this type of list myself; fields are connected to templates, so usually you'd want to see which templates a field belongs to or which pages use a specific template, rather than which pages use a specific field 🙂 If you're interested which fields have a value in specific field, then that's a different story. You can use the built-in pages find feature to list pages where that field is not empty: Also, as a general rule of thumb — and this is definitely more than a bit opinionated — I wouldn't recommend installing new admin themes unless you know what you're doing. While admin themes can be changed, and third party admin themes may work perfectly fine, generally speaking admin features are most likely to work best with the default (Uikit) admin theme. Then again, "at your own risk" is often just something developers say when they put stuff out there. It doesn't necessarily mean that something is broken — just that there's no guarantee that it will, and also no warranty in case it doesn't work 🙂 Don't worry, asking questions is A-OK 🙂

Hey @fruid, just noticed this post in the modules forum. It would be best to post ProMailer specific questions to the ProMailer (VIP) support area of the forum — this way Ryan will notice them. I've never used a subscription form from ProMailer myself so can't really answer right away, but it looks like form markup is defined (and can be customized) via promailer-subscribe.php. You can find instructions for modifying ProMailer templates from https://processwire.com/store/pro-mailer/manual/#about-the-promailer-subscribe-page-template-file (specifically take a closer look at the part starting with "If you have any custom fields you also want to use, please do the following" under "Modifying the “Subscribe” form"). Custom fields are explained at https://processwire.com/store/pro-mailer/manual/#custom-fields-reference. -- The modules area of the forum is intended for module-specific support threads (one thread per module) so I'm moving this thread to "General Support".

Hey @bernhard, I'm considering RockMigrations for a new project, but would very much prefer to install it via Composer to avoid bundling module code with project code, make updates easier, etc. I noticed that your old RockMigrations project had a composer.json in place, so would you mind adding that here as well, and preferably also submitting the package to packagist.org? Thanks in advance! 🙂 Note that I would recommend using the options outlined here: ... instead of hari/pw-module. The installer plugin from Hari was updated a while ago to support Composer 2, but it still lacks support for custom modules directory, for an example. In my opinion it would be best to eventually migrate modules to use composer/installers, since that's the "official" solution.

This is the expected behaviour, with one catch: users with edit access to said pages should be able to view them. This always includes superusers. If you are certain that the sites themselves are identical (code and site settings, template settings, permissions, etc.) there are a couple of things to check first: - Is there some sort of caching on the live site that isn't present on the working environment? - Is the admin domain the same as the one used after clicking "view" links on the live site?

Not a Drupal developer (unless a small course on D6 years ago counts...) so this is the best I can do. You've got this 🙂 Honestly, my two cents would be to try to embrace Drupal properly before making decisions about whether you like it. In my experience every major platform has ins and outs, some of which may take a while to grasp. I'm sure there's a lot of good in Drupal as well; for an example it sounds like they have solid integrations with many development-oriented tools, from Symfony components to Composer, PHPUnit and Nightwatch for testing, etc. Silver lining: sounds like an interesting learning opportunity! As for pushing ProcessWire, that may indeed be hard, especially if they have a good flow with Drupal. In terms of sales Drupal likely has an edge as well: a lot of folks have the impressions that Drupal is the go-to system for "enterprise open-source" content management, which is can make it easier to sell to certain types of clients. Perhaps suggest doing some smaller or in-house projects with PW, and see where it goes? Pushing anything too hard, especially to other developers, has a tendency to backfire 😉

If you're looking for a generic catch-all solution, there's one approach that I can think of: hooking before WireMail::send and checking if $event->object->bodyHTML is empty but $event->object->body filled, in which case you could generate the "bodyHTML" property based on the "body" property. I've never tried this, but at least this is where I'd start. Looking at ProcessForgotPassword code, there's no obvious way (config setting, hook, etc.) to make it send all messages as HTML, and I would assume that same applies to various other core (and non-core) modules as well, so your best bet is to hook directly into the class responsible for sending the message(s). Basically something like this: wire()->addHookBefore('WireMail::send', function(HookEvent $event) { if ($event->object->body && !$event->object->bodyHTML) { $event->replace = true; wireMail( $event->object->to, $event->object->from, $event->object->subject, $event->object->body, "<p>" . nl2br($event->object->body) . "</p>" ); } });

If I got this right, you have a single images field that you use for two purposes: for images that are (automatically) displayed in a carousel, and for images that are (manually) embedded within a CKEditor (rich text) field? Simply put, my recommendation would be to use two image fields instead — one for your carousel, and one for your RTE images. You can then configure your CKEditor field to use the field intended for content images via the "Images fields that may be used for dragged-in or pasted-in images" setting (found from the "Input" tab of the field). For an example on sites I work with there is almost always a field called "content_images". This field is used specifically for images embedded within CKEditor content.

Sorry to hijack the thread, but... would you believe that I literally just learned that you can do this with checkboxes? That makes things so much easier. I've always considered this part of the admin pretty cumbersome, having to click all those checkboxes one by one 😄 (Perhaps this view should include a note about this, unless this is something that everyone else already knows about?)

Same issue here, unable to log in using forum credentials (or any old information I can think of for that matter). This might need some attention from @ryan — or perhaps @Pete, as I seem to recall that it was him who originally set this part of the site up 🙂

As it happens, I'm about to hop in a project where invoicing is a key part; while I don't know if I'll be able to use your site profile directly, at the very least it'll be interesting to dig in for ideas. What we see here already looks awesome ? Would be nice if this was implemented in a way where one can easily swap the payment processor, kind of like what Antti did with PaymentModule (and PaymentStripe, PaymentPaypal, etc.)

Definitely sounds like a job for ProDrafts. Version Control keeps track of changes after they've occurred, but there's no (automatic) way to put them on hold and apply after some action/trigger. In theory one could restore the page to previous revision automatically and step "forward" again once changes are approved, but that would get very complicated very fast, and going back and forth could also result in "conflicts" where updates applied meanwhile would simply get discarded. Anyway, that's not something I would recommend doing ?

README lists three supported multilingual fieldtypes: Text (regular and multi-language) Textarea (regular and multi-language) Page Title (regular and multi-language) Technically other multilanguage fieldtypes should be supported as well, but these are the ones I've tested. Version Control has a config setting for enabling fieldtypes that are available on the site, but not listed as compatible by default.

Out of curiosity, which version of PW are you using? PW auto-corrects the rotation, and some issues related to this were fixed in version 3.0.197. Just wondering if updating to the latest stable version (3.0.200), for an example, would resolve this problem. My understanding is that PW doesn't remove EXIF data from uploaded image, just resized images — though I could be wrong here! One exception at least is that if you have configured a max image size for your image field, then it will be automatically resized after being uploaded, which means that PW no longer has any version of it with EXIF data in place. Anyway, I'm not sure which one you're talking about here: original uploaded image, or a PW generated size variation of it? If it's the latter, then currently there's no way to retain EXIF data, but the image should still be automatically rotated according to what was in said EXIF data. (There is an open issue about keeping EXIF data, at least in some cases, but no clear solution yet: https://github.com/processwire/processwire-issues/issues/1055.)