Possible API problem

[Ter747474]

I have kept my eye on this new translation update process, but without comprehension of inner workings of API I really can't pinpoint the problem. Here's what I have noticed and the steps that I have taken. Currently I'm working on three sites. Two of them are running WP 4.9.12 + Avada 6.1.1 and one site is under maintenance using only barebone demo content with WP 5.2.4. + Avada 6.1.1. I always do my theme updates via FTP, and transitions from 5.9 to 6.0 to 6.1 went smoothly, and during those updates WP prompted me about new Avada translations as it should. (edit. all the sites are located on the same webhost account)

The interesting part happens (or actually does not happen) between theme updates. Since I have been working on the translations for the past few weeks, and I know when to expect an update, I have noticed that I do not receive any translation updates or notifications of possible updates. And yes, I have enabled the update option in 6.1 and all patches are applied. The only way I can make the update notification to appear is to first delete the old .po and .mo files via FTP. Then the update prompt appears instantly.

This is really not a problem for me since I prefer to do all my updates manually, but there might be some underlying issue.

[aristath]

@Ter747474 we wanted to avoid issues with the languages updating API, so we added a few extra checks in Avada, Fusion-Builder and Fusion-Core.

The update process goes something like this:

1. Get the JSON for Avada/fusion-builder/fusion-core from this repository.
2. Check if the installed version of the product is the same as the version referenced in the language file inside the JSON. In this repository we only keep translation files for the latest version, so if the installed Avada version is 6.1 and the translation files are for v6.1.1, then the language updates won't trigger.
3. We realize that a lot of our users like to update their files manually. In order to avoid overwriting their translations, we check the timestamp of the local language files. If the language file on your site is newer than the language file on our github repository, then we assume that you're working on it and we don't show a language update.

This is really not a problem for me since I prefer to do all my updates manually

If you're editing your language files, then chances are their timestamp is newer than the files on this repo, so that's probably why updates don't get triggered on your site 👍

I realize it may seem a bit inconsistent, but it really was the safest method to handle things without messing up sites for people that translate things on a live server.

[Ter747474]

What I meant by working on translations was simply doing the translations for GitHub - translating, doing pull requests and you merging them. So there should not be a situation where my local language files would have a newer timestamp than on GitHub or JSON would not match.

But if everything works in the grand scheme of things it might also be some setting on my server which is causing this and I will investigate further. If I find the cause and solution I will post it here.

There is also another thing that I would like to bring to daylight. It might deserve an issue of its own, but since much can't be done about it anymore I might as well just point it out here. By looking at the older GitHub issues and pull requests and thinking about the translations I've done during the time when Avada's translations were handled with Transifex, I've noticed one thing.

If I look at e.g. issue 114, and some old pull requests that people have made down the line, complaining about totally wrong translations, these are not, in my opinion, errors made by translators or deliberate attempts to cause harm.

For example, I am 100 percent sure that at the time (years ago) when I wrote down the translation "Hupsista, sivua ei löytynyt!" it was not paired with a string "Page" which was brought up in pull request 125 of the Finnish po-file. My original translation was paired with text "Oops, This Page Could Not Be Found!". Examples like this keep popping up, and I've corrected them when ever I found them.

My guess is that some of the translations got mixed up at the time when Avada stopped using shortcodes and merged towards Fusion builder. Was it the 3.x to 4.0 or 4.x to 5.0. I can't remember? I've been with Avada since it had less than 50 000 users, so few years have passed.

[aristath]

I have similar suspicions, but no way to confirm exactly what happened or why. I have found the commit and it was back in 2015, but I don't know if it was a merge conflict, a translation sent by one of our community members via email or something completely different... Back in 2015 things were a lot different!

[Ter747474]

I'm closing this one for now. Like I said, if I find a solution for my original issue, I will post it here.

[Ter747474]

I have tried to figure out the update problem and found two possible reasons. If I'm right the first reason affects only a limited amount of people but the second reason delays updates for everyone. Please confirm if my findings are correct.

1. Does the update process need XMLRPC ? When one googles WP-security hardening, sooner or later one finds an advise which says to lock down XMLRPC. That's what I have done on few sites, and that probably affects the update process. This is more of a guess than a tested fact.

2. Number two is an actual finding, and I was able to make the update appear normally during my test on sites that don't have XMLRPC/other security hardnings. Have you noticed that the timestamps on every api.json are dragging one month behind? Is this intentional? The Avada 6.1.1 build was released at the end of October. Since there hasn't been much translation action the timestamps of most languages are showing the date 2019-09-30. Shouldn't that be 2019-10-30? Even the merge that you made for my pull request just the other day is showing a date 2019-10-18.

So I tested my findings with the Linux touch-command and changed the Avada-fi.po and .mo file modification dates to 2019-10-17 and uploaded them back to my server. Then it worked! I was prompted with an update request. The file modification dates in the language zip-file seems to be okay. So when the 6.1.1 update came and I installed it, the language files on my server had a modification date which was about a month ahead of the api.json timestamps. That's why I was never prompted with an update after you merged my pull requests.

Am I making any sense?

[aristath]

@Ter747474 you are making perfect sense, great debugging skills! Your analysis really helped, I found the issue and fixed it. The problem is that we use JS methods to calculate the dates, and in JavaScript the getUTCDate method we use to get the day starts from 1, but the getUTCMonth method we use to get the month starts from 0, something I didn't know. I pushed a fix, but didn't recompile the API because that would trigger an update for everyone on all languages. The next time there's an update to a language file (or the next time there's an Avada release - whichever comes first) all dates will be correct.

Thank you!

[aristath]

Oh, I forgot to address the XMLRPC question. No, the updates have nothing to do with XMLRPC, they use the native WP API. The only thing that would block the updates is if the server somehow blocks pings to github (highly unlikely, I don't think I've ever seen a server do that). The issue here was clearly the wrong number for the month 👍

[Ter747474]

I'm glad it worked out! I was so caught up yesterday in finding a more elaborate explanation to the problem that I failed to notice that I had turned the language update feature off again on my more secure sites. Once I realized that I was able to repeat my test successfully. So all is well.