Plugin Author
Tim W
(@timwhitlock)
Thanks for the heads up. I see this was added in WP 4.8
I’ve implemented in the dev branch if you’d like to try it out.
https://localise.biz/wordpress/plugin/developers
I used the context “loco” although debatable whether that should be “download_language_pack” as per translation-install.php
Howdy Tim and thank you very much for the quick response!
It works like a charm and the code looks great!
Well, I guess both are pretty valid use-cases. Since our use-case for using Loco translation is letting clients translate themselves instead of going through us every time, we basically have to allow download_language_pack on production sites.
So the most normal use-case for us would be download_language_pack but I can easily see use-cases where it would be nice to single out Loco.
So maybe make the context a filter and provide download_language_pack as the default value?
-
This reply was modified 6 years, 3 months ago by
Kallehauge. Reason: Mark as resolved
Plugin Author
Tim W
(@timwhitlock)
I suppose “download_language_pack” would be the correct context when writing inside WP_LANG_DIR, whereas the context in other locations should perhaps be something else.
Trying not to over-think it, but wp_is_file_mod_allowed doesn’t take a path argument, so context is the only way client code can make a decision. Different path = different context.
An alternative would be to filter the return value from the function, rather than the context value. (this would support wp < 4.8 too). Perhaps that’s filter overkill. What do you think?
I’ve updated the dev branch with just the change of context to download_language_pack and will give it some more thought.
I think you’re correct. I would also use download_language_pack as the default context.
And the entire logic is basically binary pre WP 4.8. It’s either enabled or disabled (by the constant). So I would just supply a filter for the context, so developers can do modifications if need be:
return ! wp_is_file_mod_allowed( apply_filters( 'loco_file_mod_allowed_context', 'download_language_pack' ) );
There is also a bigger chance for other third party plugin support if the logic is kept in wp_is_file_mod_allowed() instead of introducing custom logic in the plugin. Example:
It is likely that someone will make an UI for file modifications after this have been introduced (like User Role Editor) – we simply have to change the context and voila 🙂
Plugin Author
Tim W
(@timwhitlock)
Good points. Best keep to WordPress standards than add proprietary stuff unecessarily.
I’ve updated the dev branch again with the filter name you suggested.
If you add the filter with 2 arguments, you’ll also get a Loco_fs_File instance. This can be used to query the path being written to.
WOPS! I completely forgot to thank you for your quick and efficient effort. Thank you Timwhitlock! 🙂
