Background of the issue:
I have a complex custom developed site and want to give custom user roles access to translate custom post types. There are multiple issues already reported all leading to the following page: https://wpml.org/errata/wpml-custom-role-based-on-the-editor-role-cannot-edit-translations-and-behave-as-editor/ However, I have the latest update installed and the code in the user class still looks like this. public static function isEditor( WP_User $user = null ) { foreach ( static::ROLE_EDITOR_MINIMUM_CAPS as $cap ) { if ( ! self::hasCap( $cap, $user ) ) { return false; } } return true; }
Symptoms:
The workaround provided is not upgrade safe.
Questions:
How can I allow custom user roles to translate custom post types?
How can I make the workaround upgrade safe?
After reviewing the code, could you grant me access to your website and demonstrate how the code is hindering your desired outcome? Additionally, please explain the adjustments you've made to address the issue based on the workaround provided. This information is necessary for me to compile a report for our 2nd Tier Support to investigate further.
Please note that it is important to have a backup for security purposes and to prevent any potential data loss. You can use the UpdraftPlus plugin (https://wordpress.org/plugins/updraftplus/) to fulfill your backup requirements.
Your upcoming reply will be treated with confidentiality and will only be visible to you and me.
✙ To resolve the issue, I may need your consent to deactivate and reactivate plugins and the theme, as well as make configuration changes on the site if necessary. This emphasizes the significance of having a backup.
I am clearfiying the issue in this loom: hidden link
The application is in production already and i can definitely not share credentials. To be honest, i am having a hard time understand what the credentials you are requesting are used for. Just check the code and the loom. This is NOT about third party dependencies. The missing hook will not magically show up when deactiviating other plugins. It is purely a thing about your very own code implementation.
This is clearly a "bug" or at least a not ideal implementation that each of your developers should be able to identify immediately.
Our secondary support team has examined your query and noted that it pertains to a hook, which will be treated as a feature request. They have forwarded this to our developers for further evaluation.
This is quite disappointing feedback. According to your documented workaround, this hook should already be added in one of the previous versions.
This is terrible developer experience if i cannot trust your documentation. Also, this is definitely not a feature request but a bug, since again it is supposed to work with this hook.
In the forum I can see many users waiting desperately for 4.7 since there are also many deprecation notices that are not fixed!.
With all respect, I would like to ask for an ETA, because without one I have to evaluate if it makes sense building sites on WPML. This is not reliable at all.
I've got feedback from our 2nd Tier Support indicating that our developers will be reaching out to you shortly regarding this matter. We'll keep you informed about the status as soon as we have an update.
