Support

Account

Register Login

Home › Forums › Search › Search Results for 'WPML'

Search Results for 'WPML'

reply

  • This reply has been marked as private.

  • I’m going to say this has something to do with translation settings. I have never seen this before, but I don’t use WPML, or whatever translation plugin you’re using. I would check there.

  • This could help: https://support.advancedcustomfields.com/forums/topic/wpml-get-field-from-options-from-specific-all-languages/#post-82538

    If not: if French is the default language, you could try modifying the example from this comment to work with page-level fields instead of global options, and rename it from get_global_option() to get_french_field() or something to that effect. If French isn’t the default language, you’d probably just need to modify the output of cl_acf_set_language().

  • +1. If @elliot is concerned about security of storing one’s license key in the filesystem, here are some other ideas:

    Idea 1: Check site authorization remotely–no license key required after the first time. I think this would probably go hand-in-hand with letting folks authorize a site from advancedcustomfields.com (not just de-authorize). WPML does it that way. This also seems to be how Admin Columns Pro does it, since I never need to re-authorize that one after copying from one site to another, as long as I’ve authorized it once on that domain. If I remember correctly, I think WooCommerce extensions (and maybe WC itself) also takes that approach.

    Idea 2: Allow us to generate & hard-code site-specific auth tokens instead of the master license key. I don’t know what security issues @elliot is concerned about specifically (maybe that people’s license keys will start showing up on Github?) so maybe this is worthless, but if it helps get ideas going, perhaps there could be something similar to ACF’s current method of combining the license key and domain together, but instead of base64 it uses some kind of hashing algorithm. (On the other hand, perhaps doing that securely would entail the same logic/development required by idea 1 without any additional benefit?)

  • ciao physalis

    i had the same issue just now, using do_action( 'wpml_switch_language', $language ); to change language in an ajax call. but acf options was always returning the ‘original’ language, that was loaded on the inital load.

    i now also added this right after the do_action call:
    add_filter('acf/settings/current_language', 'jnz_acf_set_language');

    and here is the corresponding function:

    function jnz_acf_set_language() {
    return apply_filters( 'wpml_current_language', null );
}

    this sets the acf language to the current language, but you could also simply return ‘en’ or whatever you prefer..

  • In fact when using WPML and option page, only the first field shows in the remaining languages when setting the field group as “Do not make ‘Field Groups’ translatable”.

  • Hey John, thanks for the link (and sorry for the delay in responding)! Is there a way via acf_get_setting to not only get the current or default language, but a language of choice?

    What I actually need and am working on is a foreach loop through all WPML languages and the retrieval of a specific field from the options for each of the languages, to be exact.

    Thank you in advance!

  • There is a topic here that may help you, it deals with the default language, but I think it can be used to set any language before getting a field https://support.advancedcustomfields.com/forums/topic/get-option-from-wpml-default-language/

  • I updated my WPML to the latest version as suggested by the ACF support team and I don’t have the error anymore.

    I used to have WPML Multilingual CMS 3.0.2 and since my subscription was expired I didn’t have a notification to update the plugin. Now I bought the 4.1.2 and everything is running smoothly.

  • I have this same issue, it’s the weirdest thing. I am running latest ACF and WPML as of Oct 2018. Was there any resolution besides telling it to reverse the order?

    Additionally, in the DB, it’s correct for all of the translations and matches the default language.

  • I’m experiencing the same issue. Choosing any (custom) taxonomy causes the fields to gain ‘acf-hidden’.

    No WPML, WP 4.9.8, ACF PRO 5.7.6.

  • I’m having the same problem, can’t activate WPML or i got a full crash.

  • So, the problem was that when a field is set with a visual editor, in WPML translation it was a default one-line field. If anyone has the same problem, you actually need to manually specify that the field should be “visual” in wpml-config.xml or in /wp-admin/admin.php?page=wpml-translation-management%2Fmenu%2Fsettings&sm=custom-xml-config

    Here’s my example for one field:

    
<wpml-config>
    <custom-fields>
        <custom-field action="translate" style="visual">YOURFIELDNAME</custom-field>
    </custom-fields>
</wpml-config>

  • My issue was resolved in 5.7.4. I believe it was related to the WPML + Taxonomy field bugfix noted in the release notes.

  • I’m sorry, my mistake.

    I had wrong filters for rule_match. Here’s the right code:

    
# Should we display this in a Page?
function acf_location_rules_match_wpml_page( $match, $rule, $options ) {
    var_dump([$match, $rule, $options]);
}
add_filter('acf/location/rule_match/wpml_page', 'acf_location_rules_match_wpml_page', 1, 3);

    It works now.
    Thanks!

  • I have the same problem. ACF pro 5.7.0 and previous version too. Website with WPML :

    I can pick the date and publish and it is saved correctly in the database…
    but when the edit (admin) page is reloaded while publishing, I get today’s date in the datepickers.
    So if I don’t pay attention and edit something else, the today’s date wipes out the date I had chosen the first time and my custom post start and end dates become today.

    Both start_date and end_date date fields currently have custom Ymd display format and 20180723 returnformat… because I was trying to debug a order by date query, and I thought there was a problem with american or french format : 31/12/2018 or 2018/12/31 or something like that. Values in database are 20181231. A forum post suggests increasing php.ini but not sure it’s relevant

  • I’d like to add something odd. Apparently after all this time, the images were added anyway, but not the the editor. Meaning they were somehow tied to the post object, but not the editor of it.

    Here is my final code.

    
