Leaderboard

There's a new $pages->new() API method on the core dev branch this week. This method is similar to the $pages->add() method, in that it is used to add new pages to the DB, but is a lot better in my opinion. The $pages->add() method has arguments that you have to remember, whereas $pages->new() accepts a single-argument selector string, like many of the other $pages API methods. This new method can also auto-detect some properties that the add() method cannot (like parent or template). Let's take a look at how to use it. Here we create a new page from a selector string, and it returns the new page (saved in the database): $p = $pages->new("template=category, parent=/categories/, title=New Category"); If you prefer, you can also use an array: $p = $pages->new([ 'template' => 'category', 'parent' => '/categories/', 'title' => 'New Category' ]); The page name and parent can be auto detected if you specify a path: $p = $pages->new('path=/blog/posts/foo-bar-baz'); But if you start the selector string with "/" then it is assumed to be the path, so this is is exactly the same thing as above: $p = $pages->new('/blog/posts/foo-bar-baz'); In your selector string or array, you can specify any page property or field name that you want to set with the new page. It's basically just a quicker way to do something that's already pretty easy to do, but I thought people might find this new option even more handy in many instances. To create a new page, it needs to know the template and the parent. If your template family settings are configured in a manner where it can auto-detect, then it will do so, at which point parent or template becomes optional. In the last example above, it detected that the template was "blog-post" and the parent was "/blog/posts/". A few things to note (pulled from the method documentation): If a `path` is specified but not a `name` or `parent` then both will be derived from the `path`. If a `title` is specified but not a `name` or `path` then the `name` will be derived from the `title`. If given `parent` or `path` only allows one template (via family settings) then `template` becomes optional. If given `template` only allows one parent (via family settings) then `parent` becomes optional. If given selector string starts with a `/` it is assumed to be the `path` property. If new page has a name that collides with an existing page (i.e. “foo”), new page name will increment (i.e. “foo-1”). If no `name`, `path` or `title` is given (that name can be derived from) then an “untitled-page” name will be used. The `class` of the Page will be auto-detected when applicable (and something different than `Page`). An exception will be thrown if it doesn’t have enough information to create a new page in the database. I've also updated the existing $pages->newPage() method to accept the same selector string (or array). You might already be familiar with this method, but if not, it creates a new page in memory, but not the database. So you might use it to create a new page that you will call save() upon later. $p = $pages->newPage('template=blog-post, name=hello-world'); This week the core also has a few issue fixes. I'll wait another week before bumping the dev branch version though, as there's more to add first. Though the next few weeks might be little slower on core updates as the end-of-the-year seems to always be the busiest time when it comes to client work... everyone wants to wrap things up before the new year, and I do my best to accommodate that, while also keeping PW updates in progress. Thanks for reading and have a great weekend!

Just a quick heads-up: https://tailwindcss.com/blog/tailwindcss-v3.

And the guided tour of TW 3

Hello everyone, for anybody using Gravatar who didn't hear the news: Gravatar had a data leak exposing the name, username and email address of your public profile: https://monitor.firefox.com/breach-details/Gravatar For me reason enough to never use Gravatar again, but that is of course my personal decision. ? Regards, Andreas

