LostKobrakai

If you can set the visibility to hidden in the field's settings then the above change should work as well, but maybe you need to hook somewhere else, so that the render() method won't actually be called for that field (because it's hidden).

Try Inputfield::collapsedHidden instead of "hidden".

Firstly welcome to the forums. These are processwire specific settings / files, so it's perfectly reasonable why you don't know them.

For those who would rather like the cli tool to live in another directory (e.g. root in my case) you can use this in a file named 'migrate': <?php // Full or relative path to the module's cli include_once __DIR__ . '/site/modules/Migrations/bin/migrate';

Hook before InputfieldPageTable::render and set the "collapse" mode to hidden if the table is empty and it's your specified field.

It should be as it's using mysql to sort randomly instead of loading data into the runtime memory.

I've not used it, but I'd imagine it doing the latter. Should not be to hard to test out. If the resulting pages to change it's the latter.

sort=random in the selector should work.

@BitPoet Just a suggestion: Maybe inverting those if statements could make this a bit less nested. if($database->exec($sql) !== false){ […] } // to if($database->exec($sql) === false) continue; // or break;

The simplest answer is that classnames cannot be shortened, but namespaces can. The ProcessWire namespace is not the best example here, because it's still not to long, therefore I'll use some namespaces from the flysystem package. use Aws\S3\S3Client; use League\Flysystem\AwsS3v3\AwsS3Adapter; use League\Flysystem\Filesystem; $client = S3Client::factory($credentials); $adapter = new AwsS3Adapter($client, 'your-bucket-name', 'optional-prefix'); $filesystem = new Filesystem($adapter); […] if(!$filesystem instanceof Filesystem) die(); // vs. $client = Aws\S3\S3Client::factory($credentials); $adapter = new League\Flysystem\AwsS3v3\AwsS3Adapter($client, 'your-bucket-name', 'optional-prefix'); $filesystem = new League\Flysystem\Filesystem($adapter); […] if(!$filesystem instanceof League\Flysystem\Filesystem) die(); Now imagine you'd need to use these classes 15 times in a file. You'd have to write them 15 times in their full glory without namespaces. With them you can always use the shortname of a class in your code, which keeps it readable and even if the shortname would collide you can do this to use an alternative short name for one of those in the file. (Alternativ naming does even work if classes don't clash.) <?php namespace kobrakai; use ProcessWire\User as PwUser; class User extends PwUser {} The use statement is super useful because you hardly need conflicting classes in a single file. Therefore you declare once which class you want to use in a file and never care about it later on. With longer classnames you need to constantly care about it trying to remember that one special long class name. The next benefit is the "folder" structure namespaces give yourself. As long as classes are in the same namespace you don't actually need to do anything besides the namespace declaration once. Only accessing classes outside the current namespace does need you to specify the namespace in any way. > kobrakai > Form > ImageGallery > … <?php namespace kobrakai; use DateTime; use ProcessWire\PageArray; class Form { public function ImageGalleryButtons(PageArray $options) { // Namespace needed $g = new ImageGallery(); // No namespace needed […] $date = new DateTime(); // DateTime is a core class, therefore also another namespace (root) } } Like you've seen above namespaces are great to extend classes. If I want to change a already existing file, which does use ProcessWire\User to use my own implementations (with maybe some additional business logic) I just change the use statement and I'm done. The file is still as readable as before. There were 100% no accidents in trying to search/replace classnames. We are still talking about users. <?php use kobrakai\User; // from: use ProcessWire\User; $u = new User; $u->name = 'my-user'; … if($another_u instance of User) $u->friend->add($another_u); …

It should be. I've run it on multiple 2.7 installations.

The BatchChildEditor is using this quite heavily if I remember correctly. And to get more information search for showIf and requireIf.

Just click the name and it's retrieving a fresh copy from github even for the same version number.

This might happen, but should actually be a rare edge-case, especially as namespace and classname must collide to be an issue. The difference is that the chances of two libraries having a User class is certainly much higher than both having a ProcessWire\User class.

I've released the module mentioned above as beta: https://processwire....045-migrations/

I've released the module mentioned above as beta: https://processwire.com/talk/topic/13045-migrations/

Is h_age a textfield or a integer/float field? Only the latter ones should be able to use the >/< operators.

I can surely see the need / desire for such a feature, but conceptually groups aren't really the way to handle this in ProcessWire. We already have a way to group fields and have access control on them and stuff. They are called templates. To accomplish what you're asking for I'd rather suggest we need a page field, which would act kinda like a repeater and (automatically) create a new page with one-to-one mapping to the current. And it would need to simply add fields to the page edit UI like the repeater does, but without the actual repeating part. Just the "repeater-like" setup should be changed to be handled like it's done for pagetables by using "real" templates. This way all existing tools/workflows and core handling can stay the same, but things like seo fields can still be shared with different pages.

I marked it as solved.

I've just commited a few smaller updates (most on Jonathan's requests) Migration descriptions are now escaped, so that characters like double quotes or backslashes won't break any newly created migrations. Also the backend UI does now feature a textarea instead of a text input to allow for multiline description entry. In the cli one would have to add "\n" linebreaks manually. The module does now try to add the /site/migrations/ path automatically, when it's called for the first time (e.g. by accessing the admin UI page) I've added a basic onboarding page for the admin UI, when there are no migrations, which does now feature a "Create New" button to get started. Jonathan did also request the addition of importer migrations for modules like FormBuilder or HannaCode. I'm not really keen on adding those and especially maintaining them. I'd rather suggest creating a GitHub repo, where the community can add migration snippets via pull-request. For example using the FormBuilder importer is just a single line of code, whereas the HannaCode importer would need to be copied nearly completely, because it's so tightly coupled with it's backend form. This repo option would be an easy way to just share the bits of boilerplate which is sometimes needed to do things via the api. Additionally I'm going to add some example above on how to add own helper methods to the Migration class with hooks, so everybody can add his own helper functions. Edit: I've added the mentioned docs about helper functions.

