Leaderboard

@wbmnfktr The ecosystem of available packages and services is definitely one of the major draws of Laravel. It almost parallels the Wordpress ecosystem, but ten times more professional. A lot of Laravel packages are very high quality, actively maintained, well tested, etc. That's probably a result of their somewhat "enterprisey" approach to structuring a project. Dependency injection, containers, service providers, those are all great approaches for professional projects, but they do require some commitment to learning these specific concepts. ProcessWire's approach to extension via hooking is almost the complete opposite of Laravel's container resolution approach. They're both flexible and ergonomic, but ProcessWire's a lot more approachable and easier to grok for newcomers I think. Being able to replace an internal handler in three lines without copy-pasting the whole class is really magical.

Here you go: alias ddc="limactl start && ddev config --php-version=8.3 --database=mariadb:10.6 --webserver-type=apache-fpm --timezone=Europe/Vienna --omit-containers=dba --web-environment='TRACY_LOCALROOTPATH=\$DDEV_APPROOT/' --upload-dirs='site/assets/files,foo/bar'" Note that you need to reload your shell after updating your alias file!

I’ve been very happy with Vultr over the past couple of years. I host several low-traffic PW sites (1.2M total requests/month) on one of their lowest-tier “high performance” machines for $6/month and they are quite reliable and extremely fast for this use. Though they suggest a 4GB machine for production, I find the 1GB is absolutely sufficient for ProcessWire. On the other hand, it’s important not to try to save the extra $1/month and go with the corresponding “regular performance” machine: performance does indeed take a fairly dramatic hit. I’ve found the Vultr servers to be much more responsive than Digital Ocean or Linode (or the venerable Pair Networks); I haven’t compared any others.

Hello guys. If you get a “Collation unknown” error, it's probably because your MySQL server version is earlier than 8.0.1, i.e. your dev/staging/prod servers are not the same (I suggest you harmonize and work on the same servers to avoid potential problems). You can consult the mysql documentation on collation migration: collations-migrating-from-older-collations If you'd like to go further in understanding the collation naming suffix, take a look at the table in the mysql documentation there. (I take a note about the installer file; You can give a read to my comment here too for notice type meanings).

I have had this in the past or at least very similar with a custom Debian-based Apache, MySQL setup I tried to run and manage myself. I don't know what I did wrong, but everything seemed a bit off. Since using DDEV, moved away from Laragon (Win) and MAMP (Mac), never had this issue anymore. The question to ask here is: Which system is off or needs a better config? Where is your live server from or who is your hosting company? If I had to guess... A2*, Dream*, or Blue*host - or something similar.

I'd support the "enterprisey" feel of Laravel and the whole ecosphere around it. Some of those big packages and starters aren't just a package with a README.md, they have full websites to explain what's happening - even those that are free (or not that expensive). I totally get that feeling, the vibe, the experience... yet it's way over everything I want to handle (aka my comfort zone). I did the 30-day-challenge to learn Laravel and I learned a lot. I learned to invest more time in ProcessWire as I am already familiar with it and could do way more with it, when investing more time to learn some new basics (modules, hooks, custom classes, and such). I love the simplicity of ProcessWire. From fields and templates, to selectors, to templating. You can learn all that in a weekend. While hooks and modules, custom forms, and more... may take a bit longer (weeks at least, for starters and non-PHP-Developers). Still... are there some things we could learn, should adopt, might take a look at from Laravel, or CraftCMS, or Symfony, or... I asked it myself, but I'm absolutely not the right person to ask those questions, so... here we are. ?

Don't tell anyone but 90% of my ProcessWire code consists only of if/else/foreach/echo statements - nothing more. You don't need more. That's all. My opinion. Ok, nowadays there is a bit more twig involved, and some hooks, and modules... yet not that necessary. Everything beyond that is some kind of voodoo-magic for me. On the other hand: this forum has almost all answers (for starters) already. If not, this community is the best and will help. So... We still have more options: exclusive (on Discord, in the newsletter, ...) short time only starter-price (+$50 every 100 sales) 30-day-money-back-guarantee

