Support

Account

Register Login

Forum Replies Created

  • So the issue was that this was being displayed in a vue app which, for some reason, caused the twitter widgets.js rendering to fail probably due to timing of sorts.

    I solved this by loading the script in my template according to https://developer.twitter.com/en/docs/twitter-for-websites/javascript-api/guides/set-up-twitter-for-websites and triggering the widget load on $nextTick in the callback.

    
window.twttr = (function(d, s, id) {
  var js, fjs = d.getElementsByTagName(s)[0],
    t = window.twttr || {};
  if (d.getElementById(id)) return t;
  js = d.createElement(s);
  js.id = id;
  js.src = "https://platform.twitter.com/widgets.js";
  fjs.parentNode.insertBefore(js, fjs);

  t._e = [];
  t.ready = function(f) {
    t._e.push(f);

    this.nextTick(() => twttr.widgets.load())   
  };

  return t;
}(document, "script", "twitter-wjs"));

  • Okay, I believe I solved it.

    The stupid apple autocapitalize caused the i to turn into capital I when I wrote my mysql query, and thus the serialized string that had been replaced in the DB was actually:

    a:1:{I:0;s:8:”Charcoal”;}

    Unbelievable, it’s actually insane that sequelpro allows autocapitalization/autosuggestion in a query anywhere in its interface.

    So in case anyone does need to do something like this, I believe the following process does indeed work:

    1. Alter the choice as you normally would by editing the custom field
    2. Perform the mysql query with the length of the strings for the serialization in mind in the s:X: part of the query

    UPDATE wp_postmeta
SET
	meta_value = REPLACE(meta_value,
		's:5:"Black"',
		's:8:"Charcoal"')
WHERE
	meta_key = 'colour'

  • Hi John,
    Thanks very much for your reponse.

    Regarding #2, I updated the field definition by editing the field, that should be okay correct? Or does it need to be updated elsewhere?

    Regarding #1, the serialized string is identical in both cases where I manually replaced via mysql, and in a post that was saved directly.

    If you simply run var_dump(unserialize('a:1:{i:0;s:8:"Charcoal";}')); you get the expected output:

    array(1) {
  [0]=>
  string(8) "Charcoal"
}

    So I’m just confused why updating the post_meta to something that’s identical as editing an item and saving it would produce different results unless I’m missing where this link is actually made in the db. I dumped the entire db, and searching for the term I only see it in post_meta so I can’t imagine it lingers elsewhere?

  • Hm, ok, I found a solution in completely turning of wptexturize sitewide with:

    add_filter( 'run_wptexturize', '__return_false' );

    which works but seems a bit heavy handed. In trying to find a way to target the WYSIWYG sub-field more precisely, I found this thread:

    https://support.advancedcustomfields.com/forums/topic/remove-wysiwyg-wptexturize-filter/

    Which suggests:

    remove_filter ('acf_the_content', 'wptexturize');

    Which isn’t working for me, I assume potentially because it is a repeater/subfield?

    I’m also actually accessing the repeater by simply getting the entire repeater as a variable and accessing the text directly via the array, so I’m even more confused that the text is being filtered. (get_sub_field or the_sub_field result in the same curly quotes, however)

  • I seriously have never had such a perplexing problem before, I feel like there isn’t a single working solution for translation and ACF right now, and every incremental version for any one of the three above mentioned plugins breaks everything.

    I know this is a long shot, but it would be an absolute dream if ACF just supported qtranslate-x out of the box, to eliminate one further point of failure. It’s just so incredibly hard to troubleshoot when there are three plugins involved.

  • I hate to drag a two year old topic to the surface, but I’m wondering the same thing? I’m trying to import a large CSV with some dates and am unable to get the dates to show up properly in my Datepicker fields.

    Currently, my dates are formatted in the CSV so j/m/Y, for example: 7/5/2003.

    How should they be formatted in the CSV to be imported properly so ACF can read and display these dates properly?

    Edit
    Ok, that didn’t take too long to figure out. I looked in the database when setting the fields correctly through the ACF form, and saw that the dates were stored like YYYYMMDD or 20030507. Converting the dates in my spreadsheet (Google Drive, via `Format -> Number -> More Formats -> More date and time Formats…) and everything’s working perfectly.

  • Ah the culprit turned out to be ACF q-translate. Issue is here: https://github.com/funkjedi/acf-qtranslate/issues/28

    Rolling back to version 1.7.5 fixes the problem.

  • I just noticed this problem as well. I ended up having to use the web inspector to expand the size of the field so I could click the ‘x’ to delete and be able to select a new image.

    ACF Pro 5.2.1
    WP 4.1.1

  • FYI the problem was caused by the plugin acf-qtranslate which, as of v1.4 is still causing this issue.

  • I hate to revive this thread but I have a site I need to take to production soon. If it helps anyone, in the meantime I used this plugin (github – Limit Upload) to limit the number of uploads which works for me as of WP 3.8.

    Now the issue for me is still enforcing the ‘Uploaded to this post’ selector in the media uploader. All the solutions I’ve found are javascript based and trigger after the uploader already starts loading the entire media library.

Viewing 10 posts - 1 through 10 (of 10 total)