Leaderboard

I wanted to update this thread because I had to solve some unexpected problems when importing my content. Maybe documenting this will save someone else the struggle—even me, if my memory fails and I search the forum for answers to the same question. Firstly, my site requires multi-language URLs, and titles. This requires some deliberate configuration with the multi-language modules that must be taken care of BEFORE attempting to import data. This seems obvious in hindsight, but I assumed that these features were enabled by default once the core Multi-language module was active. One thing I noticed when attempting to import data was that the setLanguageValue() method would not work for the name field, even after enabling multi-language URLs. I had to do a lot of searching the forum before finding out that the language-specific name fields have a different way of assigning values via the API than what I could find in the Multi-language documentation. In the end, using the API to assign appropriate data to the fields in ProcessWire required two incantations that I failed to find in the Multi-language docs: In order to make the non-default language(s) "active", I had to use the page()->set() method to establish a hidden property "status$language". This property did not appear as unset when I buffer dumped the page() using TracyDebugger. Assigning the URL title (commonly called the "name" in ProcessWire) in the non-default language(s) required using the same set method to establish a "name$language" property. Here's a stripped down, abstracted example of my working import script, so far. <?php namespace ProcessWire; $en = languages()->get("default"); $es = languages()->get("es-es"); $articles = = database()->query(" // Magic SQL query here "); foreach ($articles as $article) { $parent = pages()->get('/' . IMPORT_SECTION); $template = templates()->get('my-article-template'); $newArticle = pages()->add($template, $parent); $newArticle->set("status$es", 1); $newArticle->title->setLanguageValue($en, $article['Title_en']); $newArticle->title->setLanguageValue($es, $article['Title_es']); $newArticle->name = sanitizer()->pageName($article['url_title_en']); $newArticle_name_es = sanitizer()->pageName($article['url_title_es']); $newArticle->set("name$es", $newArticle_name_es); $newArticle->body->setLanguageValue($en, $article['Body_en']); $newArticle->body->setLanguageValue($es, $article['Body_en']); // Etc., setting each field's value using setLanguageValue() method $newArticle->save(); } I have moved on to other aspects of the project, but I wanted to post this before I forget. It makes me wonder what else I'm missing out on, and how I might learn to do this better. Thank you!

M1 Mac Mini My first Mac. I love the hardware, but macOS is just not for me and it does some idiotic UX things that I can't stand, to the point where it's become a deal breaker. May go back to Windows and keep this as a second machine or just switch to Linux (Fedora KDE most likely); will probably stop using WSL2 and set up a dedicated Linux server for development (I don't like working with virtual machines). LAMP stack (installed and configured everything with Brew); everything ARM-based VSCode with various plugins ProcessWire with various modules (Profields being a must) + my super module (still developing it; lot's of breaking changes until the dust finally settles) I too set up a $config->env variable Laravel Mix for frontend asset management Hosting: DigitalOcean with Ubuntu Server (but considering Fedora Server in the future)

Sorry about that, I've pushed a fix for that issue. Thanks.

I use Sublime Text as my editor. I've tried others, but haven't found anything close to Sublime in terms of usability and performance. Most PW projects use the following modules: ProFields FormBuilder Wireframe ProcessCacheControl AdminTemplateColumns Any additional PHP dependencies are added via Composer. I use Laravel Mix to handle front-end compilation / bundling of SCSS and JS. It's a nice "wrapper" around Webpack that simplifies this process a lot. (View one of my webpack.mix.js files that runs PurgeCSS for production builds) All code in Git repositories hosted on GitHub, and use Sublime Merge as a Git GUI. Hosting-wise, most PW sites are on a Krystal reseller account or a client's hosting (if you use referral code 'CRAIG' we share £20 equally). For new sites, I do set up staging/development versions as a subdomain so it can be previewed. For deployment, I use DeployHQ (referral link / normal link) (also by Krystal) - which handles the transfer of changed files from Git over to the hosting via SSH - either manually or on Git push. It also does the front-end build step and Composer package installation as well so I don't have to do that myself. During development, I disable the template cache with this in a ready.php hook. // (I also set `$config->env = 'development';` elsewhere) if ($this->config->env === 'development') { $this->addHookBefore('Page::render', function($event) { $args = $event->arguments(1); $args['allowCache'] = false; $event->setArgument(1, $args); }); } I recently posted about how I do separate configs for different environments.

