Autoblog WPML Languages Addon not working

I am adding news syndication to an existing set of four separate WordPress sites - one parent and three children. I bought Autoblog for that purpose and have had success in importing the relevant feed.

However, the sites are multilingual using the WPML plugin. The new posts are added to the child site (only testing with one so far) but don't show up. Looking around I see that the issue appears to be a lack of language_code in the icl_translations table - and indeed if I manually add en in there the post appears.

Could you please grant me access to your backend so that I may see exactly what is happening?
To do so, from your dashboard go to WPMUDEV => Support => Support Access and click on the "Grant access" button.

Hope you're well today! I've just checked this out for you and I'm noticing a couple of issues of here,

The feed seems to be a internal network feed, which means I can't test that, but just to check, is this on the same internal network feed, or is this a separate network? If so we'll need to set up some forwarding for that.

Your using a outdated version of WordPress (3.5.1), I would strongly recommend upgrading to (3.9.1).

Your WP_cron is timing out, this seems to be because it can't access the feed.

If you could advise on how you have this internal network setup please that would be great. :slight_smile:

Yes its all on an internal network, all hosted on the same LAMP test server - including the feed. I've opened it to an external IP for you. Internally all the sites find the feed, and import from it, with no issues. It doesn't really matter what feed is used for now though, its just a test to try and get a value added to the table in WPML.

I would update the feed to that external IP for you but I'm not sure how seeing as I can't see it anymore I can't update the details. I did try adding a new feed but thats blank to me too.

Sorry a bit new to this and not had WordPress on an external IP from the test server before. Not sure why I can't get to details to change stuff though, the cron error? If so it'll be hard to fix that...

I'd prefer to avoid upgrading WordPress for now if thats an option. There are numerous sites involved with various plugins and I don't want to break anything until it's all been thoroughly tested for compatibility.

I have tried importing with the WPML addon but it still does not tag the icl_translations table with a language code - thus the imported posts don't appear. This is on an entirely different server configured by a hosting company.

In an attempt to test whether a different language feed imports I tried to add a second feed to autoblog. This appeared to be impossible. Regardless of whether I clone a feed or add new there is only one feed listed in the all feeds box (the most recent update) - though looking at the database I believe they may have all been created but only one displays; certainly there are 8 entries in the autoblog table.

Could this (all) be a version compatibility issue? As I previously stated I'd prefer to not upgrade if its at all avoidable to ensure nothing else breaks but if that will solve this...

That said WordPress reports its as supposedly being compatible

AutoBlog
You have version 4.0.9.3 installed. Update to 4.0.9.4. View version 4.0.9.4 details.
Compatibility with WordPress 3.5.1: 100% (according to its author)

On the upgraded server Autoblog now shows multiple feeds in the All Feeds list - though incidentally it will no longer accept a valid locally hosted feed, even with Allow Force running. It will find it off that hosted site I setup... does it try to validate now? The local url worked fine on 3.5.1

Also the WPML Languages Addon still doesn't update the icl_translations table with a language value in WP 3.9.1.

I've also some some more digging into that single feed display issue in WordPress 3.5.1. As you expected with Autoblog 3.9.9.8 they display correctly but hitting version 4 with the significant code rewrite it breaks.

Then like a fool I realised I didn't have this particular test site set to display errors. Doing so generated this when the first Post Type display was hit
Fatal error: Cannot use object of type stdClass as array in wp-includes/post.php on line 1525

Looking through the code I found that the issue happens in Feeds.php and although I don't know what changes they have made to WordPress between versions the problem occurs in the $labels block.

Surrounding that block with a clause based on the WordPress version global variable so it only runs when its 3.8 or higher means the latest Autoblog still runs fine on my 3.5.1 installs.

No doubt a bit of a botch job but it means I can see all the feeds now :slight_smile:

One thing I will ask. As I'm already behind schedule and the client is really pushing for this would it be possible to send me the fixed WPML Languages add-on code directly ASAP rather than waiting for a new version of Autoblog to be rolled out?

I told Jack in live chat that I was planning to modify the working addon a little to reconnect the translated posts and he asked me to post my (shoddy) code here.

So the principle is thus. The child site will import several language feeds and the fixed addon will update WPML's icl_translations table with a suitable code in the language_code column based on the feed language. This is how the addon is supposed to currently work I believe (though the language code is currently never added).

But in order for WPML to know the posts are actual translations, and subsequently show a language picker for that item, they all need to share a value in the icl_translations trid column (for translation id).

As the feeds are independent and won't share a common value to my knowledge (except maybe post time) I modified WPML slightly to add a unique identifier tag to all connected posts (parent and translations) constructed as WPML_[parent_post_id] i.e. WPML_1800

I set Autoblog to import feed categories as tags and create new if needed so all imported connected posts get a shared term_taxonomy_id.

The intent then is to update all the trid columns at the same time as the language update to match the trid columns to the lowest assigned trid value for posts with that tag (as the lowest trid value will be the first post autoblog processed regardless of which language feed triggered first)

