• Resolved Chad Warner

    (@chad-warner)


    After updating to 2.8, we get the following error, and front end doesn’t load.

    Fatal error: Call to undefined function qtrans_getLanguage() in /path/public_html/wp-content/themes/theme/header.php on line 37

    Here’s the code from that section of header.php

    <?php
        global $post;
        $slug = get_post( $post )->post_name;
        if(is_front_page()) {
            $slug = "home";
        }
    
        $lang = qtrans_getLanguage();
    ?>

    We rolled back to 2.7.8, and it works fine. The changelog makes it look like you started on a wrapper for this function in 2.7.9, but didn’t finish. Should we stay on 2.7.8 until further notice?

Viewing 8 replies - 1 through 8 (of 8 total)
  • Plugin Author John Clause

    (@johnclause)

    How did you get version 2.7.9? It was never released as stable version. The version 2.8 does not use compatibility wrappers and function qtrans_getLanguage is not defined anywhere. I should remove 2.7.9 from svn, not sure if it will remove zip file from WP then.

    Thread Starter Chad Warner

    (@chad-warner)

    The problem occurred with 2.8. I rolled back to 2.7.8, which works fine. I only mentioned 2.7.9 because qtrans_getLanguage() is mentioned in the changelog for 2.7.9.

    The theme for this site is calling qtrans_getLanguage() in header.php, so the theme doesn’t work with 2.8. Do I need to change the theme to be compatible with 2.8, or what do you recommend?

    Plugin Author John Clause

    (@johnclause)

    2.8 and all, except broken and faulty uploaded 2.7.9, do not define qtrans_getLanguage(). You get it apparently from some other active plugin.
    I am puzzled, why it works for you in 2.7.8 and does not in 2.8 and, I assume, 2.9.1 either?

    Could you list all your active plugins? Which theme is this?

    It is dangerous to have another plugin with qtrans_getLanguage active. I would deactivate plugin which provides qtrans_getLanguage() for you, and created your own wrapper, like I tried to do in qtranslate_compatibility.php, somewhere in a file which you control and which would not get overridden on updates.

    Ah, it just occured to me that I can create an option to enable wrappers in the configuration page and not to include them by default, since they are normally not needed and may produce fatal errors in some configurations, which users cannot figure out, but an option, consciously turned on by a user, would probably solve all the problems.

    Let me know if you are able to put in your own wrapper and if it solves your problem, and I meanwhile try to put this option in.

    And I am still curious which plugin provides qtrans_getLanguage for you and appears working in 2.7.8. Please, let me know.

    Thanks a lot.

    Thread Starter Chad Warner

    (@chad-warner)

    It’s a custom theme that was created by another agency. The theme was created to use the original qTranslate plugin.

    We migrated to qTranslate-X 2.7.8 following your instructions, and had no problems. We first noticed this problem after updating qTranslate-X to 2.8. qTranslate (original) is still installed, but has remained deactivated since we installed qTranslate-X.

    qTranslate-X (activated) and qTranslate (deactivated) are the only language-related plugins installed.

    I’ll look into creating a wrapper when I’m able. In the meantime, please let me know if you have other suggestions.

    Plugin Author John Clause

    (@johnclause)

    There is now option “Compatibility Functions”, which brings some commonly used functions back to existence. However, the theme should not really use them, they should use the standard __() translation function instead in the places that need to be translated. Or they should provide a filter for those values, and then qTranslate-X can pick it up through “Custom Filters” option. Please, advise this to the theme developers.

    Thread Starter Chad Warner

    (@chad-warner)

    I enabled Compatibility Functions, and the site works properly. As a test, I then disabled Compatibility Functions, and replaced instances of qtrans_getLanguage with qtranxf_getLanguage in the theme files, and the site works properly.

    I believe replacing the function is the better long-term solution. Do you agree?

    Plugin Author John Clause

    (@johnclause)

    Hi @chad, In fact, in long term, theme should not make any direct calls to specific plugin functions, ideally they should use hooks etc. How exactly the $lang variable is in use later? If you cannot achieve what is needed through the hooks, let me know which hook you would need. In fact, the best, you could submit a pull request on GitHub with your idea of changes needed. It is just my two cents, – best regards and thanks a lot.

    Daniel

    (@ddumondgmailcom)

    This also works with the “qtrans_use” function: Change to: “qtranxf_use”

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘undefined function qtrans_getLanguage()’ is closed to new replies.