Resolved
Reported for: WPML Multilingual CMS 3.3.6
Overview of the issue
When adding a link to a post or page, an ajax request is being sent in order to get all other posts that you can link to.
This request calls cause a fatal error as such:
Fatal error: Call to private method WPML_Language_Resolution::get_referrer_language_code() from context 'SitePress' in wp-content/plugins/sitepress-multilingual-cms/sitepress.class.php on line 2328
Workaround
The WPML 3.3.7 will contain the fix.
Meanwhile, to solve the issue in your current version, go to sitepress-multilingual-cms/classes/request-handling/class-wpml-language-resolution.php and then on line 92 change this code:
private function get_referrer_language_code()
to:
public function get_referrer_language_code()
Thanks!!!!!!!!!
You gust rock.
Will this be corrected in the next update, or will I need to change this after every future update?
Hi Justin,
This fix will be released in the next version of WPML, therefore you won’t need to reapply it on every update.
This workaround is only needed to solve the problem until the next update, where the fix will be applied for good.
Awesome. Worked like a charm. Thanks for providing this temporary workaround!
I think this is problematic enough for you to publish a quickfix, even as a minor version isn’t it ?
Hi JK,
We are about to close the development of WPML 3.3.7, which includes this fix, among others.
We are aiming to release this version very shortly.
Don’t get me wrong: I appreciate you publishing a fix, or even a quick solution in the meantime.
But to me the message given by that event is as follows: if I update to the latest version, and don’t test every nook and crany, then I can run into a situation when the official release of WPML will not correct this for months.
I mean that is a problem, in terms of reliability. I already test a copy of the WP instance of a staging server, and WPML of all plugins should be reliable. Even if you’ve got a bug, we are all human ok, but then by all means correct it as soon as possible.
Of course, you are correct to expect that products (especially paid ones) will have no bugs and no problems. This is our goal too and we put a great deal of effort towards this. Before every release of WPML, we run around 8 man-weeks of testing (it’s actually 2 weeks by 4 people). We also have a growing list of automated tests, for most parts of the plugins.
Still, problems sometimes slip through. You probably know that we use WPML on our own sites and problems that you get, we get too.
In the past, we attempted to release quick bug fixes for things like this. We learned, the hard way, that this habit wasn’t working out. In fixing one thing, we often caused something else. Since the entire test suite takes several weeks, it’s impossible to guarantee that a fix will not cause another problem.
So now, we prefer to document known issues in these errata pages and offer work-arounds. It would certainly be more convenient for everyone to receive a fully-tested bugfix version. However, if you got very frequent updates from us, solving one set of problems and introducing others, that wouldn’t be very convenient for you.
We’re not set on a solution and we can’t say that it’s ideal. When we find something that works better, we switch to it. You know that we’ve changed our policy about updates in the past and we are likely to do that in the future. Our only objective is to get you a better product, on faster cycles.
Does this make sense?
Amir, thanks for the answer.
Nobody expects you to deliver bug free software. It is impossible.
My point was, when bug is identified, there should be a quicker way to push the fix to the users. I understand the unit, integration, regression tests take time, but once again what is the consequence of that ?
A stable version of WPML with a known annoying bug without any quick fix for 4 months.
That’s the harsh reality of it.
I’m sure you are doing your best, your Plugin we go enjoy, and I sincerely hope that you can come to a better solution for those quickfixes.