nwoetzel

Thanks for the fast response!

It does work up to version 1.6.5 – I would need to look if it worked for 1.5.x
I agree that it is no an optimal idea, to use the language slug as the name for the front page.
I mean parent->child->subchild so that “subchild”‘s parent is “child”

All other pages are children (direct or indirect) of the first page, and we wanted to have the language in the slug, but not the parent page’s slug in all child slugs (so we did not want: /en/parent/child/subchild – but /en/child/subchild hiding the parent by using the ‘en’) – by the time, it seemed to have worked – although it might not have been a feature, but a bug (and I felt it is more of a hack) and the current polylang behavior is more correct.
The reason for this single parent construct is the user-access-manager-plugin – we make the parent page of all pages belong to the editor group (which makes all children part of the editor group) – this prevents us for explicitly setting it for each sub-tree. But it is for convenience – setting it for subtree’s is a little more work, but no problem.
If you say it really is a bad idea to have the front page use a language slug, I will adapt the parent-child structure of the page.

There are two filters, that one can use to tell wordpress that a slug is bad:
https://developer.www.ads-software.com/reference/hooks/wp_unique_post_slug_is_bad_flat_slug/
https://developer.www.ads-software.com/reference/hooks/wp_unique_post_slug_is_bad_hierarchical_slug/

Probably it would be nice to add them, so that nobody tries to do, what made our page fail. You could probably reserve ‘language’ and all language slugs that are configured languages for the site.

The tag seems to be removed already

I am not sure who is responsible for wpackagist.org, but since there is no guarantee to the consistency or logic of tags in svn (they can point to anything), some checking of meaningful content (at least a readme.txt) in the individual tags is advisable before mirroring?!
This can happen to any plugin…

I have created a fork at github
https://github.com/nwoetzel/polylang
of
https://github.com/wp-plugins/polylang

and created a branch based on tag 1.5.4
https://github.com/nwoetzel/polylang/tree/wp-cli

which fixes this issue and also adds wp-cli functionality based on
https://github.com/dereckson/wp-cli-polylang
and extended in
https://github.com/nwoetzel/wp-cli-polylang

This is a patch that can be applied to the 1.5.4 tag:
https://github.com/nwoetzel/polylang/compare/1.5.4…wp-cli.diff

It would be nice, if the command line interface also finds its way in a new polylang version, since it is a pretty nice feature and is fairly easy to maintain, since it is just calling api-functions.

Thanks

Another thought:
Since the roles can be queried for the options interface of the plugin, the mapping could be validated against the valid roles before saving. Then any mapping error (for the roles at least) are caught.

Hi Vladimir,

thanks!
The link at https://www.ads-software.com/plugins/user-role-editor/developers/ under
“current version”
“4.14.4 (svn)”
the (svn) still points to “trunk”
I am not sure what the wordpress policy is, but it seems that there is no automatism in generating/fixing these links base on the svn tags.

Anyways, with the tag you generate, we can install through svn.

Thanks a lot
Nils

This also works for us.
Thanks for finding that and documenting it here!

Nils

I actually had the same problem, but needed it for all sorts of types:
user, role, post, term
So I implemented a plugin for the wp-cli: https://wp-cli.org/
by extending the current plugin. Since I am not not clear about how to contribute directly to the project, I made a “fork” based on the current svn trunk at https://github.com/nwoetzel/user-access-manager/
and created a branch that adds wp-cli functionality:
https://github.com/nwoetzel/user-access-manager/tree/wp-cli

I hope this helps more then just me.
When wp-cli is installed, and the plugin from the branch, you should have ‘wp uam’ as a new command
in case you have just the svn version installed, you can apply a patch:
https://github.com/nwoetzel/user-access-manager/compare/master…wp-cli.patch