Support

Account

Home Forums Search Search Results for 'Accessible'

Search Results for 'Accessible'

reply

  • Hi @emanahan,

    Thanks for the post.

    Since the WYSIWYG editor already contains a color palette to choose font colors, it is best advised to make use of this functionality which is accessible from the toolbar.

  • Some more information to add which is missing in the answer above:
    This error only happens when you try to access all options at once using get_fields().

    Elliot meant that he can’t think of a quick and easy bug fix for this.

    However, there’s a workaround, where you don’t use get_fields(), but get_field() for every repeater. To still have them all accessible in one place, you can do something like this:

    
    // Put all repeater field names you have in your options fields in an array
    $options_repeater_names = array(
        'options_repeater_name_1',
        'options_repeater_name_2',
        'options_repeater_name_3',
    );
    
    $options_repeaters = array();
    
    // Loop through repeater field names and use get_field separately for each repeater field
    foreach ( $options_repeater_names as $field_name ) {
    	$options_repeaters[ $field_name ] = get_field( $field_name, 'options' );
    }
    
    // Now all the repeaters are accessible in $options_repeaters
    

    Good luck!

  • You’re probably not going to get this question answered on this forum. You should submit a new ticket http://support.advancedcustomfields.com/new-ticket/ or send an email to [email protected]. What I do know is that you can distribute ACF Pro in a premium plugin, it cannot be publicly accessible, and I do know that you cannot distribute your license key with it. Basically it would be your responsibility to update ACF and put updates of your theme to your users.

  • Hi @conradical

    I think you can create a custom post type of brands and inside that post type, you can add a repeater field of the Battery Types. This way you can set the URL slug, and it’s accessible as a post. On the Battery subpages, you can add a repeater with Post Object Field in it which is assigned for the Brands custom post type.

    I hope this makes sense.

  • The other massive issue with this, is that the old ACF data is seen by WP search functions.

    We had an ACF text area for staff listings on an old theme. We approached that content differently on the newest theme, but the search results now show old data in the results. Which has conflicts in between the old unaccessible ACF content and the new data.

  • Is this still a viable solution?

    I have added this to my functions file, and I can see it being loaded in the source, but it doesn’t seem to be taking effect. I can inspect the editor iframe and see it loaded inside the iframed html head, just like the admin-side editor, but still, the style doesn’t not seem to be

    The CSS file is open and accessible, but it still doesn’t appear to actually access the file.

  • That sounds cool, I’d like to see that. I just built a custom filtered search for our site and it was a beast to create enough posts of a custom type to test search against. I tried using LastPass’s custom form profile to auto fill but a lot of ACF’s great features like multi-select taxonomy and wyswyg are not accessible.

  • I’m hoping for a solution as well 🙁 Apparently BP doesn’t use CPTs, things like “groups” are just a BP component so they are not accessible by ACF out of the box. I’m hoping to find a solution that lets me add ACF fields as freely as I do everywhere else, and then possibly using a Gravity Form (or other custom form solution) during the registration process to populate those fields.

    Any other suggestions out there for making the connection?

  • Hi,

    first of all thank you for taking the time to answer my question. But I think, I did not explain myself well enough. The problem is not to get the file somewhere in the theme, after its saved, repeater or not. I need to hook into the moment when the file was uploaded, but BEFORE the data of the field set is stored into the database.

    In other words: I create a post, populate the acf fields and click the save post button. That’s where the mumbo jumbo should happen: Create and store a preview file, move the uploaded file to another location, where it is not accessible by the public, give the file path of the newly created preview mp3 as the new value to the former file upload field and finally save the post and all it’s meta data.

    Does that makes it somewhat clearer? Is there any hook, that I could make use of?

  • Hi @MrWebslinger

    Can you please elaborate on what is broken / accessible. ACF loads data in multiple places and it is hard to understand what has gone wrong where in the plugin.

    Please also check your console log for errors and attach images to help

  • We just recently added a Layout to one of our flexible field entries and it also broke our site. Most of the data isn’t accessible now from those layouts. I removed the layout I added and it didn’t resolve the problem. I restored the site from a backup, tried it again, and again, it broke the flexible fields. I think the fact that it re-ordered them, might have something to do with the issue because the couple layouts above the one I added are ok, it’s the existing layouts, now below the layout I added that are now gone, both Front end and Back End.

  • Sometimes that’s due to permalink caching. If you go to Settings > Permalinks and just hit “Save Changes” (don’t need to actually make any changes) it will flush the cache and the URLs should be accessible.

  • Hopefully I have this right, I’m assuming you have these people added on an options page.

    A better way to do this would be to have a Custom Post Type for adding the people and then use a relationship type of a field on the page editor where you want to allow them to be selected. If you’re not sure about adding CPTs check out Custom Post Type UI. You can set public to false in the post type so the posts are not accessible from the front end.

    Using and options page for your people you’re going to need to build a filter on the acf/load_field hook that gets all the values from the option pages and makes them choices for your checkbox field. I think displaying them on the front end would probably be a bit more complicated than the other way.

  • I can reproduce it currently with all my relationship fields in the admin – I have a custom post type called ‘Team Members’ and I am trying to relationship them to a page. When I got to a page, there’s no Team Members listed over on the right side.

    If I set up the relationship to allow for searching, I can find team members that way and add them.

    This is one relationship that had existed previously, and when a new one is created either for these two post types, or with another custom post type and page, the same thing happens.

    I can try to list exact steps and screenshots tomorrow if this is still confusing, but sadly my work computer is not accessible at the moment.

  • Hi guys

    Sorry about this issue. Yesterday, the ACF server ran into a whole bunch of issues and as a result, the .zip files were not publicly accessible.

    Apologize for this issue, but all is working now.

    Thanks
    E

  • Hello @elliot,

    Thank you for your quick reply. Deleting the ACF plugin files didn’t restore the site, but restoring the database plus the plugin files did restore the site.

    (It’s possible that solely restoring the database to its previous state would have allowed the site to be accessible again.)

    For your future reference, only ACF was updated from 4.1.8 to 4.1.8.1; WordPress and other plugins were all up-to-date before the ACF update.

    The site is up now, and we’ll determine if there was a conflict with another WordPress plugin, or if there’s code specific to the ACF 4.1.8.1 update that conflicted with the custom WordPress theme.

    Updating ACF from 4.1.8 to 4.1.8.1 on another website proved successful.

    Thanks again,
    Tevan

  • hi, I’m having a similar problem.

    I upgraded my WP install and my ACF plugin about a week ago. all of the previous custom field entries (of which there are MANY) are showing up fine on the live site, but the fields themselves have disappeared from the custom fields setup page and from the edit pages themselves – essentially it’s impossible to edit them.

    I downgraded back to the latest v3 and that didn’t solve anything. I upgraded to the newest v4, and that’s solved nothing either. is there any way to make this information accessible again somehow? at present on every edit page I see a list of all of the custom field sections, but clicking on them does nothing.

    please help ASAP… we rely on your plugin for a ton of content on the site!
    http://www.nacto.org

    thank you
    Leah

  • You mentioned when you loaded the .php file directly, does this mean this isn’t a part of a WordPress page? A stand-alone PHP page? I’m not sure whether ACF fields would be accessible through this or not, i’d guess not.

    You’d be better off adding a php callback function for your ajax in your functions.php file.

    Here’s a simple example of getting a field with AJAX:

    In your functions.php:

    
    add_action('wp_ajax_getdatefunction', 'getdate'); 
    add_action('wp_ajax_nopriv_getdatefunction', 'getdate'); 
    function getdate(){
    
       the_field('your_date_field');
    
       die();
    }
    

    In your JS file:

    
    $('button').click(function(){
    	$.ajax({
    		type: "POST", 
    		url:'/wp-admin/admin-ajax.php',
    		data: 'action=getdatefunction',
    		cache: true, 
    		success: function(results){
    			$('.your-date-container').html(results);
                            alert('The date is: '+results);
    		}
    	});
    });
    
  • Hi Darpan,

    It seems like you are trying to show a page-specific field on every page on the site, would that be right?

    The Options Page extension will help you here. This allows you to display a field on any page of the site, added into one site-wide options page. This is the opposite of adding fields to pages, that’ll only be accessible when the page is being shown; hence why when you added the post ID to your code, it worked.

Viewing 19 results - 76 through 94 (of 94 total)