@flydev I am receiving a General error: 1273 Unknown collation: 'utf8mb4_0900_ai_ci' error when trying to migrate a PW site from a production/staging server back to local dev with MAMP on macOS. Is this a MySQL version error? And if so how do I fix ? also getting this message which I have never seen in Duplicator just before inputting database name user/pass and extracting Deprecated: strrpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in /Applications/MAMP/htdocs/production-pulldown/installer.php on line 709 - - - SOLUTION - - - I found a solution to my problem. I had to edit the .sql file within the duplicator-temp directory and do a search/replace all instances of utf8mb4_0900_ai_ci with utf8mb4_unicode_ci That seemed to have solved the issue. Never had that happen before. Must be an incompatibility with the duplicator package generated on the staging server and my local dev setup.

I don’t think that’s a bad thing per se, but I agree the big PHPStorm background could probably be replaced by just the slideshow of PW admin screenshots that currently plays awkwardly on top of it. Perhaps with one or two code screenshots intermixed. In general though, maybe I’m just old, but the site doesn’t look outdated to me at all? At least the frontpage looks as fresh as ever to me. Welcoming, professional, you name it. Certainly no worse than the examples mentioned? Wordpress has a trendy serif typeface which I get is part of their printing press shtick, but I honestly find kind of offputting for what it is (also the footer is grade A pure unadulturated organic cringe and all their images are blocked by Firefox’s default tracking protection). Structurally I think the ProcessWire site could use some improving, especially these “hub” pages like https://processwire.com/docs/, especially especially if they link to the next identical looking hub page (eg. https://processwire.com/docs/start/). Someone mentioned earlier that it’s a shame a lot of great nuggets and frankly vital info can practically only be found in blog posts. I know I’ve searched for specific blog entries I knew existed plenty of times, wondering how someone who hasn’t kept up with PW for over a decade would find out about stuff like custom user parents, for example. It would be great to have a more official tutorial section for these things which the blog posts would then link to. The current tutorial section only has 10 tuts, most of which, including the "More Tutorials" link, are secretly external.

From my perspective this is mostly spot-on @poljpocket. Yet there are a few things I'd like to add here: those of us that are active in the forum, read the weekly posts from Ryan, read weekly.pw from Teppo and follow every last bit... ProcessWire is evolving each day, each week, each month, all the time. YET... the last commit to master was 9-10 months ago, which is a century or two ago in the fast-living webdev-world - mostly due to the JS-sphere. I know a lot of people that look very close at this metric, but unfortunatelly on the wrong branch in this case. I'd love to see (and I personally keep it this way) the master branch as something like an LTS, while dev is more like a stable-rolling-release of some kind. I'd probably even use an unstable branch in some projects, even though there is no branch for it. BUT this isn't about naming, but MARKETING. And the last push on master is really bad marketing for ProcessWire right now. That's all I am saying. It doesn't look good. This needs to be changed. I don't care how, but it needs to be fixed. Fast! I don't care if we use SEMVER, ROMVER, WHATeVER, or any other way of versioning (besides the one from Ubuntu, which is really a bad look in the long run and introduces a lot of stress as there has to be a release no matter what at a specific date). All I need to know is if there are breaking changes or new requirements, like min. PHP 8.x and similar. I won't see (as in recognize) this in the version number and wouldn't even think about breaking changes the moment a ProcessWire 4.2 pops up in my upgrade module. Yeah, sorry... I just click UPGRADE as most of the users out there. Maybe the upgrading process/module needs a few upgrades, tricks, and markers to show and tell breaking changes, changed requirements, and what not. Sure more work for module developers but probably not really. Modules already have all these details like requirements. I'm not that deep into developing but as a user... that would be nice! One more thing... In this thread a lot of things were mentioned but mostly like "I'd like to have this feature and this, and that, and ..." which is fine. I'd support most of that. But I'd like to know and ask: Where do we want to see ProcessWire in 5-10 years? What can I do to support ProcessWire/Ryan more?

I took a look at StaticWire. It's truely a basic SSG, but IMO it's rather a local tool not intended for use in hosting environment. It's okay if You have some hundreds of pages, but what if there's 1000+ of them?.. Generating a lot of static files at once can take too much memory and time, so personally I opted for a lazy static pages generation. Here's my module doing exactly this: https://github.com/theoretic/StaticPages It's open source, and it's free.

