Document alternative solution

[szepeviktor]

This enables Polylang thus all posts can be managed, e.g. by wp post list

~/.wp-cli/commands/polylang-enable/command.php

<?php

if ( ! defined( 'PLL_ADMIN' ) ) define( 'PLL_ADMIN', true );
if ( ! defined( 'PLL_SETTINGS' ) ) define( 'PLL_SETTINGS', true );

~/.wp-cli/config.yml

require:
  - commands/polylang-enable/command.php

Please consider mentioning it. It took me 20 minutes to find out.

[diggy]

See https://github.com/diggy/polylang-cli/blob/master/src/Commands/BaseCommand.php#L12

Also note https://github.com/diggy/polylang-cli/blob/master/src/Commands/Post.php#L225

Why would mentioning this in the polylang-cli documentation be useful or relevant?

[szepeviktor]

Projects usually have an "Alternatives" section in the readme.

[diggy]

@szepeviktor I've been thinking about this, and I'm not convinced this is a viable, alternative solution. Defining the constants is simply not enough; wp post list might work, but for other pll commands I was hoping simply passing args and assoc args to the core command counterparts would suffice, but it does not, take a look at these commands I just implemented:

• https://github.com/diggy/polylang-cli/blob/master/src/Commands/Term.php#L344
• https://github.com/diggy/polylang-cli/blob/master/src/Commands/Post.php#L192

[szepeviktor]

Ok-Ok. Finding those constants to make wp post * work took me a long time. I thought it worth sharing.

[szepeviktor]

Instead of alternative solution I would call it Viktor's hack: https://github.com/szepeviktor/wordpress-plugin-construction/tree/master/wp-cli-commands/wp-cli-polylang-enabler-hack