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!

The invoices application site profile that I uploaded last week now has a companion blog post: https://processwire.com/blog/posts/invoices-site-profile/ Thanks for reading and have a great weekend!

What I really love about AdminStyleRock is that you simply set one color and the PW backend immediately looks like it was built only for this client: But I'm not a Designer, so I just kept it very much like the default uikit theme. What I don't like is that several parts, especially the important page edit screen and all the inputfields have very low contrast and as I'm using dark mode now I think all the white is quite heavy on the eyes. What I don't like on the reno theme though is that it has totally unique and opinionated colors that never ever fit any of my client's CI. It's really easy to adjust everything of the style using simple css/less, but unfortunately several years passed by and nobody did improve this foundation. I wonder if some designers are still afraid of messing around with the css/less, so I want to ask if we have any designers here that want to work in improving the style in collaboration with me? We can do video calls or I can try to work from figma designs. Maybe we could even think of adding a light/dark mode toggle as we are working on it. Another thing that is not ideal is that it seems to be impossible to find all existing admin styles in the modules directory at the moment? Using the search I found these: In terms of design I think @Noel Boss AdminThemeBoss is very nice, but I don't like that it's an AdminTheme and not just a Style. And I'm not sure if he is still active in the PW world? If anybody has opinions to share or ideas on how to improve the situation please go ahead!

Thank you very much, Bernhard. This DefaultPage class will be very handy for a lot of stuff !

You can either use hooks: <?php $wire->addHookMethod("Page::thumbnail", function(HookEvent $event) { $event->return = ...; }); Or even better you use custom page classes (it's really easy thx to pw!) and there you create a DefaultPage class that adds your method: <?php namespace ProcessWire; class DefaultPage extends Page { public function thumbnail() { return ...; } } Then you just make sure that thumbnail() always returns a PageImage object and then in all your templates you can do this: echo $page->thumbnail()->size(100,100)->webp->url; And it will automatically render either the custom or the fallback image. Check out https://processwire.com/blog/posts/pw-3.0.152/#new-ability-to-specify-custom-page-classes for details

I'd like to introduce you to my newest employee: Devin

Nice, for a beginner it's a nice way to quickly discover PW mechanics. And probably an experimented user can also find some interesting features he doesn't already know (I already see some of them). ?

So, today I learned that you can use a config-dev.php file which takes precedence over the normal config.php file if it's present. ... unfortunately I discovered this by accidentally uploading a config-dev file to a live site. I'd got two config files for live and staging in my project folder and just renamed them when I wanted to update a setting - I'd coincidently named the file for the staging details as config-dev.php and accidently uploaded it to production. Luckily this just meant that the content from the staging site got displayed which wasn't too out of date so hopefully no one noticed.... Now I look into it, I can see that's it been around for ever and there's been lots of chat about it, but hey, I didn't know about it, so thought I'd stick it in this thread just in case anyone else was a daft as me.

@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'"; }

In regards to dev vs live htaccess, you can also use htaccess's "if" conditional for blocks of code you want to selectively enable/disable depending on the site being loaded. By doing so, you don't need two separate htaccess files to maintain. When using ProCache combined with it's htaccess recommendations at the top, I wrap it inside a conditional like this: ################################################################################################# # ProcessWire ProCache recommended .htaccess tweaks for expires and gzip performance settings. # PWPC-3.0 Keep this line here for ProCache identification purposes. ################################################################################################# <If "%{HTTP_HOST} == 'my-live-website.com'"> ...the code here... </If>