Support

Account

Register Login

Forum Replies Created

  • Hi @maijavilkina,

    I’m not definite about this but are you sure the user’s are not being created? I only ask because I think that when using the wp_create_user() function you need to pass it the plain text password, no need to create a hash. If I am right, the user is created but instead of ‘password’ being the password it is actually the has of that: ‘Juwufbfuahduhaf209r32’.

    Also, you might want to consider using wp_insert_user() you can pass the first name, last name and display name to that which means you don’t need to create and separately update the user 🙂

    I’m not sure either of these have anything to do with your issue, but the first one might 🙂 The user should still be created though!

    Daniel

  • Hi Enrico,

    I think I see what you mean 🙂 So you’re creating a repeated field which has these fields (just an example):

    1. Title
    2. Post Type
    3. Post Content

    When user’s save the field you would like to create posts based on the information the user has entered.

    If this is correct you could use the acf/save_post action. This runs once the values for the repeater are saved. You can then retrieve them using the usual method, you could do something like this:

    add_action( 'acf/save_post', 'my_custom_creator' );
function my_custom_creator( $post_id ) {
    if( have_rows('your_repeater') ):
        while ( have_rows('your_repeater') ) : the_row();
        
        $postdata = array(
            'post_title' => get_sub_field( 'title' ),
            'post_content' => get_sub_field( 'content' ),
            'post_type' => get_sub_field( 'post_type' );
        );

        $new_post_id = wp_insert_post( $postdata );
 
        endwhile;
    }
}

    Do be careful though as this will create a new post each time you save the fields. You can either delete the post where the options are right after creating the new post, or you can save the ID’s of the newly created post and make sure they are not created, only updated if the options are saved again.

    Hope I could help,

    Daniel

  • Hi Elliot,

    It was no problem at all! We can of course fix this on our end by adding some code just before we output the meta but it would be nice if the ACF core took care of it.

    As a quick aside, I sent you a screencast about translation stuff a few days ago. On our end this is much more pressing, did you have some time to take a look at it? I think we found a better solution to translate user input 🙂 We actually have a solution, not just a problem 😉

    Daniel

  • Hi Elliot,

    I had a look and I think this is still a bug, I’ve created a hand screencast to explain. Sorry for the weird resolution 🙂

    http://cl.ly/1e23203G2N1e

    Daniel

  • Hi Elliot,

    This is definitely a possibility! I will investigate and get back to you here with an answer,

    Daniel

  • Hi Elliot,

    Thanks so much for looking into it! For the second issue, it would be great if I could choose a text domain by defining a constant for two reasons.

    The main reason would be to make it blend into the theme more. We’re making premium themes and having two textdomains: “theme-frontend” and “theme-backend” is super obvious while “acf” would be a bit of a mystery without documentation. We can of course provide the documentation so it’s not a huge issue.

    A smaller issue: after adding 20 or so fields we have 420-ish translatable strings, I am guessing that about 50 of these are our fields. If we want to provide translations for our fields we’d need to wade through the 420 instead of just going down a list of 50 or so. This is a minor considerations since we can do this on the PHP side, but it could be of some help.

    Again, this second issue is just me being more of a control freak than needed, the translatable PHP strings would solve all our actually important issues 🙂

    Thanks again!

    Daniel

  • Hi Elliot,

    That’s fine as well, it’s not a matter of not being able to include, it’s more an issue of future-proofing things. If the check is contained within the addon then there’s no chance of getting tangled up in someone else’s sloppy coding 🙂

    On our end we’re fine, as you said, checking for the class will do it 🙂

    Thanks,

    Daniel

  • Hi Elliot,

    I may not have been clear on this one. The issue is not with the core plugin, it’s with the addons, specifically the gallery and the options page.

    If you only include the base plugin all is well because it’s one big class and before the class you’ve added this check:

    if( !class_exists('acf') ):

    If I want to include the repeater field addon all is well again because I include the acf-repeater.php file which has this check: 

    if( !function_exists('acf_register_repeater_field') ):

    However, the gallery and the options page addon does not have this check so it can not be included with a simple include.

    I hope that makes it a bit clearer, let me know if I’m just being thick 🙂

    Daniel

  • No worries, thanks for the fix!

    Daniel

  • Hi Elliot,

    I think the conflict is in your script, perhaps they changed something with Iris in the last WordPress update. If you remove line 1203 from input.js $input.trigger('change'); then the color picker works as expected: I don’t know if this has any impact on anything else, but it may help you look further.

    event.returnValue is only used in wp-auth-check.js and jQuery itself so I don’t think this is a related issue.

    Daniel

  • Yay, I am not alone! Elliot, if you need any help with this let me know. I’ve had this issue occur when I changed the name of an HTML element and forgot to update the drag event in the colorpicker 🙂 Judging from the quality of your code I’m guessing you don’t need my help 🙂

    Daniel

  • Hi Elliot,

    Thanks so much for your help, I’ll just grab it from Github then 🙂

    Thanks again, top notch product and top notch support!

    Daniel

  • Hi Elliot,

    Thanks for that, I’ll try and dig into the source code as well a bit. I dont think I did anything special to create my fields. The documentation does say that get_fields will only return fields which do not start with an underscore, but as the key IS returned I assume the value should be as well.

    The odd issue is that everything works perfectly except this one function. I will try and make time to troubleshoot this myself, I’ll report back if I find anything.

    Thanks for the help!

    Daniel

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