@theoretic It's actually the opposite of that. ProcessWire is an API and that's all it is. Any output comes from the user of the API and not from ProcessWire, as it doesn't output anything on its own. ProcessWire started as a headless CMS, before the term even existed. The admin was later added on as an application built in PW, and then grew from there. But the base of PW is still just nothing but the API. ProcessWire itself doesn't output HTML. But since most use it for that, all of our example site profiles output HTML. There could just as easily be a site profile that outputs JSON or XML, or whatever you want it to. The point is PW has always been separate from whatever you choose to output with it, so that it has no opinion about what you use it for. While we could have a site profile that outputs something other than HTML, I don't really know what we would have it output or who it would be for, but maybe someone else does (?), it would be a simple matter.

Hi friends! And thanks for ProcessWire! Maybe I'm a bit late to the party, but I'd also like to bring some ideas here. Processwire is a great CMS having many brilliant ideas inside. But there's always some space for further improvements. JAMStack paradigm It's about static html pages which have some javascript-driven parts interacting with some APIs and changing their look and feel depending on what users do and which data API provides. Sometimes there's just a single static html page which behaves as a multipage web application, sometimes there are just small dynamic chunks. This approach has many advantages: There's no need to generate pages each time they are requested from server. They can be generated just once. Returning static pages drastically reduces the server loading. Static pages are safe by nature. There's nothing to hack there. And even if someone hacks into the server, there will be only some static html files there. APIs return pure data, no html at all. The most typical API data format is JSON which is pretty compact and human readable already, and there are others (bson etc.) which are even more compact. Processwire vs JAMStack The current ProcessWire is pretty far from JAMStack paradigm: By default, PW is about generating pages on each server request. And, being fair, lots of such pages could be static (generated only once). If someone will take a closer look to how the actual PW admin works, he/she will find that there are ajax-driven things there. But in these cases PW generally returns the chunks of html markup, not pure data. There's no native PW tools providing an easy way to build an API over PW. There are some 3rd part modules, and it's not a rocket science to build a PW-based API from scratch, but no native support out of the box. Processwire as "headless CMS" Headless CMS is a CMS which can only return data, not html. This approach is an important part of JAMStack approach, and there's plenty of such CMSs on the market. PW can be a perfect headless CMS, but it's not by default. You need to build an API on the top of PW to make it "headless". I did this in some of my projects, and I'm quite happy with the result. But, come on, give me a reason why this functionality doesn't deserve to be in the PW core? ) Processwire as "static site generator" (SSG) SSGs are another important part of JAMStack world. They are tools allowing You to make static html files based on the data and the templates You have. Contrary to headless CMSs, SSGs are generally the tools used locally, and the result (static pages) is later uploaded to server. It's quite interesting that PW can be a server-based SSG! I also did this, and I was quite satisfied again. But AFAIK there's no core-level or even 3rd party tools to do this using PW. Bringing the pieces together PW can make a big step from the ol' good paradigm of server-side page rendering to the modern JAMStack. Two things are missing: Native tools for building an API on top of PW. Again, it's doable, but it's not native. A PW-compatible (maybe even PW-based) SSG which won't be a headache. Both things are not rocket science, and they potentially could bring much more attention to PW, make it interesting for younger devels. I had a lot of talk like "ahhh You're that guy from 90ties, still writing php code and making server-rendered pages? You're the past already, man!". Hope this will worth a good discussion ?

This is super true. Gideon

Output logic is a part of the view. When I build a site profile to share with others my primary goal is to make it as simple and easy-to-follow as possible. For most websites powered by ProcessWire the template files are the views, and that's where I think most should start too, as it's very simple. As needs grow, many will naturally isolate the views to reusable files separate from the template files when it makes sense (like that parts directory in the invoice profile). But I think it's good for PW to be less opinionated about that because people may be using different template engines, different output strategies (direct, delayed, markup regions), etc., or they may not even care about following an MVC pattern, even if PW naturally leads there. This pattern was around before we had web sites/applications, so the "view" part is not like it was when we were building desktop applications in the old days with Borland C++. With HTML we've got server side markup and the additional layers of client side CSS and JS. Not everyone always agrees about where to draw the lines and it can depend on the case. I don't think we should decide that for people and I think it's good to be flexible on on this part of it.