No, sorry. I meant it's not a good idea for the compiler to add a namespace declaration. You yourself can do what you want / need to do in your template files.

Take a look into MarkupPagerNav, which does exactly this for creating it's paginations. The issue you're facing is actually not an issue, but a common practice for frameworks of all sorts. The .htaccess file does rewrite the request to be able to enter the application always via the index.php. To still know where the user wanted to go the path must be passed as get variable. In case of ProcessWire this get variable is "it".

The file compiler does not add the namespace, but rather rewrites all instances, where class names where used without proper namespace. new Page() => new \ProcessWire\Page() new PageArray => new \ProcessWire\PageArray if($page instanceof Page) => if($page instanceof \ProcessWire\Page) Adding a namespace declaration to a file is not a good idea for the compiler, because it affects all used classnames, not only the processwire ones.

Sure. I just wanted to get it out, but this can certainly being added. We're using Cronjob DB Backup on our project so it's not been so much a necessity for me. Also it wouldn't even need to check for anything as the backup functionality is part of the core. Only the admin UI must be installed.

This module is deprecated in favor of RockMigrations. It'll continue to work and I might fix some smaller incompatibilities if they're reported, but no major development will happen on this anymore. There where various threads about a how to reasonably handle multiple dev/staging and live environments with ProcessWire and at best handle it as automatically as possible. A git based workflow makes it easy to handle files, but the pain point of migrating db changes has even lead to multiple requests of not handling template/field storage in the db at all. I've gone ahead and used for my own projects the concept of database migrations, which most frameworks are using to handle database changes – but the ProcessWire flavored way. ___ ___ ___ ___ ___ ___ ___ /\__\ /\ \ /\ \ /\ \ /\ \ /\ \ /\ \ /::L_L_ _\:\ \ /::\ \ /::\ \ /::\ \ \:\ \ /::\ \ /:/L:\__\ /\/::\__\ /:/\:\__\ /::\:\__\ /::\:\__\ /::\__\ /::\:\__\ \/_/:/ / \::/\/__/ \:\:\/__/ \;:::/ / \/\::/ / /:/\/__/ \:\:\/ / /:/ / \:\__\ \::/ / |:\/__/ /:/ / \/__/ \:\/ / \/__/ \/__/ \/__/ \|__| \/__/ \/__/ Beta This module does help you managing migration files, where any database changes can be stored in php files using just the simple ProcessWire api at your disposal. It's not as nice as using the admin UI, but certainly better than trying to migrate changes manually and possibly weeks after adding the changes. Also there's always the option to create helper modules, which can export changes made in the admin UI to something usable in those migration files. For example I'm using an internal process module, which does let me export changes to template access rules as json strings, which I then use in my migrations to actually apply the changes. Now on to the meat – How to use the module: Read the following guide on creating own migrations Maybe use the CLI tool to speed up your workflow (and possibly automate stuff) It is generally recommended, but not enforced, that migrations are run/rolled back in order. When doing migrations or rollbacks, without specifying a migration, this module will stick to the order. Creating Migrations Your migrations will probably hold lot's of code, which does delete data. By now this module does not have any security measurements to prevent that. Be sure to test your migrations locally and possibly keep a database backup before running them. There are currently four types of migrations: default (Migration) Default migrations are the most free form migrations. There's just a description and two functions – update() and downgrade(). What you're doing in those functions is totally up to you, but it's recommended to try the best to keep changes as reversible as possible. Meaning that running update() and downgrade() once should have as less effect on the installation as possible. The ProcessWire API is available exactly like in modules using the $this->pages, $this->config, … syntax. FieldMigration TemplateMigration ModuleMigration All of those are there to make your life easier. They all have different but similar functions – which you can find in migrations created by this module – which ease the creation and removal of fields, templates or modules. All the boilerplate is handled by the base classes these migrations do extend, so you don't even need to think about update() and downgrade(). You can rather just describe the item you want to handle and the creation / removal process is taken care of. These are by now not highly tested, so please again be sure to test migrations before running them on important content. Command-Line Interface The module does include a cli interface, which does allow the migrations to be run automatically by CI or deployment scripts or just by you if you like cli's. The cli script is located in the bin directory inside the module's folder. It does however require a composer package to work, which you can simply add by running composer require league/climate in your site directory (or the root directory for pw 3.0). Make sure to require composers autoload.php in your config.php for 2.x installations. The CLI does have a quite handy help page, which you get by running php migrate -h so I'm just adding the important bits of that here: > php migrate -h […] Usage: migrate [-h, --help] [-i info, --info info] [-m migrate, --migrate migrate] [-n new, --new new] [-nf newField, --newField newField] [-nm newModule, --newModule newModule] [-nt newTemplate, --newTemplate newTemplate] [-r rollback, --rollback rollback] Optional Arguments: -m migrate, --migrate migrate Run a specific migration or all new* ones if none given. * From latest migrated to newest. -r rollback, --rollback rollback Undo a specific migration or the latest one if none given. -n new, --new new Bootstrap a new migrations file. Optionally you can already supply a description. -nt newTemplate, --newTemplate newTemplate Bootstrap a new template migrations file. Optionally you can already supply a description. -nm newModule, --newModule newModule Bootstrap a new module migrations file. Optionally you can already supply a description. -nf newField, --newField newField Bootstrap a new field migrations file. Optionally you can already supply a description. -i info, --info info Get detailed info about a migration. -h, --help Show all commands of the cli tool. Link the migrations cli update save to ProcessWire's root: https://processwire.com/talk/topic/13045-migrations/?p=118329 Helper Functions There are already a handful of helper function included in the Migration base class, which tackle things I found to need way to much boilerplate for kinda simple changes, but you can also add own custom helper functions via hooks. /** * This does use @diogo's while loop technique to loop over all pages * without getting memory exhaustion. */ $this->eachPageUncache("template=toBeHidden", function($p){ $p->setAndSave('status', Page::statusHidden); }); /** * $template, $field, $reference = null, $after = true * The below function reads like this: * In the template … add the field … relative to the field … in the position after/before */ $this->insertIntoTemplate('basic-page', 'images', 'body', false); /** * Edit field settings in context of a template */ $this->editInTemplateContext('basic-page', 'title', function($f, $template){ $f->label = 'Headline'; }); And a simple example of adding a custom helper as a hook. // in ready.php $wire->addHook('Migration::renameHome', function(HookEvent $event){ $name = $event->arguments(0); wire('pages')->get('/')->setAndSave('title', $name); }); // in the migration $this->renameHome('Root'); Snippets Still not sure how all this works in practice? Or you want to share a maybe more complex migration? Just head over to the Snippets Repo at Github. https://github.com/LostKobrakai/MigrationSnippets There are also less specific examples in the modules repository: https://github.com/LostKobrakai/Migrations/tree/master/migrations Appendix As long as the module is in Beta the helper functions in the Migration.php might be object to change/removal, so be aware of that. Download http://mods.pw/Bm https://github.com/LostKobrakai/Migrations