Leaderboard

A little postscript to this thread... Though I'm loving ProcessWire, I don't love any of the core admin themes. I like restful colours that don't scream at you but I also don't like plain white with no differentiation between functional screen areas. I discovered AdminStyleRock and its customisation possibilities, and with about 30 minutes' work I now have a rather nice Nord Light admin theme as you can see. I've attached my admin.less file (I hope attaching a .less file works!) and anyone interested can follow the instructions at the top of the file. admin.less

Here's a site from someone new to ProcessWire. I've been developing with PHP and WordPress for donkeys years, but decided to try building a site with PW to see if it might be a better platform choice for the kind of sites and apps I build these days. Spoiler alert: it is. https://www.eltikon.online/ I'm not holding this site up as any kind of design example - it's a really, really basic hobby blog. What's more important to me is that I managed to build it from scratch in PW (previously it was a WordPress site) in about 20 hours, starting with zero PW experience, and my templates folder is really tidy with just a few small, well-structured PHP files. And that 20 hours includes sorting out the RSS feed, the XML sitemap, the SEO, etc etc. So my reason for posting is really to say that I found the PW architecture and methodology instantly comfortable and intuitive, and PW is going to be the first platform I consider for most future builds. It fits with my "hate visual builders, love coding" methodology, and I aim to get the ProFields Repeater Matrix module, since Advanced Custom Fields Pro's flexible content field has been at the core of all my WordPress sites for ages. Site details: I started with a clean install of PW 3.0.229 and the "site-simple-blog" site profile by tcnet, which I proceeded to completely rip apart and rebuild as part of the learning process. Non-core modules installed are SeoMaestro and ProcessPageViewStat, nothing else.

True, thx! I've just added it. I guess some others are missing as well... I guess I should go through my github repos and update my website 😅

Sure 😀. The key thing is that I am coming from Windows (but also that have tried so many Linux distros before). A one-liner that sets things up for me is great! It is beautiful right of the box, fast and installs the tools I need. Sure, I could have configured things myself but that means hours of research. I want the cake now and later, if I want, I can try and find out how the cake was made or change the recipe. In addition, the name (and by extension the company) behind it. It gives me confidence that he has done the research behind his configuration decisions for Omakub. Then there's the manual. It is concise and well-thought out. It has helped me discover tools I didn't know existed such as Xournal++ and a bunch of shell tools. Finally, if I am feeling adventurous, the whole thing is on GitHub 😀.

Hey @DrewPH. Welcome to ProcessWire and the forums. Thanks for sharing your exciting journey with us! 🙂.

Hey @FireWire please grab the latest version from the dev branch 😎😍 Note that you even have tabs for latte/php to show both the latte file and the compiled php file!! I got so used to these unhelpful error messages on a white screen that I didn't even think of looking into it. Thx a lot! This improves the dev experience a lot!

I mentioned a couple of weeks ago that I’ve got to do a lot of traveling in September and October, and so that means not a lot of core updates in the short term. Core activity may be a little quiet till the end of October. Sorry about that, I feel especially bad I’m not providing any good material for ProcessWire Weekly. But I’ll make up for it later, I promise! I’ve been reluctant to push any significant updates to the core because it is quite stable right now. So I’ll hold off on anything major till the traveling is done. I did just push one update to the dev branch that I think is a good addition though. I noticed recently that on a couple sites I work with, there was some markup cached with $cache that never seemed to expire. I tracked it down to an issue in WireCacheDatabase where some caches had ended up with invalid MySQL dates somehow or another. WireCacheDatabase now implements its own cache maintenance that ensures these never-expiring caches get deleted. In doing that, the cache maintenance process became more efficient as well, as it’s all handled with a single delete query, rather than multiple select and delete queries. If you’ve been noticing anything cached by $cache that doesn’t seem to be expiring when it should, it’s worth grabbing the current dev branch, or at least the updated /wire/core/WireCacheDatabase.php file from the current dev branch. One way you can tell if you have any caches that shouldn’t be sticking around are if you find any with dates prior to the year 1971, or any with a zero’d out date like 0000-00-00. Maybe there is still a bug to track down that is causing the occasional invalid dates, but at least now those caches won’t last more than 10 minutes. There likely won’t be an update here next week, as I’m anticipating no internet access, but there should be the week after next. Thanks for reading, have a great week and weekend!

Sometimes the best thing you can do for the project you work hard on is to get away from it for a while. When you come back, you'll notice a lot of new shining edges (or the ones to be polished) and almost definitely have lots of new shining ideas about it. So please do this little PW detox to keep it new and sparkling for yourself and all of us!

It's hard to say what is your problem because $user->givenname should work if the template "user" has a field givenname with a value. So the problem is not this code, it's elsewhere. You shouldn't need this, I didn't even know it exists and I added 27 fields on the "user" template in my current project. 🙂 Where does $user variable comes from in your code? Does the "user" template have all the properties? What var_dump($user) returns?

So silly. I placed the $featured_field inside the repeater. Solved