FieldtypeColor is on github Fieldtype stores a 32bit integer value reflecting a RGBA value. Input 5 types of Inputfields provided Html5 Inputfield of type='color' (if supported by browser) Inputfield type='text' expecting a 24bit hexcode string (RGB). Input format: '#4496dd'. The background color of the input field shows selected color Inputfield of type='text' expecting 32bit hexcode strings (RGB + alpha channel) Input format: '#fa4496dd' Inputfield with Spectrum Color Picker (Options modifiable) Inputfield type='text' with custom JavaScript and/or CSS (since version 1.0.3) Output Define output format under 'Details' tab in field settings. Select from the following 9 options string 6-digit hex color. Example: '#4496dd' string 8-digit hex color (limited browser support). Example: '#fa4496dd' string CSS color value RGB. Example: 'rgb(68, 100, 221)' string CSS color value RGB. Example: 'rgba(68, 100, 221, 0.98)' string CSS color value RGB. Example: 'hsl(227, 69.2%, 56.7%)' string CSS color value RGB. Example: 'hsla(227, 69.2%, 56.7%, 0.98)' string 32bit raw hex value. Example: 'fa4496dd'(unformatted output value) int 32bit. Example: '4198799069' (storage value) array() array( [0] => 0-255, // opacity [1],['r'] => 0-255, [2],['g'] => 0-255, [3],['b'] => 0-255, ['rx'] => 00-ff, ['gx'] => 00-ff, ['bx'] => 00-ff, ['ox'] => 00-ff, // opacity ['o'] => 0-1 // opacity ) The Fieldtype includes Spectrum Color Picker by Brian Grinstead SCREENSHOTS Input type=text with changing background and font color (for better contrast) Input type=color (in Firefox) Javascript based input (Spectrum Color Picker) Settings Output Settings Input

Thank you all for your help and ideas. I solved my issue with creating some magic with dynamic options, hiding fields depending on their parent and using some kind of namespace for the fields to match them to the categories. While developing this I learned a lot about the fields API and remembered how awesome processwire is ?

I can't find it there either, but Tracy has you covered :)

Import/Export has a number of problems and fails to deal with some field types properly. Not wishing to detract from RockMigrations, which is excellent, but there is also my module ProcessDbMigrate. It is different in concept in that it is UI-based rather than code-based. It does handle 'uninstallation' of migrations and also database comparisons, but there are some features of RockMigrations that it does not have. In it I used some code from Import/Export but ditched or fixed quite a bit.

Adding data via migrations is the most straightforward thing, but removing or renaming is a little more tricky, as you realized ? Usually all methods are built in a way that they can run as often as you want. That means you can just run $rm->renameField(...) as often as you want: https://github.com/BernhardBaumrock/RockMigrations/blob/dc9dba1b050469ea085af9dca1201746e2422960/RockMigrations.module.php#L942-L944 I know that adds a little overhead and I've heard from @dotnetic that some of his migrations needed around 20 seconds to finish. On all of my setups (and I'm using RM all the time, everywhere, extensively) site-wide migrations fired via $rm->fireOnRefresh(...) take at most around 2 seconds to finish. If you really want to avoid that, you can always do custom logic via PHP's if/else... Of course that does not work with declarative syntax, but that's no problem in my opinion. The declarative syntax is easier to use and easier to read, but it has limitations regarding the execution of things by design. I'm not sure. I've evaluated it more than 2 years ago and never ever used it again. It was simply useless for my workflows. I've just had a glance in the core and it does not seem to be very helpful for RM. I've just addes support for your request and added an example to the readme: $rm->migrate([ // fields to create 'fields' => [ 'ready_text' => [ 'type' => 'textarea', 'tags' => 'ReadyDemo', ], 'context_example' => [ 'type' => 'text', 'label' => 'Global field label', ], ], // templates to create 'templates' => [ 'ready_blog' => [ 'tags' => 'ReadyDemo', 'fields' => [ 'title', 'context_example' => [ 'label' => 'Field label on ready_blog template', ], ], ], Repeaters $rm->migrate([ 'fields' => [ 'foo_field' => [...], 'bar_field' => [...], 'my_repeater_field' => [ 'type' => 'repeater', 'repeaterFields' => [ // you can set field data in repeater context like this: 'title' => ['required'=>0], 'foo_field' => ['columnWidth'=>50], 'bar_field'=> ['columnWidth'=>50], ], ], ], ]);

1) It seems, the SEO reason that I gave is being taken very literaly. To me, it's more a matter of having built-in flexibility to structure pages without necessarily exposing the structure. I may not want to expose the parent page in the front-end. 2) "Virtual Pages" aligns with Ryan's "no assumptions" design principle. ProcessWire allows the admin to structure pages - but doesn't make (too many) assumptions about how these pages are output in the frontend. Or, to put it in the words of Ryan, "ProcessWire doesn't control the front-end, there are very few assumptions that can be made from an editing perspective." See also: No assumptions (cute interview!). 3) Short urls are cool - SEO or not - and "Virtual Pages" help me achieve that. Consider these versions of the same url: Long: www.example.com/book-reviews/wheres-wally-in-hollywood/ Short: www.example.com/wheres-wally-in-hollywood/ 4) WordPress has a bunch of change / shortify your urls tools - some quick examples: https://wordpress.org/support/article/pages/#changing-the-url-of-your-pages https://wordpress.org/plugins/url-shortify/ @bernhard URL hooks are nice. Thanks for that pointer. @wbmnfktr Thanks for the VirtualParents module link. I'm trying not to use plug-ins and would prefer to have this flexibility built-in (or use hooks). Thanks for constructive inputs and perspective. I'll rest my case.

ProcessWire 3.0.190 has 15 commits relative to 3.0.189 and contains a mixture of issue resolutions and feature additions. We’ll review these below, in addition to updates for the PageAutosave and ProFields Table modules— https://processwire.com/blog/posts/pw-3.0.190/

Hi guys! I'm a bit anxious because this is the first module I present! (beta modulo) But I will finally be able to share something with the community too! :) This is a BETA version of the PayPal payment system called: PayPal Commerce Platform. It is an advanced system (Business Pro account is needed) that brings various benefits in terms of fees and above all integrates direct payment with credit/debit cards. The module integrates with Padloper 0.0.2, which is the current installation I'm using. This system integrates the classic PayPal buy button, the alternative or local payment method and the new payment system: credit/debit cards that doesn't go through the PayPal account. It is a Stripe-style payment, it connects directly with the bank and integrates 3D security validation. I say that it is a BETA because this module currently only works with Sandbox account, to put it live you need to change API url manually (manually for the moment). Because this module is not ready for live: I would like to have your opinion on how I built the module (is the first one I do). I don't want to share something that is not fish but I need a comparison with someone more experienced than me, for be sure that this is the best way to code the module. If you want to try this I created a git, you will find all the instructions for installation and correct operation. (Git has a MIT licensed) https://github.com/MarcooRo/processwire-PayPal-Commerce-Platform I hope I did something that you guys can like :) UPDATE I have been testing the form for several days and everything is working fine. Each order enters correctly, so I have updated the repo with the latest changes and I can confirm that this version is ready for live! I have updated the repo: Added error message + popup Fixed some bugs related to multilingual Updated the switch for checking the responses of the 3D security system

This is a holiday week here in the US, at least for my kids (school break). With kids home I've been off work this week so don't have any ProcessWire updates to report, but I'm looking forward to getting back to work next week and will have more updates to report then. Yesterday was Thanksgiving here in the the US and that kind of marks the beginning of the holiday season here. So today the Christmas tree went up, the lights are coming out and the holiday music has taken over the radio (or Alexa or Google or whatever we call it). Cheers and Happy Holidays!