// *** REWRITE GROUP TRIDS TO MATCH IF WPML_#### TAG EXISTS
// *** get the tag id if it exists
$terms = get_the_terms($post_id, 'post_tag');
if(!empty($terms)) {
foreach ($terms as $term) {
if(strpos($term->name, "WPML_") === 0) {
$term_id = $term->term_id;
break;
}
}
}
if(!empty($term_id)) { // if empty then no tag and not translated, don't try to match trids
// get lowest trid of translations with matching WPML tag. This will have been the first inserted and will thus be the value assigned to all tag matches
$trid = (int)$wpdb->get_var(("SELECT MIN(trid) FROM {$wpdb->prefix}icl_translations AS trans INNER JOIN {$wpdb->prefix}term_relationships AS rel ON trans.element_id = rel.object_id WHERE term_taxonomy_id = {$term_id}"));
}

This I can confirm because a new entry is added for each imported post to icl_translations regardless of whether the addon is running or not.

The problem is that that new entry, while being correct doesn't have a language_code value and thus doesn't appear because it fails to match the filter.

Looking at your new code I see that the language_code finder remains but then nothing is actually done with that value.

I'm sure that $sitepress->;set_element_language_details(...); needs to be run (as it was in the original version) to correct the language_code, source_language_code and in my case the trid, but my confusion was as to why that wasn't working in the original addon version.

That said the original code had a few puzzles. A trid value was extracted from the database and never used, and it seemed to try and pass a set variable for the post type which may have been a problem.

After some fairly extensive testing and modifying I have now basically fixed this - though my php skills are rather poor so it's probably not the most elegant of solutions.

As I suspected there were several problems in the language assignment.

Forgive my ignorance of some php structures butif($feed = $item->get_feed()){
never made any sense to me. I assume it is supposed to check for the existence of $feed before proceeding but $feed is never defined. (Some sort of shortcode syntax?)
Anyway setting $feed = $item->get_feed(); makes it able to pull the language when asked.

Additionally I didn't really understand the table query for the language code

There is no tag column in that table - I assume the comparison was intended to be with the default_locale column, and even then the feed language is en-US whilst the table value is en_US - hence a quick hypen/underscore replacement.

The pastebin code also has my routine in place to write a matched trid across imports with a common WPML_# tag. This tag is generated at the feed end. As a result those translations are tied back together.

Hope the code helps and you can use it to make a tidier version for inclusion.

Forgive my ignorance of some php structures but
if($feed = $item->get_feed()){
never made any sense to me. I assume it is supposed to check for the existence of $feed before proceeding but $feed is never defined. (Some sort of shortcode syntax?)
Anyway setting $feed = $item->get_feed(); makes it able to pull the language when asked.

This will get the SimplePie feed, so we can get the language from the feed. If no language found, so we will use the default :slight_smile:

And as I look it in your code, it seem that is old version, I have some rework to update the add-on again, and it work for me and my colleague @Jack Kitterhing.

If that still not work for you, I really want to see you database, just to check the WPML tables, because in frontend, WPML append many join query to the main Wordpress query, I want to manual run that query on your database to know the issue. Of course I will backup everything before do that.

Can you please send in:

- Mark to my attention - ATTN: Hoang Ngo
- Link back to this thread
- Include admin/network access
- Include cPanel (I will need to look at the DB so need PHPMyAdmin or similar)
- Include FTP
- Include any relevant URLS for your site

On the contact form, select "I have a different question", this ensures it comes through and gets assigned to me.

I thought I'd mentioned it before but I can't see it with a quick skim but the version of WPML used is not the latest one. Specifically it is 2.6.4.1. Again this was the installed version on the WordPress sites I inherited to maintain and as everything had been working correctly I didn't want to rock the boat by upgrading everything and hoping nothing broke.

Yes I modified an old file. Specifically it is the one that was linked to in the first reply to this thread. That said it is identical to the version you include with Autoblog with the exception of the error logging and language cache update. I forgot which one I was editing to be honest and have no idea if these functions still serve a purpose. Though I expect they don't.

Looking at your new code it looks like it should probably work now with a language being passed, though not for me because of the missing tag column in the languages table.

What I don't get though is why the use of wpml_add_translatable_content which requires including the API. Looking around I've seen it used when generating entirely new content, such as autocreating translations but in this case the translatable content has already been made by WPML's hook on wp_insert_post which runs the add_translate function.

To me set_element_language_details seems to achieve the same goals without any need to query the database for the trid or load that API.

(I know i query the database for the trid but that's for a separate purpose not simple insertion)

How do you rate me?

Thank you for rating your experience!

We’re thrilled to hear you had a great experience with . Would you like to leave a comment about your experience?
Thanks for voting on your experience with , we’d love to get some feedback please.
Ohh no! We’re really sorry to hear you didn’t have a pleasant experience with , we’re always looking at how we can improve and would appreciate you provide some further feedback here please.
Type your feedback here

it's great that you had a positive one. Based on your experience in this ticket would you please be kind enough to rate us externally on: