Leaderboard

Padloper 2 is Here

Happy New Year! Hope that you all have a great end to 2021 and start of 2022. No major core updates to report this week, just a few minor issue fixing commits, so no version bump today. The dev branch is getting close to 100 commits (and at 7 versions) above the master branch, and with even more improvements/fixes/optimizations than that. So we may try to get a new master/main version out in early 2022, as I'd really like to get more master versions out in 2022 than we did in 2021. Some portion of our audience does not use the dev branch where most of the activity happens, and so it might be nice to share more of that activity on the master/main branch. That's one of many things I'm thinking about as the New Year approaches and am certain 2022 is going to be a great year for ProcessWire and the community. Hope that you have a great weekend and Happy New Year!

Padloper 2 documentation can be found here. This is WIP but has the very least to get your started. It is a bit rough around the edges. We'll improve it as we go along. At the very least, I suggest you read these sections: Getting Started API, especially the finder, cart & checkout and session order chapters. Frontend. With respect to the API, the most important thing to know about is the $padloper global variable. It is your gateway to nearly everything (finding things, carts, checkouts, orders, etc.) in Padloper (2). Please do let me know if you find any errors. I am also working on the starter (demo) site repo. This and the docs should hopefully help move you along. If I get a minute, I might throw in a quick demo video. No promises though ?. Happy reading ?.

Depends on what you guys dig up when you put it through its paces in the next few weeks ?.

Real programmers use butterflies To everyone using git for automated deployments: How are you handling field/schema changes in between environments? And what about module updates/new modules, module configuration, custom module data (like Hanna Code shortcodes)? And everything else that's in the database but affects the CMS, like selecting a specific page as allowed parent in a Page Reference field? A database dump is of course an option, but once a site is live you can't just import the dump in production since it will overwrite the live contents. Are you writing migrations using one of the migration modules by hand? For every single field, field setting etc? Assuming you're able to handle all the edge cases (mentioned above and otherwise) with custom migration code, isn't that hugely time-consuming? Particularly when it comes to creating complicated field setups like Repeater Matrix fields with multiple types, where some settings are stored separately from the field settings and not all properties are documented or type-hinted … Something else? Anyone got a setup that allows them to use git and deploy from dev to staging/production without manual steps? If so, how are you handling the above issues?

Over the years, I've experimented with using RepeaterMatrix as the basis of a rich page builder. I've gone through at least a dozen concepts, most of which hit the chopping block due to either being too complex, not well thought out, too clever or too limiting. To my knowledge, the only other CMS that takes the "Builder" approach that I've demonstrated is DjangoCMS (meaning, it has a matrix-like field with depth support). While the "Builder" approach works well, it could be too advanced for some people. Therefore the other approach is the "Classic" approach where you don't deal with containers/rows/columns (which instead is handled by template code), and simply enter the content in the respective field. This is easy to understand, but has drawbacks in terms of flexibility. If it were made to be too flexible, it would become a "God" block which is bad. Then I finally thought of a third approach which is a mix between the Builder and Classic approach. It uses the basic builder blocks, combined with the layout from the matrix item template file. By using the basic builder blocks, you get the plethora of options. It requires an extra page to be created behind the scenes however, but live preview still works. I made a video comparing all the above (10m duration). I want to hear your feedback on this as I am ~75% done with my super module (doing a lot of code and concept cleaning at this point) and want to finish off this portion of it. (note: I'm posting this in the Dev Talk forum since this is a discussion / not support request)

What you've done with the first example looks super powerful. Nice work. The second approach is what we use. It's always a battle between giving the client more control vs. making it easier for them to manage (and making sure they don't mess up the site's aesthetic!). So we tend to give them more clearly defined components and then add options to them as they need them, or build out new components if they want something totally new. With the example of the text w/ image block, you could create a single block but add a radio button for which side the image goes on.

Whatever Alex is drinking, get me double ?.

Probably my method is in the dinosaur category, but it still works without spending too much time on migrating a database: If I do not mix up production with local then it is fool proof. It takes less than 15 secs from start to finish to clone a small database including all the keystrokes I have to perform at the beginning. Sure, it is the other way round regarding migrating, but for a one man show it is not a big deal. When modifying settings in production, I sometimes have to do the cloning more than once but since the whole process is so fast, for me it is a non-issue. "I am still waiting" for an official automated migrating solution included in the ProcessWire core :P

ATM I simply use the manual export <> import function from PW for fields and template settings. Every time I also have to alter field and or template settings, I write down the timestamp on a pad of paper when I start to do so and then collect a list (on the left side) of all fields I touches in the next time until deployment, (and on the right side I collect all template names).* When I'm ready for deploying, I may or may not shut down the live system for a short amount of time, depending on the amount of changes, then collect from the DEVs export selector all needed fields, copy the export json and drop it into the targets fields import field and proceed. Next step is the same with template changes. There is no need to shutdown a live site for long time. Mostly when I had large deployments, it was closed for one hour, but most of the time I do and have done those db migrations without any maintenance mode, because most of my sites uses ProCache. If it really would matter, I can prime the cache by crawling the site once before starting to deploy. It is not comfortable and also not the best I can think of, but it's not nearly as uncomfortable as described by @bernhard? Using these functions is not nearly as error prone as manually writing EVERYTHING into one schema or another for every field and template change. Noting everything by hand is not error tolerant for typos, I might forget to note a value, a change to a template, etc. All this is avoided by simply copy-&-paste ready generated JSON directly from PW. No typos, nothing forgotten, nothing added. Not perfect but for me much faster, easier and safer than writing everything down again by hand. PS: * In case you are not sure if you have written everything down on paper, you can generously include additional fields or templates in the export. In this case, it is better to have more (or even all) than too few. All unchanged settings will be recognized by PW during import and will not be processed further. ?

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!

Docs are up: Thanks.

What ever lived before dinosaurs, I'm one of those ? I use Nova as Code Editor which has a FTP-client builtin. Most of the time I'm working on the live-server. ProCache takes care of my scss-files Modules: PrivacyWire, Jumplinks, ProtectedMode, lot of the ProModules, … ProfileSiteExporter for moving Sites I also do not offer hosting Even with a limited setup as mine, there is a lot possible with ProcessWire. What a great CMS and community. btw: Happy new year to you all!

Demo site (frontend) is here. I'll do a write-up about it soon. The cart is htmx, Tailwind and alpine.js powered. Borrowed bits of templates here and there, threw in some Tailwind CSS components and this is what we get. Oh, yes, all the blemishes are mine. Site is not optimised but it is fast enough. It should give better feedback after item is added to cart. Will work on it later. Full checkout works. The PayPal widget will not charge you though. It will just crash (with a lot of grumbling in the console). Over the weekend I'll set up a GitHub repo with this demo as a starter site for our testers (especially). I also plan to wrap up the docs and prepare access for testers ready to download by Monday. I'll send you (testers) an email in this respect. After (or even before) that I'll write up a bit about what to expect in this first release and what not to expect. Happy new year.

I always watch carefully your videos. You've put so much thought into it, it really shows how you've found the advantages and drawbacks of each solution. I also started experimenting with the first option where you basically need to set up the container, rows and columns first before working on your content. Template-wise, I figured that tracking depth could get complicated quickly, and I abandoned the idea, but it sure looks like the most flexible, less "hacky" way compared the new, third option you're proposing. Sure, it requires thinking about design first before inputting your content, and I'm not sure I would offer that option to most of my clients as it requires some learning and a designer/developer frame of mind ("what's the deal about those rows and container anyway?" is what I'd imagine they'd say), but if I'm the sole editor, I'll love to have that option! The classic option is of course always a good, although obviously more limited option, that is intuitive and supported out of the box without some clever hack and double modals such as the new, hybrid approach. I can't shake the feeling that the third option is going to be brittle and need an ever-growing set of workarounds for all the use cases out there. Personally, I've gone a different route. That's probably going to sound half-baked to you, but it might be of interest to some. Instead of trying to cram all the blocks on the same page, I'm using subpages as containers for those blocks. In other words, from the parent page, I loop through all the children to build my page out of this series of containers / sections. So each child page is basically a section of the parent page, where I only need to apply columns, then place my blocks inside. If I need to change the order of those sections, it's just a drag and drop away: I simply move the child page up or down below the parent page. I've not fully explored the possibility, and I'm still experimenting with this on a couple of sites, but I've found it flexible enough for most of my uses, and easy to code. On each child page, first there's a combo (pro) field that holds the basic design settings for the current section, such as margin, padding, background color, width, etc. Then I set up my columns with a simple text field that holds predefined tags for responsive widths and optionally offsets and additional classes, and inside my blocks. Here's a screenshot (in Spanish, sorry) of something very similar to what you've shown in your video: a text on the left, and image on the right.

Just wanted to share the new approach we've started using for our configs. Instead of multiple config files, we are using a single shared /site/config.php plus a custom /site/config-env.php file that is unique for every environment the site is deployed (or developed) in. The config-env.php file simply contains one $env variable with a string that defines which environment we're working in (e.g. "production" "staging" "dev") and we include this file within the usual /site/config.php file. The config-env.php file is excluded from git (gitignore) and from our deployment scripts, so it won't be overwritten or touched after it's set up. Using a file to determine the environment rather than the domain or server variables means that it will work regardless of where or how it's invoked (cli vs browser). Here's the basic format: Example /site/config-env.php <?php $env = 'production'; // A string identifying the current environment Example /site/config.php <?php if(!defined("PROCESSWIRE")) die(); setlocale(LC_ALL,'en_US.UTF-8'); ini_set('session.gc_probability', 1); ini_set("log_errors_max_len",0); /*** SITE CONFIG *************************************************************************/ /** * Set up all your defaults and settings that are shared by all environements below */ $config->debug = false; $config->adminEmail = 'example@example.com'; $config->advanced = true; $config->templateCompile = false; $config->uploadTmpDir = dirname(__FILE__) . '/assets/uploads/'; $config->chmodDir = '0775'; $config->chmodFile = '0664'; $config->timezone = 'America/New_York'; $config->defaultAdminTheme = 'AdminThemeUikit'; $config->installed = 1527694349; /** * Environment-specific configs */ if(!file_exists(__DIR__ . '/config-env.php')) { echo 'No /site/config-env.php file could be located. Please create a /site/config-env.php file with a single $env variable containing a string identifying the current environment. This file should NOT be committed to Git (add it to the /.gitignore file) and must be excluded from deployment.'; exit; } require(__DIR__ . '/config-env.php'); if(!isset($env)) { echo 'No $env variable found in /site/config-env.php'; exit; } switch($env) { /** * Production */ case 'production': $config->dbHost = '...'; $config->dbName = '...'; $config->dbUser = '...'; $config->dbPass = '...'; $config->dbPort = '3306'; $config->dbEngine = 'InnoDB'; $config->httpHosts = array('...'); break; /** * Staging */ case 'staging': $config->dbHost = '...'; $config->dbName = '...'; $config->dbUser = '...'; $config->dbPass = '...'; $config->dbPort = '3306'; $config->dbEngine = 'InnoDB'; $config->httpHosts = array('...'); break; /** * Developer One's Dev environment */ case 'dev1': $config->debug = true; $config->dbHost = '...'; $config->dbName = '...'; $config->dbUser = '...'; $config->dbPass = '...'; $config->dbPort = '3306'; $config->dbEngine = 'InnoDB'; $config->httpHosts = array('...'); break; /** * Developer Two's Dev environment */ case 'dev2': $config->debug = true; $config->dbHost = '...'; $config->dbName = '...'; $config->dbUser = '...'; $config->dbPass = '...'; $config->dbPort = '3306'; $config->dbEngine = 'InnoDB'; $config->httpHosts = array('...'); break; default: echo "No configuration found in /site/config.php for the environment string \"$env\""; exit; } If you wanted, you could make the $env variable $config->env instead, which would allow you to access it from anywhere else on the site using wire('config')->env

Hey @Moritz! I use RockMigrations to handle most of the API related stuff along the initial Migrations module, which has a CLI interface letting me run pending migrations per site and keeps the track of it. The sites all share the same features and templates, nothing can be added as a "site specific feature" that involves a "custom pw stuff" in the database, it religiously needs to be in sync. I use bitbucket pipelines for deployments, and it's a very simple script involving rsync and running the Migrations CLI. I do write everything that involves a "new feature" regarding fields on a page, repeater matrix, etc. I'd say once you got it figured out, most of the time i'm copy pasting between migrations and adapting. I'd love to get in sync with some sort of automated testing (end to end with cypress?), but right now it just involves manually testing, and deploying to a few sites to test, fix otherwise and deploy again. I guess this is more of a management issue?? Maybe I am not understanding your full perspective here. No db dumps becase as you mention, it will mess up content. HannahCodes I migrate using the text version export of the hannahcode haha Module updates I guess just upgrading the files?? Haven't got into a deeper issue where something breaks while doing these. I think, up to know, I have just installed new modules. I keep processwire install outside of this equation, I am not sure if this was a wise decision, but it is like that lol One thing that is super important that I haven't though very well is rollbacks. Right now I basically would just run another migration on top, chekout/cherrypick from earlier branch or sth. Though haven't had enough time on this setup to mess up like this and need a rollback or where just doing a migration on top wouldn't work.

+1 ??

Some people have been telling me the opposite. They just want it now ?. Some of the features are pretty straight forward, for instance, editing a category or tag page. They are ProcessWire pages being edited in the usual page edit form. Given that this is alpha/early beta software it is not catastrophic if the documentation is lagging behind. I'll leave it up to the individual for now ?.

There must be something on my local machine, I uploaded it to the dev server and it works straight away. I configured it and got busy translating. Thanks for the help and for the great module! I tested DeepL's translation quality with my native language and it blew my mind. Multilingual sites are now really a breeze to create.

Is it a good idea to wait for the documentation to be completed before us testing it?

@kongondo Gold baby! Digging for gold ?

yessssssy! EXCITING

Awesome!

I'm getting excited! When will Padloper 2 be released "officially"?

I know what you are looking for. Unfortunately, there isn't any. However, there is another alternative search that might help. For example: site:processwire.com/talk your-query-here You can substitute "blog" for "talk" (talk == this forum) and get a listing of articles covering your specific query, which is the closest thing to the type of documentation you are accustomed to. I see by your post count you have been here a while, so you know how helpful all the members are when you have a question. That is one of the best things about ProcessWire; This community.

Hello @Jan Romero, thank you so much. This gives me a lot of new stuff to work with and try tomorrow morning. ? Happy New Year! Edit: I kept getting similar errors with your suggestions, but after trying a lot of variations with your input, this seems to work: $field = $page->getField('comments'); $comment = $field->getFieldtype()->getCommentById($page, $field, '26'); if ($comment !== NULL) { $field->deleteComment($page, $comment); } Still not entirely sure what getFieldtype() does, but that is apparently essential. Thank you! Now putting together the complete comment delete button solution, will post in next comment below...

You can use the query feature of Tracy (ProcessWire Info Panel) to search various categories, such as github... https://github.com/processwire/processwire/search?utf8=✓&q=PageTable

I had the same problem when I switched to MacOS 10 years ago. I found ways to change almost all the issues I was having - there are lots of utilities out there that can help. The others I learned to live with and now I do think that overall the experience is better.

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.

Kind of embarrassed to mention my setup as it is all old school style stuff. local and remote LAMP stack SSH + RSYNC for bidirectional comms No composer, etc. Live server is with Ethernet Servers Ltd. Great VPSs. Great support too And the only module installed is Tracy VSCodium (VSCode without M$ nose buttin' in) Front end is plain html/css/js.

I usually use: IDE: visual studio code Server: hosting with DigitalOcean droplets administered with Serverpilot Staging: I edit over FTPS (I know!) on the dev server, then either copy or git to a live server. PW Modules: always use AIOM, ProCache, RockMigrate (looking into), ManageFiles, ProcessRedirects

This week ProcessWire has gone on a diet. I've been working on reducing the size of the core by moving all (except site-blank) installation profiles out of the core and into their own repositories. This cuts the size of the core in half, going from 15.5 MB down to 7.5 MB, which is quite a slim down! This means the site-regular, site-default, site-beginner, site-languages, and site-classic now live in their own dedicated repos on ProcessWire’s GitHub. The site-blank one remains, but I've updated it a bit to make the template files more useful for beginners while still keeping it a blank profile. I may do a little more with it and rename it to be site-basic or something, and then have an even more trimmed down site-blank in its own repo as well. I'm not yet sure about that, so will do a little more with it next week also. I also went through each of these site profiles and cleaned up a few things, corrected old and outdated links, and updated a lot of text in readme files and such. I think a lot of the more experienced users would also prefer not having extra profiles included in the core as well. This update came at the request of the community a few months back (I think it was Robin S. that requested it, but not positive). It's not like any of the current site profiles have a lot of bling or marketing value, as they really are more just technical examples and starting points. So I think it's kind of a win/win to trim down the core in this way. Though maybe one day we'll have a site profile that looks good and has good marketing value. But until then I think we gain more by keeping the core size nice and trim. The downside is that there's a little more for new users to figure out (downloading a profile), so in the next week or so I'm planning to update the installer to hopefully lessen that issue and maybe even build in the ability for the installer to download and install site profiles from the modules directory. That comes with its own security considerations, so I'm not yet sure we'll go that far just yet, but it's one of a few options I'm looking at. Thanks for reading and have a great weekend!

Or without any dependencies: <?php $wire->addHookAfter("ProcessPageEdit::buildFormContent", function($event) { $form = $event->return; $page = $event->object->getPage(); if($page->template != 'my-template') return; $form->add([ 'type' => 'markup', 'label' => 'foo', 'value' => 'bar@'.date('Y-m-d H:i:s'), ]); });

I have added a request "findRaw should have support for joining parents and references" (and also for getting option field titles) here https://github.com/processwire/processwire-requests/issues/427 @adrian @thetuningspoon

@ryan it came to my mind it would be very useful to create or use already built profiles for frameworks like Foundation or Bootstrap. It could speed up project starts not also for experienced users but also for beginners. Not to mention preconfigured profiles with using Twig or other template engines…

Make sure you have a filter form that action url is the $page->url. I don't know what the problem is really but it's all getting too complicated for what it really can be (dead simple). Example filter form for a paginated result list : <?php namespace ProcessWire; $filter = ""; $form = $modules->InputfieldForm; $form->attr("action", $page->url); $form->attr("method", "get"); // select with sort options $f = $modules->InputfieldSelect; $f->attr("name", "sort"); $f->label = "Sort"; $f->addOptions(array( "-title" => "descending", "title" => "ascending" )); $form->add($f); // submit button $f = $modules->InputfieldSubmit; $f->attr("name", "filter"); $form->add($f); // process form if(count($input->get)){ // processes and populates form fields $form->processInput($input->get); // if sort is not empty if($form->get("sort")->value) { // build filter and add to whitelist so it gets picked up by pagination $input->whitelist("sort", $sanitizer->selectorValue($form->get("sort")->value)); $filter .= ",sort=" . $input->whitelist("sort"); } } $result = $pages->find("template=basic-page, limit=2{$filter}"); $content .= "<h2>Show Results</h2>"; if(!$result->count) { $content .= "<p>no results</p>"; } else { foreach($result as $res){ $content .= "<p>$res->title<br>$res->url</p>"; } $content .= $result->renderPager(); } $content .= $form->render();

Oops. My bad, I apologize. My assumption was based on some old forum threads.

Thanks you so much for the insightful replies, @owzim and @AndZyk. Of course I tried to find something with PW forum search, but was not happy with the results I found. For my production site has active content creation and new content is stored in database all the time. My development environment is a snapshot of certain time in production, so it's content start getting outdated from the second I take the snapshot. I looked promptly at @LostKobrakai's Migrator-module, but the use of it felt quite complicated, especially for newbie and for beta status. I hope no-one would not take this statement offending, but I feel sometimes tutorials and forum thread information require more indepth understanding of PW itself. As a newbie one is still trying to overcome the steepness of the learning curve. If one hits a wall, it may take plenty of time to overcome it. PHP environment is quite different from java or c#, so my coding and setup skills for the latest devops style coding is shallow. Maintaining PHP code, CSS and JS is a OK with Git, but how to move created pages from dev to prod is not that simple anymore. As @Michael Murphy pointed out, in another thread, one way is by exporting/importing fields and templates. But does it export the pages or content that I have created in the dev environment in to the fields?