As a default? Big NOPE from me. The super easy way and low barrier to enter the world of ProcessWire was one of the main reasons I gave it more than a quick look, did all the tutorials, read the docs, read the forum, ... and stayed. I tried a lot of CMSs back then and because ProcessWire had this "direct output"-way of achieving a lot without needing to know much about PHP or programming in general was the biggest PLUS ever. if/else/echo/foreach is almost everything you need to know to get up and running - and this quite far. Easier than anything. Easier than the Wordpress-loop, Silverstripe's way of doing things, or Drupal and Typo3. Such a delight and super fun to learn something new, a new CMS. Sorry for interrupting this great discussion.

I've been using ProcessWire for a long long time and over the years my techniques and go-to approaches have been constantly refined. A lot of this knowledge is codified in my internal heavily opinionated starter module that sets up everything up the way I like. Even with that, there are other tips, techniques, and modules that I may use occasionally on client sites and because of that, I may not remember them months or years later. I do have a document that I've been better at updating recently with this information, but in addition to that, I think to really remember a piece of knowledge it's best to actively use it even if not necessary. The best place I've found to do this is on my personal website. I treat my personal website as a semi-testing ground, a reminder of techniques and the generally the first place I will use something that maybe gets used on my other client websites. Even if I don't really need some specific module, need that odd hook, or require a specific setting, I will deliberately use it on my personal website because I have total control over it, it's live (meaning I have both a development and production version which allows me to test my deploy and sync scripts) and if something breaks temporarily it's not a big deal. For example, I'm doing the following on my personal site: various hooks that modify the admin; adding custom markup fields in the page editor for certain templates using dotenv (maybe eventually use this everywhere, but only here for now to codify the latest approach on this) using rockshell with some custom commands that I don't really need have a random snippet for tracydebugger in /site/templates/TracyDebugger/snippets/ created all the other special status files in /site/ (boot.php, download.php, failed.php, render.php) blocking the vendor folder in .htaccess have a random rewrite rule in .htaccess using ProcessRedirects with a random rewrite rule disabling sessions purposely have a dash in the name of my database (did you know Microsoft purposely put a space in the "Program Files" directory so that developers properly handle paths with spaces in it?) using Page Edit Lock Fields on my home and about page (yea, locking the page from myself!) experimenting with the AdminBar module and hooks, even though I won't use this module (I have my own admin bar that loads via ajax) overriding styles in the ProcessWire's admin bar (making the font small, smaller spacing, full width container) have a humans.txt file separately, using Matomo even though I don't really care about analytics for this site my deploy script deploys some extra random directories even though I don't need them have a separate user account that's been assigned the AdminThemeBootstrap theme I am working on using a honeypot field on my formbuilder-based contact form (I use this everywhere) I have a note (which is basically the above list) that I add to so it's easy to remember what I did, why and references to it (forum post, github, blog post, etc.). --- Separately, I have another completely blank ProcessWire installation with nothing extra done to it (except TracyDebugger). I use this to test and experiment various things (sometimes unrelated issues) when I don't want any hooks or installed modules potentially modifying anything. I'll also install modules here that I'm not so sure about. If I suspect I hit a bug with ProcessWire in a separate installation, I'll experiment here as well. Once I'm done fully experimenting and the issue has been resolved, I'll make a note in a log of what I did then undo my changes bringing it back to a clean slate.

I'm using uptime kuma for monitoring my websites and it looks like it can do what you want: Oh, and I'm using https://www.statuscake.com/ to monitor my monitor ? So as uptime kuma is self hosted and needs some time to setup you'd maybe better of with statuscake which offers 10 monitors for free. I just checked and you can use GET and POST

Hahaha- those are great. This is what I'm putting on the invoice line item. That's it. Also, new DJ name.

