Support

Account

Register Login

Forum Replies Created

  • @blueli The http(s):// is the protocol part of the URL; it tells the browser that it’s an external link. An href without a protocol is treated as an internal link.

    If you’re removing the protocol for display reasons, you should save that to a separate variable instead.

    Also, if you want to remove trailing slashes, there is a native WP function called untrailingslashit() or trailingslashit() for the opposite effect.

    Good luck!

  • If you use widgets a lot, consider checking out http://acfwidgets.com

    Might speed up your workflow some!

    Cheers!

  • @huwrowlands if you make widgets a lot, check out http://acfwidgets.com

    Could speed up your workflow quite a bit.

    Cheers!

  • If you make a lot of widgets, check out http://acfwidgets.com

    Cheers!

  • @elliot

    Any idea when the next version will be released? 😉

    Just curious how long I’ll have to tell clients to wait before they update.

    Thanks for the awesome plugin!

  • Frikken sweet! I updated the gist I sent in the email, so hopefully he hasn’t read it yet 🙂

    Thanks for all the hard work @strommerm! You deserve a trophy or something! Or perhaps just a pint 😛

  • Very nice! Can I ask what you changed/added?

    I sent an email to Elliot regarding our efforts and it would be good to document all the changes so he can review them before implementing a bug fix patch.

  • I made a gist in case anyone comes along later and needs to copy our code until Elliot can implement an official fix.

    https://gist.github.com/Daronspence/9179023c8e956e99974e

    Note to regular users out there, you will need to re-compile input.min.js from input.js to take advantage of this fix without enabling debugging. input.js is not loaded by default unless script debugging is enabled with the flag outlined in acf.php. To enable script debugging, you can add define('SCRIPT_DEBUG' , true); to the top of acf.php in the root of the plugin folder.

  • So this definitely isn’t working as intended.

    Uncomment the debugger for the change method (line 2267).

    If you want to see the debug tool in action, click around on the map and watch the console.

    Now follow these steps:

    1. Choose a very generic location. A large city works well.
    2. Update the post and reload.
    3. Click on the address. Since you used a generic city with lots of locations, a drop down should appear with other choices. If the drop down doesn’t appear, try pressing on the down arrow key.
    4. If you’re watching your console, you will notice there isn’t a change triggered by the debug tool, even though you chose a different location.

    If you type a location it works as well as clicking the map. Why doesn’t it work for switching a location without typing?

    I know this is probably an extreme fringe case, but I feel like the answer is so simple but I can’t figure it out!

  • @strommerm can you link to a gist of your input.js file?

  • Awesome! While this is certainly an improvement, I just uncovered one more tiny-ish bug.

    With the snippet above being used instead of the old change code, if you have a pre-populated field and click on the address and change it to a new location from the drop-down, it does not trigger page reload warning, although it should. The “change” function is being called, so why is there no message?

    Personally, I’m the type of person to always hit the update button but sometimes people won’t and we should account for that.

    I’ve made a short video showing the problem. If you watch my dev tools, every time the window moves, a “Change” is triggered in the console (I added it). However, it only shows the message for changes that occur by clicking the map/marker.

    You will notice that the map also triggers 2 change console logs on load.

    https://www.youtube.com/watch?v=OKh43wBJkC8


    @strommerm

  • jk. tagging myself to see what happens. See http://support.advancedcustomfields.com/forums/topic/google-maps-js-alert/ for more info on progress.


    @daron

  • Great news! We have progress! I took a stab at delving into the ACF core JS files and I think I have found the problem.

    The issue lies within the input.js that spits out all the javascript for ACF to function. I suspect the same code is within google-map.js but I didn’t want to screw around with enqueueing it and de-registering the rest of them.

    I started by commenting out all the JS regarding Gmaps, and slowly uncommenting it out to see where the weird reload was coming from. This narrowed it down to this function call.

    Around line 4105, you will find the acf/setup_fields function. Here is where the problem lies. 

    	/*
	*  acf/setup_fields
	*
	*  run init function on all elements for this field
	*
	*  @type	event
	*  @date	20/07/13
	*
	*  @param	{object}	e		event object
	*  @param	{object}	el		DOM object which may contain new ACF elements
	*  @return	N/A
	*/
	
	acf.add_action('ready append', function( $el ){
		
		//vars
		var $fields = acf.get_fields({ type : 'google_map'}, $el);
		
		
		// validate
		if( !$fields.exists() )
		{
			return;
		}
		
		
		// validate google
		if( typeof google === 'undefined' )
		{
			$.getScript('https://www.google.com/jsapi', function(){
			
			    google.load('maps', '3', { other_params: 'sensor=false&libraries=places', callback: function(){
			    
			        $fields.each(function(){
					
						acf.fields.google_map.set({ $el : $(this).find('.acf-google-map') }).init();
						
					});
			        
			    }});
			});
			
		}
		else
		{
			$fields.each(function(){
				
				acf.fields.google_map.set({ $el : $(this).find('.acf-google-map') }).init();
				
			});
			
		}
		
		
	});

    The variable and the first statement are harmless. The if statement just checks to see if any google map fields exist. The issue is further narrowed to the “Validate Google” part of the function. If you comment out that whole if/else statement, the field will not load, however, no warning will be triggered.

    I’m struggling to see how the else statement fits into the picture as well. At first I thought it was for rendering fields after the initial first map, but adding console comments show that the if part of the function is called for each map field regardless of other maps on the page.

    If you comment out the if part of the function, and just leave the else (removing the “else” and curly brackets so it triggers correctly), a google is undefined error is thrown and the map doesn’t load. However, there is no warning when navigating away.

    I feel like I’m rambling now, but the issue lies within the if statement. I have a feeling that this is because something in the pages <form> element is being altered by the rendering of the map, triggered from this location. This triggers the warning message when trying to navigate away from the page.

    I’ve examined the input.js file from v4 (current on repo) and there doesn’t seem to be a lot of differences. There was the call in v4 to a function called is_clone_field but adding that to v5 returned undefined.

    So this is where my knowledge ends. I also feel like I may be rambling 🙂

    I’m tagging a couple people so hopefully this can get resolved! It’s a very strange error but it definitely needs to be addressed. One of the great things about ACF is the awesome user interface as well as the well thought out UX. This bug is a game-breaker on that front though. Clients shouldn’t feel like all their work is lost every time they want to navigate away from one of these pages. It’s a false sense of unease that shouldn’t be there.

    Hope this helps!


    @fatbeehive     @Elliot Condon

    @bobz     @aditron @strommerm

  • Ah, the address! That’s what it is! I never noticed that before. That’s definitely something to look at more closely.

  • @strommerm can you try the plugin (a fresh download from this site) on a fresh install of WordPress?

    If the problem still persists there, let us know.

  • Is $qualite a regular array or an associative array?

    One idea would to be to store the value of each $qualite in a variable and check the new one against it before outputting it. Example: 

    $qualite = get_field( 'qualite', $modele->ID);
