Leaderboard

And now I got for you: Version 1.2.2 ? With @adrian's help I managed to find out, that the `date()` function in PHP 8 seems to return the current date, if NULL is passed in as the second parameter. In PHP 7 this was 01.01.1970 which was handled correctly. Long story short: Now I will write NULL to the database without any date-formatting. This should make AppApi fully compatible to PHP 8.

I have been following tailwind css for a while. Can't help it but having so many classes in a tag really clutters up your html. What has become wrong with vanilla css ?

textformatter module

Thx, fixed in v0.0.73

@bernhard I found a bug in your RM update, this line https://github.com/BernhardBaumrock/RockMigrations/blob/master/RockMigrations.module.php#L1007 should be $data[$key] = $addFields; Data under repeaterFields option should be field ids, not names, obviously. Otherwise style and script assets are not loaded for inputfields in repeater (if not present in other places in the form). It took me quite a long time to figure out that ?.

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!

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

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], ], ], ], ]);

And the guided tour of TW 3

Please read this blog entry. You can use images, links, a dropdown or your own custom solution for adding new matrix items: New Repeater and Repeater Matrix features (processwire.com)

I guess it's just CSS? a.InputfieldRepeaterAddLink.InputfieldRepeaterMatrixAddLink.InputfieldRepeaterAddLinkInit[data-type="3"] { font-size: 0; width: 150px; height: 100px; display: inline-block; background-image: url(https://via.placeholder.com/150); background-repeat: no-repeat; } span.ui-priority-secondary { display: none; }

If you already have HannaCode installed, you can use that to run code in the backend easily using the Test option. If not, then you can place it into an existing template file. If it's a live site then maybe wrap it in: if($user->isSuperuser()) { so that it only happens once when you visit the page with the template. I would also recommend testing that code of mine on a dev/testing site first. I adapted it quickly from https://processwire.com/talk/topic/6654-convert-repeater-to-pagetable/ - I think it should be fine - looks good, but always worth a double check before running something like this on a live site.