Leaderboard

This week the new ProcessWire Invoices site profile has been released on GitHub here: Invoice Application Site Profile. This particular profile is much broader in scope than the others I've developed for ProcessWire, so will benefit from more descriptive information about what it includes, how to use it and modify it, and how you might build further from it. That info will all be coming next week in a new blog post. But feel free to download and install the site profile sooner if you'd like. If you are already familiar with ProcessWire, then perhaps most of it will be self explanatory. While this site profile doesn't cover everything that you might do with an invoicing application, it does cover everything that I've needed over the last year of using it with my clients. Though admittedly, I don't have a lot of clients, nor do I send a lot of invoices. Given that, when my existing invoicing service raised the monthly rate from $3/month to $20/month (a year or so ago), that's what motivated me to build this site profile. And it does everything my previous invoicing service did, and in fact does it better. While much of it was built several months ago, major improvements have been made to it over the last couple of weeks, preparing for it for release as a ProcessWire site profile. My hope is that you'll find this site profile easy to work with, and easy to build out further where needed. For instance, I imagine some may want to add in the ability to pay an invoice. It would be relatively simple to add in FormBuilder with its Stripe Processor plugin, or perhaps some other payment solution. But all my clients pay by check, whether physically or digitally, so I've not needed to add payment ability to the application yet. In any case, I hope that you find this site profile useful, and please let me know if you run into any issues with it or have suggestions for future upgrades to it. Thanks for reading and have a great weekend!

@teppo Not very straightforward, but here's a function that would tell you whether or not a translation exists for the given phrase in the given file, in the current language. Maybe we need a dedicated core function for it? function isTranslated($text, $textdomain) { $translator = wire()->user->language->translator(); $translations = $translator->getTranslations($textdomain); $hash = $translator->getTextHash($text); return isset($translations[$hash]) ? $translations[$hash]['text'] : false; } Example $text1 = 'About Us'; $text2 = isTranslated($text1, '/site/templates/about-us.php'); if($text2 === false) { echo "Not translated: '$text1'"; } else { echo "Translation of '$text1' is '$text2'"; }

Just this week had to deal with the same thing on a site with 100+ translatable strings, many views reusing same translations, and three languages. Ended up splitting translations into a (static utility) class that has a string() method that returns the translation. So basically the same thing that Ryan has done here. Biggest difference is that since many of those strings in my case also exist in the admin as field labels, I added a fallback that first checks if a translation for current language exists, and then falls back to the field label if possible. I guess this confirms that I'm not doing anything too silly ? ... but on a loosely related note, if anyone has a good idea how to check if a string has been translated, I'd be happy to hear. I'm currently just comparing the source value to the return value and if it has not been changed I'll assume that a translation wasn't found. That's obviously a bit crude. Would be nice to have some way to check if the returned value from the translation method in core is indeed a translated version ?

Thanks for releasing this Ryan. Although I've been using ProcessWire daily for over a decade at this point, it's nice to compare my version of "The ProcessWire Way" with that of the creator himself and learn any tips and tricks along the way. This is probably going to be very helpful for beginners. When I was researching Tailwind a while ago, the creator (Adam Wathan) spoke about how he made many demo videos of himself replicating websites with his CSS framework so developers could get an idea of how the creator of the tool himself would approach using it. I feel like these site profiles provide a similar and more realistic learning experience in addition to ProcessWire's great documentation.