Thanks a lot. Very much appreciated.

Thank you for this module. Love it. A few weeks ago I accidentally found this gem although it was not listed on your website. IMO this is the slickest color picker in the PW ecosystem, if you only need predefined colors (which is mostly the case in my projects). Very easy to setup and the editors love it, too. This will be new standard in my tool belt for new projects.

Do you remember which ones you read about? I don’t know how well it scales, but this is something that makes it interesting to have a PW module (same way there is a WP one): it would allow users to have a simple and manageable instance with one (or potentially more) users, on a shared hosting. But I did read some issues about how Mastodon is agressively sending requests to websites when they are referenced in a toot, especially if said toot is shared on a big instance (read https://www.jwz.org/blog/2022/11/mastodon-stampede/), I don’t know though if this changed in the meantime. I read that as well. Apparently ActivityPub is quite “loosely” spec’d so there’s a lot of parts that can be interpreted differently. And since Mastodon is (one of) the biggest player, their way of doing became a de-facto standard (others had to implement the Mastodon-way to be able to interact with the bigger network).

Hi @Flashmaster82, v2.0.22 released which I hope finally addresses your issue. Please let me know how it goes (and remember, it's still alpha, so take backups at all key points, such as before installing new versions and before installing migrations).

@bernhard I've never been so excited to see errors in my code! Thank you!

@MarkE I know this is a late answer, but I think this is a great question and something that can feel daunting. Hopefully it's still helpful for you and possibly others. I originally wrote my translation module back in 2020 and when it came time to build upon it, add new features, and respond to feedback from the community that first version felt like a straightjacket in terms of structure. I rewrote it last year and have been able to iterate on it much more easily and confidently. This is really a decision based on how you view your project and what "feels good". When you get to writing modules as complex as the one you're describing, as always, the best way to reason about your approach is consistency and maintainability. This is more critical than trying to fit your code into someone else's structure. The most important way to think about organization is considering where you would first look to find a specific feature or behavior and if there are enough of these to warrant their own directory. My translation module probably isn't as complex as yours is, but it may not matter because we're both writing software applications that must be understood and maintained. Anyone can view the repo I shared above, but here are some notes about my reasoning. The purpose of this isn't meant to be a set of instructions or a roadmap, but more of a way to help you think about what is best for your application. [app] - This contains everything that supports what the module must do. If it has logic or supports logic, it goes here. [Caching] - Caching is a performance requirement and required abstraction and logic to tailor PW's caching feature for my use EngineLanguagesCache.php TranslationCache.php [Components] - Fieldsets used in one or more places where abstracting helped keep clean code in other files, like the main Module Traits - Shared behaviors used by Component files FluencyApiUsageTableFieldset.php FluencyStandaloneTranslatorFieldset.php [DataTransferObjects] - All DTOs that encapsulate data provided to and returned by methods in different classes Traits - Shared behaviors used by DTOs AllConfiguredLanguagesData.php ConfiguredLanguageData.php DEVDOC.md - A guide for me and others about how to use DTOs and their purpose as general data objects EngineApiUsageData.php .... [Engines] - Self contained "submodules" that interact with 3rd party services, both current and future. [DeepL] [GoogleCloudTranslation] [Traits] DEVDOC.md FluencyEngine.php FluencyEngineConfig.php FluencyEngineInfo.php [Functions] - General functions imported to support specific sub-behaviors that serve a specific purpose in more than one-two places fluencyEngineConfigNames.php typeChecking.php [Services] - Features that are added to Fluency that extend beyond the primary function of translating page content FluencyProcessWireFileTranslator.php FluencyErrors.php FluencyLocalization.php FluencyMarkup.php [assets] - Files that contain admin-facing UI files and compiled code, Gulp compiles and outputs to this directory [img] [scripts] [styles] [src] - Source JS and SASS that gets compiled and output to the assets directory [scripts] [scss] ...(editor/dotfiles) CHANGELOG.md - Semantic versioning is your friend, this is as important for you as it is for others Fluency.info.php Fluency.module.php FluencyConfig.php LICENSE README.md - This goes into high detail of all features because it also organizes my understanding of everything Fluency does ...(JS module configs and Composer file) I spent a lot of time on this decision. Probably overthought it, and since then there are things that I would do differently- however, how it exists now has been great to work with. My approach was entirely based on what this module does now, and what it may do in the future. The focal point and goals of this approach serve these purposes: - Fluency.info.php - Not required to separate, but helped keep the main module file cleaner and purpose-driven - Fluency.module.php - Aims to primarily contain methods needed to integrate with ProcessWire and any methods available via the global $fluency object - FluencyConfig.php - ProcessWire needs this to be configurable, but the amount of logic it contains certainly benefits from its own file Things I like having lived with it for over a year now. The directory structure is great and supports future expansion since it organizes by purpose. The specific way I structured my subfolders may not make sense for most others, but the message here is the logic behind the approach. Like I said, it seemed overengineered at the time, but now I know exactly where everything is and where everything should be in the future. This module has heavy UI integration and the way the JS files in src/ are broken down makes it clear what everything does. Because JS can import modules from other files, it really doesn't matter how many you have. The JS files for each Inputfield has on more than one occasion enabled me to add features or fixes that would have taken much longer without the granularity I put in place. Initially this module only supported DeepL for translation, but because of how Engines is structured as individual units, it was relatively easy to come back and add Google Cloud Translation because of how the individual units of behavior were organized and supported. What would I do differently having lived with it for over a year now? I would change the file names in app/ and remove the 'Fluency' prefix. That's why we have namespaces. Name collisions are handled by PHP so a simple file naming approach would have been best. This is something that I could change though without impacting the end user. FluencyErrors, FluencyMarkup, and FluencyLocalization might be better located in a 'Support' directory or something, but that would just be applying my approach to organization rather than needing to serve a hard purpose. It doesn't cause any confusion or problems as is. Probably some little things here or there, but not nagging enough to mention or even remember. Anyway. I chose a directory heavy structure with nesting which was a personal choice. There are a lot of great modules out there with different structures. A mark of good organization is asking the question "if I've never looked at this codebase before, would it be something I could get up to speed quickly and contribute without difficulty?". This may seem like a disconnected and impersonal approach, but inevitably you will feel like you need to relearn your own codebase in the future if you've spent enough time away from it. This is a great place to start. In a complex enough project, it may be worth considering separate modules that are installed as dependencies. This would let you group like-kind behavior where it may also be possible that some separate functionality could stand on its own. If you can organize things to separate concerns enough, it's trivial to access other installed modules from within modules using $this->wire('modules')->get('YourOtherModule'); and access all of its features and functionality. Since you can configure your module to have required dependencies, you can be sure that the modules you need will always be available. Organizing by purpose and features is really helpful. If the behavior doesn't provide anything useful as a standalone, then consider keeping it within the "wrapper" module. It depends on how portable you need individual behaviors to be separate from others. I'm not sure too much on the specifics of the implementation, but these are files that perform a specific type of work and would be candidates for their own directory. There's no rule for this, but it makes sense because it gives you a single place to look for these files. Long story short, trust yourself now and think about future you who will work on this later. You'll thank yourself for it. Hope this was relevant enough to be helpful even though it's a late-in-game response.

My too I'm happy Linux user. I actually tried many years ago to make my Hackintosh, but, luckily, didn't work and I moved from Mac to Linux and never regret it. The freedom you have is priceless. My distro of choice: https://www.bunsenlabs.org/ very clean and stable, based on Debian. As for Adobe, yes, still miss a proper app for Linux. I now use https://affinity.serif.com/ on a dual boot Windows machine. Affinity does pretty much what Adobe does, but it has a reasonable price. File manager: Thunar does the job, but if you want to have fun try Midnight Commander!

Hi; honestly, i would do this kind of thing in the template file wrapping the display of the link with a simple if user is logged... better SEO and UX than a 404 🙂 have a nice day

Something like this: $i = 1; foreach($page->my_repeater_field as $item) { echo "<div id='slider-layer-$i'>Layer $i</div>"; $i++; }

There are a few problems with that code: Switching $magazine to $page doesn't actually help at all. $page is not defined here either. As I mentioned in my previous post, you're in function context, and in that context you only have access to a) function arguments ($event), b) variables you've made accessible with "use" (currently there are none), and c) global functions. $page is none of those. Another issue is that there's no savedPageOrField method for Inputfield, so Inputfield(...)::savedPageOrField is never triggered — what you're looking for is Pages::savedPageOrField. From your post I assume that you've put this code in the template file, i.e. /site/templates/your_template_name.php? If so, the hook only applies to when you're viewing a page using that template, i.e. it has no effect in Admin. I'm not sure if that's what you really intended, but I'd assume not — more likely you'd want to put this hook somewhere it gets added in the admin as well, so perhaps /site/init.php or /site/ready.php. ... and, finally, even if your code did work, you would've likely ran into an infinite loop: if you hook into page save and save the page, that'll trigger the page save hook, which will then save the page and trigger the page save hook again, which... you know the drill. Pages::saveReady() is often better method to hook, as you can just modify the page values, and they'll get saved soon after (you don't have to call save in your hook) ? In this case something along these lines could work: // hook into Pages::saveReady $wire->addHookafter('Pages::saveReady', function($event) { // get current Page object — in this case this is the first argument for the $event object $page = $event->arguments[0]; // bail out early if current Page *doesn't* have the field we're interested in if (!$page->template->hasField('snipcart_item_image')) return; // ... and also bail out early if the snipcart_item_image field hasn't changed if (!$page->isChanged('snipcart_item_image')) return; // now that we know that snipcart_item_image has changed, set a custom value to another field $page->set('imagecolorat', 'YOUR_NEW_VALUE_HERE'); // finally, populate our modified $page object back to the event $event->arguments(0, $page); }); Note: written in browser and not properly tested.