Here's a different site I was called in to fix. The design has been screwed up because it never quite looks right and the non-designer that edited the pages didn't click the buttons that change the editor size to "Mobile", "Tablet", and "Desktop" to make sure it would look correct across all devices. The semantic HTML was destroyed because, you know, the <h*> tags are to control the size of the text, right? It murdered SEO because tags aren't being used correctly. I love ads and update notifications that have existed there for weeks and also appear to be broken. I'm not doing anything about it because I'm not contracted for it and who knows what it will break. I do like the power that this design editor gives non-developers though, when things don't look right they can just tweak all of these numbers. I mean, who doesn't know and understand the CSS box model? Surely users can rattle off the differences between px, %, em, rem, and vw. Anyway. The amount of work it takes to make sure a page doesn't look like a trainwreck is, and I mean this, a valuable use of everyone's time- just stack the time I'm getting paid to fix it on top of that. I love WordPress, I make a lot of money off of it.

Not sure if this is documented anywhere, but you can use the RepeaterMatrixPage::matrix() to get the label: // get the label in the current language $page->my_repeater_matrix_field->first()->matrix('label'); In recent versions of RepeaterMatrix, you can also call RepeaterMatrixPage::getMatrixInfo() to get an array of information, including the label: $page->my_repeater_matrix_field->first()->getMatrixInfo();

Building on @BitPoet's code, here's an alternative way you could add labels to the select options: $wire->addHookBefore('ProcessPageEditLink::execute', function(HookEvent $event) { $input = $event->wire('input'); $page = $event->wire('pages')->get($input->get->id); // Do some check on $page to return early when not applicable $anchors = $input->get->anchors ?: []; $my_anchors = [ 'some_anchor' => 'Some anchor', 'other_anchor' => 'Other anchor', 'third_anchor' => 'Third anchor', ]; $anchors = array_merge($anchors, array_keys($my_anchors)); $input->get->anchors = $anchors; $event->wire()->addHookBefore('InputfieldSelect::render', function(HookEvent $event) use ($my_anchors) { $inputfield = $event->object; if($inputfield->name !== 'link_page_anchor') return; $options = $inputfield->options; $inputfield->options = []; foreach($options as $option) { $anchor_name = ltrim($option, '#'); if(isset($my_anchors[$anchor_name])) {; $inputfield->addOption($option, $my_anchors[$anchor_name]); } else { $inputfield->addOption($option); } } }); });

Not with the built-in anchor select. If you don't mind a bit of regex ugliness: wire()->addHookAfter("ProcessPageEditLink::execute", function(HookEvent $event) { $page = wire('pages')->get((int)wire('input')->get('id')); if(wire('input')->get('href')) { $currentValue = wire('sanitizer')->url(wire('input')->get('href'), array( 'stripQuotes' => false, 'allowIDN' => true, )); } else { $currentValue = ''; } $inp = wire('modules')->get('InputfieldSelect'); $inp->attr('id+name', 'select_anchor'); $inp->label = wire()->_('Select Repeater Anchor'); $inp->icon = 'anchor'; $inp->collapsed = $currentValue ? Inputfield::collapsedNo : Inputfield::collapsedYes; // Instead of addOptions here, fill your select however you want $inp->addOptions([ "" => "", "#some_anchor" => "some_anchor_text", "#other_anchor" => "other_anchor_text", "#third_anchor" => "third_anchor_text" ]); if($currentValue) $inp->attr('value', $currentValue); $wrap = new InputfieldWrapper(); $wrap->append($inp); // It's a bit ugly, but to get our InputfieldSelect to render correctly, we need // it rendered by an InputfieldWrapper. We do that, then strip out the wrapping // parts afterwards (i.e. everything before the first <li> and after the last </li>). $html = $wrap->render(); $html = preg_replace('~^.*?(?=<li\b)~is', '', $html); $html = preg_replace('~</li>.*?$~is', '', $html); $js = '<script> $("#select_anchor").bind("change", function(evt) { $("#link_page_url_input").val($(evt.target).val()).change(); }); </script> '; $html .= $js . "</li>"; $event->return = preg_replace("~(?=<li[^>]+id='wrap_link_page_file')~", $html, $event->return); });

Here's a Google Maps WordPress plugin that takes advantage of needing a Google Maps Platform API key. They redirect the user to this page to promote their $12/mo. paid plan even though Google will charge you $0. They're happy to charge you up to $109/mo. for 10,000 views even though Google's platform affords 26,000 under their monthly free credits. Stay classy.