Hi everyone! I built this module trying to solve the following issue. Most of the time I use Repeater Matrix types with a few fields wrapped in a fieldset that are for configuring the behaviour/rendering of a specific repeater type, and are not really content related so I had always wanted to have them kind of hidden, but with a small preview of that the options are set (which I've yet to do). https://github.com/elabx/FieldtypeFieldsetPanel

Dear ProcessWire community, Over the last years I created many small–medium websites for classic musicians among other things. I have grown to a point where I cannot support all projects in a timely manner, so I look for some support on code level. (Some websites are oldschool PHP templates, some are headless with a Svelte or Next.js frontend.) Tasks may involved Implementing new screens and features (designs provided by me) Refactoring oldish static fields to more flexible repeater layout Maintenance (Updating ProcessWire, PHP Versions) Requirements Experience with ProcessWire, HTML, Vanilla JS, jQuery, CSS, Sass, node.js build tools, Git, SFTP Ability to estimate tasks, plan and deliver on time Billed by the hour based on estimates Nice to have, but not required Experience with custom ProcessWire Modules, Docker, Svelte, React, Next.js, Typescript, THREE.js, R3F, GDPR complience Eye for design details Germany based / German speaking Please send me a DM if you are interested so we can discuss details.

Hi, I've created a very simple module, that displays the number of (PagesVersions) versions a page has in the Page List: https://github.com/eelke/ProcessPageListVersionsCounter I expect something like to become part of the PW core as the PagesVersions implementation matures, but in the meantime it could be useful to others. So I'm posting it here.

Looking forward to it! And good luck ?

Thanks, Ryan; I see your point. I don't necessarily agree with all of it (apart from the front-end facing modules part, that I fully agree with), but I appreciate you taking the time to explain your view! Also, I'm clearly in the minority here with my opinions ? One last point, though: When I hear someone describe vanilla JS as not fun or inconsistent, I do wonder if they might be, perhaps, remembering JS as it was a long time ago. Modern JS is at least as far apart from JS of 2006 (when jQuery was released) as PHP 8 is from PHP 4 (also from 2006). After being a heavy jQuery user for years I've been getting more into vanilla JS these past few years, and I must say that my impression of it has changed a lot. Anyway, just saying that if you've been on the jQuery side of things for a long time, giving vanilla JS a try may be a positive surprise. Of course if you're super into the jQuery syntax any difference may be a dealbreaker — and that's fine too ?

Makes sense to update to jQuery 4 once it's available and stable, but I must admit that when I read that article my first thought was "holy crap, they are still going on?" ? Serious question to @ryan: what's your take on jQuery these days, do you still see it as something we will be, or should be, relying going forward? I'm not trying to push any agenda here, but I am wondering if you'd be open to perhaps starting to migrate more of ProcessWire's core code to vanilla JavaScript. I'm also not going to go into the "but what about Vue / React / Alpine / HTMX / insert-name-of-any-other-library-or-framework-here" topic at this point; that's a whole different subject. Also: all modern libraries are advocating the use of native JavaScript API's instead of "framework specific magic" anyway, so vanilla JS would be a good first step towards something new. In my opinion (which I've probably voiced here on the forums a few times already) jQuery is now largely obsolete. And I'm saying this as a former fan — it was amazing back in the days when native JS API's were very crude and lacking. Today it's more of a problem. For those that don't know what I'm speaking about, one example is the way jQuery handles events: the API is nice, but also hacky and non-standard, leading to the fact that in order to combine (standard) JS events with jQuery events you essentially need yet another library. (And vendor lock-in, intentional or not, is not a good thing.) Personally I find myself reaching for jQuery in pretty much one specific case: many third party plugins/libraries still rely on jQuery. This is less of an issue every year as devs keep moving forward, but there are still many popular plugins that do require jQuery. For every need there is a non-jQuery solution, but it can take a bit of work to find / migrate to. Some things are admittedly more difficult to replace, and one of those is jQuery UI. But since jQuery UI is already in "maintenace updates only" mode, replacing it is likely something that has to be done at some point. (Also... form serialization. That is something they did really well. And no, vanilla JS FormData is not a direct replacement ?) Sorry for the long rant, but I just felt that this needed a bit of context. I for one would be happy to submit PR's etc. that would move us towards fewer dependencies for jQuery if that's something that'd be beneficial for the project. I believe it would be, but that's just me ?

@BoostGuess stability, security and privacy data protection. I don‘t like my IP send to CDN servers and for some of my customers this would be a no go at all.

This is so great!! Thx @ryan and @Jonathan Lahijani and @thetuningspoon for suggesting this. I've just implemented first class support for this in RockMigrations and it comes in really handy for the development of RockCommerce. There I have a repeater where clients can add Accessories for every Product. Instead of being RepeaterPages they are now \RockCommerce\Accessory objects which is a lot nicer and makes the code a lot cleaner and I can get rid of many hooks and now my IDE actually understands my code ? For everybody using RockMigrations all you have to do to make that work is to place your file in /site/modules/YourModule/repeaterPageClasses/Accessory.php and add the field constant to that class so that RockMigrations knows which field to apply the pageclass to: <?php namespace RockCommerce; use ProcessWire\RepeaterPage; class Accessory extends RepeaterPage { const field = "rc_product_accessories"; } While working on this I have also improved autoloading of custom page classes and autoloading of regular PHP classes or traits: MyModule/classLoader will auto-load regular PHP classes or traits MyModule/pageClasses will auto-load PW custom pageclasses MyModule/repeaterPageClasses will auto-load PW custom repeater classes (and trigger init() and ready() for them) Extensive docs are already on the dev branch (https://github.com/baumrock/RockMigrations/tree/dev/docs/classloader) and will be merged to main begin of next month ? This is also the case when using $pages->newPage(...) - not sure if that's intentional @ryan ?