Yes, it's those plug-ins that define the CPTs and taxonomies.
The fatal error may stem from the fact that the plug-ins are trying to connect to an mssql server.
You can avoid that by setting an environment variable named APP_ENV to the value 'development'. They will then instead try to a different IP (on a local or docker network).
If you can privately communicate details of the fatal error, I could say more about it and perhaps supply a version of both plug-ins that won't try to connect and won't throw. That in the sense of allowing you to proceed on a staging env. rather than the production.
If push comes to shove, let me know and I can ensure we have backups of the prod environment just before your intervention.
OK, I have a version available that will not check for the presence of that PHP extension.
Could you allow me to reply via private message so I can share the URL ?
That works, I have the local copy of the site working.
Can I get some history about how the content to the site was added, and how it was translated?
I'm not sure what I should expect to see.
For example, looking at the eag-adultes-fr term of the mnhn-age-group taxonomy, assigned to the mnhn-event post type.
I've been querying the db directly to get a sense of the underlying data.
This simple query (you can perhaps check it yourself) is to see which posts have the eag-adultes-fr term assigned to them, and what is their language.
SELECT wp_posts.ID, wp_posts.post_title, wp_icl_translations.language_code, wp_icl_translations.source_language_code, wp_term_relationships.object_id, wp_term_relationships.term_taxonomy_id
FROM
wp_posts
JOIN
wp_term_relationships
ON
wp_posts.ID = wp_term_relationships.object_id
JOIN
wp_icl_translations
ON
wp_posts.ID = wp_icl_translations.element_id
AND
wp_icl_translations.element_type = CONCAT('post_', wp_posts.post_type)
WHERE
wp_posts.post_type = 'mnhn-event'
AND
wp_posts.post_status = 'publish'
AND
wp_term_relationships.term_taxonomy_id IN(163)
You can see a sample of the results in the screenshot.
163 is the ID of the French age-group term for adults, but all of the mnhn-event posts which have that term assigned are either DE or LU, translated from FR, and none of them are FR posts.
That's clearly wrong, and before going much further I want to understand the history of the site to know how this may have come about.
WordPress' WP_Tax_Query class will attempt to convert this into an SQL clause using term ids.
However, if it fails, it will return `$no_result`, which is:
```
/**
* Standard response when the query should not return any rows.
*
* @since 3.2.0
* @var string
*/
private static $no_results = array(
'join' => array( '' ),
'where' => array( '0 = 1' ),
);
```
It does this e.g. here:
```
public function get_sql_for_clause(&$clause, $parent_query) {
[…]
$this->clean_query( $clause );
[…]
if ( 'IN' === $operator ) {
if ( empty( $terms ) ) {
return self::$no_results;
}
```
In this case, `WP_Tax_Query::clean_query` removes all terms from the clause when it runs the `WP_Term_Query`. – So yeah, this is quite a hunt…
Eventually, it boils down to the `get_term_args` filter. WPML hooks into it and replaces the correct term_ids with the term IDs in another language.
This creates a WHERE that cannot work because the term_ids are for German and the language_code it requests is for French:
```
[where] => tt.taxonomy IN ('tax-age-group') AND t.term_id IN ( 154,157,160 ) AND ( ( icl_t.element_type IN ('tax_tax-age-group') AND ( icl_t.language_code = 'fr' OR 0 ) )
```
I feel like at this point, I'd have to deep dive into WPML to figure out why and not only is that not my job, it's also almost impossible to follow all the different functions.
Something is seriously broken with this installation and at this point I really no longer know what to do.
Sorry, it wasn't my intention that you spend a long time digging into the WPML code, I was simply looking for some history of your site to know how and why it got that way.
Language-specific terms are assigned to posts of other languages.
I'm looking at how to fix that, and working on it now.
My apologies, I thought I had written back to you, but I realise I hadn't.
I'm just finishing up, but let me just share that the intention is essentially to run through all the posts in French which wrongly have DE or LU terms assigned to them, to look up what the FR version of the term is, assign that, and unassign the wrong terms.
Then run the troubleshooting step which mirrors the assignments of terms in the default language to the secondary languages.
I assume that is the intention on your site, that the posts in the different languages should all have the same (translated) terms assigned to them.
> I assume that is the intention on your site, that the posts in the different languages should all have the same (translated) terms assigned to them.
Yes, that's correct.
> all the posts in French which wrongly have DE or LU terms assigned to them,
I've never observed that, at least not on the UI. Are you saying there are e.g. French Posts that have a German term_id pointing to them instead of the French term_id ?
Since you asked about the history of the site:
It's been running for a very, very long time with little to no changes to how these contents are created. And this problems only started to occur very recently.
So my intention is to fix the French posts so that they have French terms assigned (by inferring the correct French term from the DE or LU term which is actually assigned), and then run the troubleshooting batch process to then update the DE and LU posts to have the corresponding terms in their own language.
OK, I'll go ahead with that on my copy of your site, and when I confirm it works, I'll share the code with you.
The topic ‘[Closed] Trying to get property 'post_type' of non-object in class-wpml-term-actions’ is closed to new replies.
Manage Cookie Consent
We use cookies to optimize our website and services. Your consent allows us to process data such as browsing behavior. Not consenting may affect some features.
Functional
Always active
Required for our website to operate and communicate correctly.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
We use these to analyze the statistics of our site. Collected information is completely anonymous.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
These cookies track your browsing to provide ads relevant to you.