global $sitepress;
$jargs = array( 
    'post_type' => 'ettevote',
    'posts_per_page' => -1,
    'post_status' => 'publish'
  );
  $allposts = array();
  $loop = new WP_Query( $jargs );
  while ( $loop->have_posts() ) : $loop->the_post();
        $wpid = get_the_ID();
        $engposts = get_fields($wpid);
        $orcontent = get_the_content();
  
        $wpml_element_type = apply_filters( 'wpml_element_type', 'ettevote' );
        $t_post_id = $sitepress->get_element_trid( $wpid, 'post_ettevote' );
        $translations = $sitepress->get_element_translations($t_post_id , 'post_ettevote', false, true);
        $original_post_language_info = apply_filters( 'wpml_element_language_details', null, $get_language_args );  
  
        $aid = get_the_author_meta('ID');
        $region_id = get_user_meta($aid, 'user_region', true); 
        $engthumbnailID = get_post_thumbnail_id($wpid);

        $postids = array();
      foreach($translations as $langs){
        array_push($postids, $wpid, $langs->element_id);
        if($langs->element_id){
            $my_post = array(
                'ID'           => $langs->element_id,
                'post_author' => $aid,
            );
        
                   set_post_thumbnail( $langs->element_id, $engthumbnailID );
                   $newpost_id = wp_update_post($my_post);
              
                    $set_language_args = array(
                        'element_id'    => $newpost_id,
                        'element_type'  => $wpml_element_type,
                        'trid'   => $t_post_id,
                        'language_code'   => $langs->language_code,
                        'source_language_code' => $original_post_language_info->language_code
                    );
                    do_action( 'wpml_set_element_language_details', $set_language_args );
          
                    //update ettevote fields
                    update_field('galerii', $engposts['galerii'], $langs->element_id); 
                    update_field('video', $engposts['video'], $langs->element_id);
                    update_field('country', $engposts['country'], $langs->element_id); 
                    update_field('city', $engposts['city'], $langs->element_id);
                    update_field('street', $engposts['street'], $langs->element_id); 
                    update_field('house', $engposts['house'], $langs->element_id); 
                    update_field('aadress', $engposts['aadress'], $langs->element_id);
        }
        else{
            continue;
        }
  
     
  endwhile;

    Maybe it helps someone in the future

  • No, if WMPL required different images for each language then you need to get the image information and insert the images to the media library and then use the new image IDs to update the ACF field. I don’t know the details you’d use for inserting an image for a specific language

    https://codex.wordpress.org/Function_Reference/media_handle_sideload

    Honestly, I don’t know beyond this point. The image IDs used need to match existing images for for the site/language, again, I don’t know how WPML works or what hurdles you need to jump to get this to work.

  • Another issue could be that the images don’t exist. If this is somehow using multisite and the values are being inserted into a different site then the image “POSTS” will not exist on the other site. But to be honest, I don’t know how WPML works.

  • Do you maybe have WPML installed ?

  • Not needed anymore, fixed with a WPML filter.

    function sd_change_language( $post_id ) {

    if ( 'post_type' == get_post_type( $post_id ) ) {
        $wpml_element_type           = apply_filters( 'wpml_element_type', 'post_type' );
        $get_language_args           = array( 'element_id' => $post_id, 'element_type' => 'post_type' );
        $original_post_language_info = apply_filters( 'wpml_element_language_details', null, $get_language_args );
        $set_language_args           = array(
            'element_id'           => $post_id,
            'element_type'         => $wpml_element_type,
            'trid'                 => $original_post_language_info->trid,
            'language_code'        => 'en', // language code to change it to
            'source_language_code' => null
        );

        do_action( 'wpml_set_element_language_details', $set_language_args );
    }
}
add_action( 'acf/save_post', 'sd_change_language', 1, 1 );

  • Any updates on this? The same just happend to me. The funny thing is that it’s happening in the local development copy of my website, but not in the production one. Same code, same plugins installed and activated. The only thing I’ve been doing recently in my local copy is managing field groups translations with WPML, but I can’t find what fired this bug exactly.

  • Yea, unfortunately WPML and ACF works nicely together ONLY if you don’t change “post_id” to something different than “options“, if you want to use something like “sidebars” for example, than translations for your options page stop working and updating options page on other language will overwrite other ones, or I assume it just updates it as not even trying to update for current language and separate from other ones 🙂

    I managed to fix this issue like this:

    // Get language suffix if not default language
function getTheLang(){
        if( function_exists('icl_get_languages')){
            global $sitepress;
            $default_lang = $sitepress->get_default_language();
            $lang = ICL_LANGUAGE_CODE;
            if($lang != $default_lang) return '_'.$lang;
        }
        return '';
}

// Add custom options page
acf_add_options_page(array(
            'page_title' => 'Sidebars composer',
            'menu_title' => 'Sidebars composer',
            'post_id' => 'sidebars' . getTheLang(),
            'parent_slug' => 'themes.php',
));

    To load a field, just add “getTheLang()” after your custom options “post_id”, like this for example:
    get_field( ‘sidebars’, ‘sidebars’ . getTheLang() );

    Nut much changed/hacked there, but this is works nicely 🙂

  • Thanks for the quick reply.

    No WPML. It’s single language.

    These are the active plugins:
    All In One WP Security
    Contact Form 7
    Duplicate Page
    Eigene Felder
    Envato Market
    Google Analytics Dashboard for WP (GADWP)
    Google XML Sitemaps
    Lightbulb Save and Close
    LightGallery Lightbox for Visual Composer
    ManageWP – Worker
    Simple History
    Slider Revolution
    Terra Atma Utilities
    TinyMCE Advanced
    UpdraftPlus – Backup/Restore
    WPBakery Page Builder

    I always save and then look at the FE.

  • Which plugins are in used? Is the plugin WPML activated?
    And for FE, do you look at the page in preview mode or after saving the changes?

Viewing 25 results - 76 through 100 (of 495 total)
1 2 3 4 5 … 18 19 20