This week there have been various small core updates and fixes but the biggest change was to the installer in 3.0.191. Last week we removed all but the site-blank profile from the core, cutting in half the size of the core. And because of this, the installer now needed to provide more direction about downloading and installing other site profiles. So it now does that and it also links to a new page that describes all of the past and current site profiles, along with additional details on how to create and install site profiles. Speaking of creating site profiles, the Profile Exporter module was also updated this week. It is now PW 3.x exclusive and is updated to recognize and work with various aspects and $config properties that are specific to 3.x. ProcessWire 3.0.191+ and the Profile Exporter module now support a custom /site/install/finish.php file which is a template file that is called when installation of a new ProcessWire and site profile has finished, but before it has cleaned up the installer. It is a plain PHP file that has access to PW's API and the installer, so it can do pretty much anything you could do from a regular template file or module. I added this because I noticed a few issue reports for the Profile Exporter module were requesting support of one thing or another, and I found that nearly all of them could be added just by having a profile-specific finishing file, for those that want it. So if you want your site profile to perform any other types of customizations on top of what you can already do with a site profile, this is the place to do it. This is where things are at this week but perhaps we'll continue to go further with the installer in supporting more things too in the new year, as there have been several good ideas. Thanks for reading and I hope that you all have a Merry Christmas and/or Happy Holidays!

