elabx

OMG what is this gem I hadn't seen! Thanks @Gideon So!

I had not! 🤩 Thanks! Let me read the module's readme and I might come back with questions 😅

So it goes like this, you create a migration file under the Setup > Migrations. This is a "Default" type of migration. Which is the one I only use, since with RockMigrations the whole API work is abstracted so nicely that working with the "data schema" (meaning ALL the config in processwire) is really more simple, so no need for the specific migrations types. <?php class Migration_2022_06_02_11_42_58 extends Migration { public static $description = "Do some awesome migrations stuff"; public function update() { // Put your migration code here $rm = wire('modules')->get('RockMigrations'); $rm->migrate([ 'fields' => [ 'button_label' => ['label'=> 'Button Label', 'type' => 'text'] ] ]); } public function downgrade() { // Put your rollback code here } } Then this runs either through the UI under Setup > Migrations or the CLI included in the Migrations module. We could say one "caveat" is that to use the CLI you need to install the Migration module through composer as the CLI tool has dependencies assuming them. So every time I wan to to push a migration to the live site, the pipelines I use for deployment (Bitbucket Pipelines) rsync's the new files, then triggers on the server: php /path-to-website/site/modules/Migrations/bin/migrate run Or for anyone reading this not familiarized with CI/CD pipelines, just log into the server and run the command. So "migrate run" runs all "pending" migrations. Previously run migrations are already tracked as migrated, so they won't run again. cc @MrSnoozles. I DO NOT, have an automated rollback solution yet, in terms of the CI/CD pipeline. So if I break something, I just move forward with another migration. Let me know if it sounds I'm skipping something, wrote this a bit quickly!

@MrSnoozles You could take a look at using Migrations + RockMigrations (which work great hand by hand!) which satisfies exactly this. So you only substitute the "migration files" system, but use the invaluable abstractions from RockMigration. @bernhard interesting idea the tracking within the fields!

No worries mate! I precisely saw this issue commented here: https://github.com/processwire/processwire-issues/issues/1569 Did you see that or arrived to the solution by chance?

remove() takes the key as argument, not the value. I'd wonder, if the WireArray is numerically indexed, would there be a way to use a selector to find the item to delete first?

Hi @LexSanchez made a PR to support TikTok embed, thanks for this great module!

Oh! That's gotta be it!

You need to get $inputfieldTextTags from the field itself: $inputfield = $page->getInputfield('tags_field'); $list = $inputfield->getTagsList(true); foreach($list as $item){ // echo tags ? }

This is useful? https://processwire.com/api/ref/inputfield-text-tags/get-tags-list/

Oh yes, fix the ids selector! <?php foreach ($pages->findIDs('id=1223|1224|1225, sort=-created')->children as $item) : ?>

I might have complicated this way tooe much maybe simply: $item->parent->id == 1234

if($item->matches('parent=1223')){ ... } Maybe try this?

Iterating for output shouldn't be an issue, could you post a more complete code sample?? I only see an empty for loop on your previous post.

Before editing/saving any repeater item call: $item1->of(false); $item1->title = "new title"; $item1->save(); More info here: https://processwire.com/api/ref/page/of/ Repeater items are themselves RepeaterPage objects which is a class that inherits from Page, hence the formatting flag applies too.