Cleanup content files

I was curious if there is a way to ‘cleanup’ content files?

I have been tinkering with the setup a lot, which makes that the content files contain a lot of empty / unused fields. So I was wondering if there is a automated way to ‘clean’ the content files based on their template/blueprint? (as that should be the only data in the content file anyways, right…?)

There is a cookbook recipe I wrote some time ago:

… which never really worked for me, to be honest. I wonder if that’s something to open an issue on GitHub about :thinking:

Sure, please do with a description what exactly didn’t work.

Not sure if I can reproduce it, will try … did you run your script against a starterkit after deleting some fields from blueprints or something?

I tested it of course when I wrote it and have also used it in the past, but haven’t tested recently. Maybe I should…

Alright, I‘ll dig up some old repo and fire it up, that should do it. Will report back (some day).

I ran a quick test with a 3.5 Starterkit and the script runs as it should…

I executed the script on a production project two days ago and it worked very well. :+1:


@Oziris Thanks for your feedback!

For some reason which I have never been able to sort out so far, I cannot run scripts by calling them in the browser when using Valet as my dev environment. Then I just get the the error page. In that case, it might make sense to move the the functionality into a route or template, or use PHP’s built-in server to run the script.

Another issue you might run into is script timeouts when you run it against a very large site.

You can modify it a little to make it able to run for longer.
Also I would recommend launching it in a separate process (which will work on local environments as well).

To make this work within a page it is advisable to use a route/api hook for triggering the script.
I use the following snippit to activate a process during a route hook (copied from a video-call plugin)

        // get script location
        $scriptfile = kirby()::plugin('my/plugin')->root() . "/src/async_script.php";
        // get log location
        $logfile = $this->root . static::LOG;
        // auto detect windows vs unix envorinment
        if (strtoupper(substr(PHP_OS, 0, 3)) === 'WIN')
            $cmd = "start cmd /c php -f \"${scriptfile}\" ^> \"${logfile}\"";
        else $cmd = "nohup nice php -f \"${scriptfile}\" ^> \"${logfile}\"";

        // shell_exec($cmd); // little bit tricky to get it working reliable
        pclose(popen($cmd, 'r')); // works better for me

The async script can be the same as in the linked post. But I would add the following lines

/* for logging purposes */

/* Prevent timeouts. */

/* is a neat way to enable IO from the process owner, this can be used to implement pause/terminate behavior (not currently available in the script) */

A fun alternative would be to include it in a page as a server-event script.
You have to give direct access to the script (propably by modifying the .htaccess file). If you do I would recommend adding a authentication layer to it (which is possible since the script is initializing a kirby instance already.

1 Like

i have a case where i would like to change existing fields in a multilang-site to “translate: false” (mostly date fields). if i do so, fields in translations (!= default language) will become “disabled” with the existing values still being in effect. i am wondering:

  • is this in fact a bug ?
  • does the cleanup-script take “translate: false” into account and wipe those fields from existing translations?