Talking about dinosaurs... (To be fair I'm mostly just a "late adopter". I don't mind trying out new stuff, but rarely jump to new tools until they've been battle tested first.) IDE: VSCode, with a bunch of handy extensions (PHP Intelephense, Tailwind CSS IntelliSense, SCSS IntelliSense, phpcs, EditorConfig for VS Code, Git Blame, GitLens, Remote, etc.) Emacs when it makes sense to work on the live server, or I just need to make a few quick changes for a local site — though Remote extension for VScode works really well over SSH, so been using that more lately ? Dev environment: VirtualBox or Docker, depending on the project. Some of my own old projects, mostly the ones that I rarely need to touch, I tinker with on the live server ? Staging... is not really a part of my usual process. Changes go from local dev environment to live server ?‍♂️ Syncing between environments: combination of (bash) shell scripts and rsync ? Hosting: AWS for client stuff, Contabo for personal projects. Currently considering switching away from Contabo. It's super cheap, but sluggish. Could be my own making, but I would happily spend a few more bucks a month if it helps. Modules: that's a long list, but development oriented ones are Tracy, Wireframe, and lately ProfilerPro. Other modules I use on pretty much all sites include AdminBar, MarkupMenu, SearchEngine, ProCache, ProFields (particularly Repeater Matrix), FormBuilder, SchedulePages, Redirects, Process Changelog, Process Login History, WireMailMailgun, PrivacyWire ... and a handful of others, many of which were built by @Robin S ? Front-end: Tailwind CSS + build process powered by Gulp. Vue for some JS work, but mostly just plain old JS/ES. With all the goodies baked into the language nowadays, jQuery is obsolete. (Literally have had one case where I wanted to use it in the past two or three years: needed to serialize form data.) What else? Composer for managing PHP libraries and ProcessWire modules, NPM for JS, Git for version control (surprise). Think that's just about it ?

Looks like you’re using @Wanze’s module Pages2Pdf. Unfortunately that module is pretty outdated and not compatible with PHP 8. I recommend switching to @bernhard’s RockPdf: $pdf = $modules->get('RockPdf'); $pdf->settings([ 'mode' => 'utf-8', 'format' => [210, 297], 'margin_top' => 20, 'margin_bottom' => 20, 'margin_left' => 20, 'margin_right' => 20, ]); $pdf->write("<h1>{$page->title}</h1>"); $pdf->write($page->body); $pdf->download($page->name . '.pdf'); It comes with handy output methods:

Hi Ryan, Big thanks for doing this, as it adds to beginners friendly and jump start with Processwire. Merry christmas to the Processwire Family

Some would and will call this... craftsmanship. I like it. Easy to maintain. Nothing that interferes without knowledge. I like the touch of open source and free software due to Codium.

Yet another functional setup without bells and whistles. IDE/Editor My "IDE" is a simple text-editor called neovim but due to a few plugins it has all I need. Yet I don't want to call it an IDE as it starts within half a second and runs from the terminal. My neovim has support for all kinds of LSPs, snippets, Git, code formatting, and whatever I really need. Tons of stuff. Tools Neovim - hyperextensible Vim-based text editor https://neovim.io/ As it says already it's a hyperextensible Vim-based text editor. I use it in a terminal and therefore it's pretty fast. Neovim has initialised a project already while VSCode starts. The absolute benefit for me is that I just need to download my configuration file(s) to a new setup, start neovim once or twice and everything is ready to go. No hassle. But the learning curve is ... weird. Tmux - tmux is a terminal multiplexer https://github.com/tmux/tmux/wiki Allows me to use just one terminal window to do 90% all the things I need to do through the day, while developing something with ProcessWire or frontend-related things. PrePros - Your Friendly Web Development Companion https://prepros.io/ In case I need a tool that does all the SCSS, Sass, less, JS things I prefer the easy way here. A benefit is that I can save the config file for each project right in the project, put it into Git and whenever needed I reinstall Prepros and go from there. Another hassle-free tool. ScreamingFrog - The industry leading website crawler for Windows, macOS and Ubuntu. https://www.screamingfrog.co.uk/seo-spider/ The easiest way to find issues on a website and while looking for errors it's stress-testing the hosting environment. In case you do SEO for a project you should give it a try. It's probably ProcessWire under the installable SEO-Tools. Missing NPM, Composer, yarn, npx and things like that? I'm too old for that. Whenever needed I download a module or use one of my site profiles right away. And for most other things Prepros does its job. Hosting/Server webgo - german hosting company. https://www.webgo.de/ Hosting Company of the Year in Germany since 2017 and probably the only hosting company I recommened to clients and even friends. But almost any other hosting company that has git and Let's encrypt support. I curate a list for myself to know where to go but webgo would be probably my choice. PW Modules FormBuilder ProCache ProFields (RepeaterMatrix, AutoLinks, VerifiedUrl) ProMailer AutocompleteModuleClassName Duplicator HannaCode ImportPagesCSV Jumplinks MenuBuilder PagefieldPairs PageHitCounter PricacyWire ProcessChangelog ProcessDatabaseBackups ProcessWireUpgrade RockHitCounter (PageHitCounter Addon by @bernhard) Snippets WireMailSmtp I guess these are most of the time self-explanatory. There are a lot more modules I have used, used to use and maybe will use some day. But all of these are in my default tool-belt when needed right now. Workflow I run Debian Linux on my main-machine where I do all my work and therefore have a local Apache2/MariaDB/PHP server setup running. Here starts absolute every project in its very own VirtualHost and Git repository. I prefer to use a similar setup like @horst and do the actual development on my local machine and then deliver it to a testing/stage/qa system where clients can take a look at the progress. The difference here is that my dev/testing/stage setups all run on my hosting accounts. I like to have a bit more control at this point. Everything gets transferred via Git. From local to testing/stage/qa and later on even the live environment. Changes will be made only on and within the local dev setup. So it's super easy to see whenever a client changes files or something was changed on the remote server. I guess that's all.

Just wanted to mention that this is a one-liner using RockMigrations: <?php $rm = $modules->get('RockMigrations'); $rm->setPagenameReplacements("de"); // or the even newer setDefaults: $rm->setDefaults([ 'pagenameReplacements' => 'de', // de is default // 1 is default and means consistant click behaviour on inputfields // see https://github.com/processwire/processwire/pull/169 'toggleBehavior' => 1, ]); I'm really not a fan of site profiles, so removing them from the installer is a welcome change for me ? IMHO if we put energy in that direction it would be a lot better to think about better automation than about adding more site profiles... This is already possible using RockMigrations (sorry, self-promotion again): <?php // site/ready.php // Demo "Site-Profile" using RockMigrations $rm = $modules->get('RockMigrations'); $rm->installModule('FieldtypeRepeater'); $rm->installModule('HannaCodeDialog', 'https://github.com/Toutouwai/HannaCodeDialog/archive/master.zip'); $rm->installModule('ImportPagesCSV', 'https://github.com/ryancramerdesign/ImportPagesCSV/zipball/master'); $rm->installModule('InputfieldPageAutocomplete'); $rm->installModule('LazyCron'); // you can also set module config easily $rm->installModule('TracyDebugger','https://github.com/adrianbj/TracyDebugger/archive/refs/heads/master.zip', [ 'guestForceDevelopmentLocal' => 1, 'forceEditorLinksToTracy' => 1, 'editor' => 'vscode://file/%file:%line', ]); // multilang: translate default language to german $rm->setTranslationsToLanguage("https://github.com/jmartsch/pw-lang-de/archive/refs/heads/main.zip"); $rm->addLanguage("en", "Englisch"); // add english as second language I'd love to see RockMigrations (or something similar) in the core one day. It makes developing modules so much easier, more fun and also faster. And of course it helps you in all your CI/CD workflows making your setup more professional, more robust and reusable! It can be used to automate anything you want. Just like shown in the "site-profile" example above. You'll not only have much more freedom about your setup, you'll also get the latest version of all your modules... PS: Maybe something similar could also be done using composer, but as soon as you want to set module settings and/or create fields/templates etc. composer is out ? PPS: My old project PW Kickstart from 2018 could also be used for some inspiration...

Some introduction... This module is experimental and there are probably bugs - so treat it as alpha and don't use it on production websites. I started on this module because there have been quite a few requests for "fake" or "invisible" parent functionality and I was curious about what is possible given that the idea sort of goes against the PW page structure philosophy. I'm not sure that I will use this module myself, just because I don't really see a long list of pages under Home (or anywhere else) as untidy or cluttered. I would tend to use Lister Pro when I want to see some set of pages as a self-contained group. But maybe others will find it useful. At the moment this module does not manipulate the breadcrumb menu in admin. So when you are editing or adding a virtual child the real location of the page is revealed in the breadcrumb menu. That's because I don't see the point in trying to comprehensively fool users about the real location of pages - I think it's better that they have some understanding of where the pages really are. But I'm open to feedback on this and it is possible to alter the breadcrumbs if there's a consensus that it would be better that way. Virtual Parents Allows pages in Page List to be grouped under a virtual parent. This module manipulates the page list and the flyout tree menu to make it appear that one or more pages are children of another page when in fact they are siblings of that page. Why would you do that instead of actually putting the child pages inside the parent? Mainly if you want to avoid adding the parent name as part of the URL. For example, suppose you have some pages that you want to be accessed at URLs directly off the site root: yourdomain.com/some-page/. But in the page list you want them to be appear under a parent for the sake of visual grouping or to declutter the page list under Home. Example of how the page structure actually is Example of how the page structure appears with Virtual Parents activated How it works This module identifies the virtual parents and virtual children by way of template. You define a single template as the virtual parent template and one or more templates as the virtual child templates. Anytime pages using the child template(s) are siblings of a page using the parent template, those child pages will appear as children of the virtual parent in the page list and tree menu. You will want to create dedicated templates for identifying virtual parents and virtual children and reserve them just for use with this module. Features Adjusts both page list and tree flyout menu to show the virtual parent/child structure, including the count of child pages. Works everywhere page list is used: Page List Select / Page List Select Multiple (and therefore CKEditor link dialog). Intercepts the "Add page" process in admin, so that when an attempt is made to add a child to a virtual parent, the child is added where it belongs (the next level up) and the template selection is limited to virtual child templates. Intercepts moving and sorting pages in the page list, to ensure only virtual children may be moved/sorted under the virtual parent. Superusers have a toggle switch at the bottom of the page list to easily disable/enable Virtual Parents in order to get a view of what the real page structure is. Usage Install the Virtual Parents module. In the module config, enter pairs of parent/child template names in the form virtual_parent_template=virtual_child_template. If needed you can specify multiple pipe-separated child templates: virtual_parent_template=child_template_1|child_template_2. One pair of template names per line. There is a checkbox in the module config to toggle Virtual Pages on and off, but it's more convenient to use this from the page list. Notes It's important to keep in mind the real location of the virtual child pages. This module is only concerned with adjusting the appearance of page list and tree menu for the sake of visual grouping and tidiness. In all other respects the virtual children are not children of the virtual parent at all. It's recommended to select an icon for the virtual parent template (Advanced tab) so virtual parents are marked out in the page list as being different from normal parent pages. Do not place real children under a virtual parent. There is some protection against this when moving pages in the page list, but when it comes to changing a page's parent via the Settings tab the only protection is common sense. https://github.com/Toutouwai/VirtualParents