if( $qualite ):
$unique = '';
    foreach( $qualite as $qualite ): 
        if ( $unique != $qualite ) :
            echo '<dd class="filtr" data-filter=".'.  $qualite->ID . '">'.get_the_title( $qualite->ID ) .'</dd>';
        $unique = $qualite;
        else : endif;

    endforeach;
endif;

  • The widget should have the same slug (name) on both your dev site and in your new plugin.

    Here is some test generated code I exported. 

    if( function_exists('register_field_group') ):

register_field_group(array (
	'key' => 'group_5421d12d3b08c',
	'title' => 'User Registration',
	'fields' => array (
		array (
			'key' => 'field_5421d133e4826',
			'label' => 'File Upload',
			'name' => 'file_upload',
			'prefix' => '',
			'type' => 'file',
			'instructions' => 'Upload a file',
			'required' => 1,
			'conditional_logic' => 0,
			'return_format' => 'array',
			'library' => 'uploadedTo',
		),
	),
	'location' => array (
		array (
			array (
				'param' => 'widget',
				'operator' => '==',
				'value' => 'recent-comments',
			),
		),
	),
	'menu_order' => 0,
	'position' => 'normal',
	'style' => 'default',
	'label_placement' => 'top',
	'instruction_placement' => 'label',
	'hide_on_screen' => '',
));

endif;

    As you can see, this add a “File Upload” to the “recent-comments” widget. recent-comments is the slug associated with that widget. This location value must match the widget you are trying to target. Make sure you are assigning a slug when you generate the widget. See the codex info on creating widgets for more info.

  • Have you tried re-installing the plugin?

  • 5.0.9 update seems to have resolved this issue. Definitely gonna keep an eye on it though for a little while.

  • Just saw the 5.0.9 update. Installed, and the issue seems to be resolved. I’ll definitely be keeping an eye on though.

    If you happen to see this, thanks Elliot!

  • bump…

  • I am also having this problem. Not sure if it was v5 or v5.0.8

  • ACF stores field groups in the wp_posts table now. So you can use the post ID to check if it exists, or any other valid way to look for a post.

  • @UnionDesign, not sure if you’re still using ACF, but at least with the current version of ACF5 PRO, I have working Repeater Fields in Live-Edit. I am using some custom code to grab all the fields in a group however, so if vanilla isn’t working out for you (or anyone else who may find this) then you can check out the gist at https://gist.github.com/Daronspence/4ec625d1e371543dfa93

    Hope this helps!

  • Check out the acf_form(); function in the documentation. You can use that display forms on the front end. Couple this with some “if logged in” type statements and reference user IDs and you’re golden.

Viewing 25 posts - 1 through 25 (of 28 total)
1 2