Support

Account

Register Login

Forum Replies Created

  • So I just wrote this routine which is more “hands off” when you’re adding blocks. You just register the block w/ this class and it should add images to the Yoast sitemap.

    
 class YoastSEOSitemapImages {

    public static $instance;
    private $registered_blocks;
    private $current_block;

    public function __construct() {
        
        $this->registered_blocks = [];
    

        add_filter( 'wpseo_sitemap_urlimages', [ $this, 'add_sitemap_images'], 10, 2 );

    }

    public function register_block_images( $block_name = '', $field_name = '', $field_type = 'image' ) {

        $this->registered_blocks[$block_name] = [
            'block_name' => $block_name,
            'field_name' => $field_name,
            'field_type' => $field_type,
        ];
        

    }

    public function is_registered_block( $block_name ) {

        $has_block = false;

        foreach ( $this->registered_blocks as $registered_block ) {

            if( $registered_block['block_name'] == $block_name ) {
               
               

               $this->current_block = $registered_block;

               $has_block = true;

            } 
                      

        }

        return $has_block;

    }

    
    public function add_sitemap_images( $images, $post_id ) {

      

        $post = get_post( $post_id );
        $images_to_add = [];
         
        if ( has_blocks( $post ) ) {
            
            $blocks = parse_blocks( $post->post_content );
                        

            foreach( $blocks as $block ) {

                if ( $this->is_registered_block( $block['blockName'] ) ) {

                    //var_dump( $block );

                    switch ( $this->current_block['field_type'] ) { 

                        case 'gallery' :
                        
                            $image_ids = $block['attrs']['data'][$this->current_block['field_name']];
                        
                            foreach( $image_ids as $imid ) {
                                $images_to_add[] = $imid;
                            }

                        break;

                        case 'repeater' :
                            
                            foreach( $block['attrs']['data'] as $key => $value ) {

                               

                                if ( strpos( $key, $this->current_block['field_name'] ) !== false ) {

                                    $images_to_add[] = $value;

                                }
                            }

                        case 'image' :
                        default :

                            

                            //Now grab the data from the attrs
                            $images_to_add[] = $block['attrs']['data'][$this->current_block['field_name']];

                        break;
                    }

                }
      
            }

        }

        foreach ( $images_to_add as $img_to_add ) {

            $images[] = [
                'src' => wp_get_attachment_image_url( $img_to_add, 'large', false),
                'title' => get_the_title( $img_to_add ),
                'alt' => get_post_meta( $img_to_add, '_wp_attachment_image_alt', true )
            ];

        }

 

        return $images;

    }

    public static function get_instance() {

        if ( self::$instance == null ) {
            self::$instance = new self;
        }

        return self::$instance;

    }

 }

 function BricSitemapImages() {

    return YoastSEOSitemapImages::get_instance();

 }

BricSitemapImages();

    Then you could register the block that has an image field like this:

        BricSitemapImages()->register_block_images( 'acf/pretty-rows', 'image', 'repeater' );

  • This will only work if the media item was added to the library while on the particular post’s editor. I cooked up code to traverse the blocks, but it requires you to edit for each new block.

    Was wondering if anybody came across a “catch all” solution for adding images to the Yoast sitemap.

  • Same issue as madtownlems.

    Any progress on this?

  • Another way to accomplish this is to use the global variable $_SESSION to store whatever you want the notice to be. I wrote a PHP class and wrapper function to keep track of the notices so you don’t have to write to the database.

    <?php

/**
 *	Class to handle admin notices
 *
 */

class BricNotices {
	
	
	public function __construct() {
		
		//Start the session
		add_action( 'admin_init', [ $this, 'start_session' ] );
		
		add_action( 'admin_notices', [ $this, 'display_notices' ] );
		
	}
	
	
	
	
	
	
	
	
	
	/**
	 *		Add a notice
	 *
	 *
	 */
	
	
	public function add_notice( $text = '', $type = 'success' ) {
		
		
		
		$_SESSION['bric_notices'][] = [
			'type' => $type,
			'text' => $text,
		];
		
		
		
	}
		
	
	
	
	/**
	 *		Display the notices
	 *
	 *
	 */
	
	public function display_notices() {
		
		
		if ( !isset( $_SESSION['bric_notices'] ) &&  empty( $_SESSION['bric_notices'] ) ) {
			
			return;
			
		}
		
		
		if ( is_array( $_SESSION['bric_notices'] ) ) {
			
			foreach ( $_SESSION['bric_notices'] as $this->notice ) {
				
				$this->print_notice();
				
				
			}
		
				
			
		}
		
		
		
		//Delete the notices
		unset( $_SESSION[ 'bric_notices' ] );
		
	}
	
	
	
	
	
	
	private function print_notice() {
		
		
		//notice types = error, warning, success, info
		
		
		printf( '<div class="notice notice-%s is-dismissible"><p>%s</p></div>', $this->notice['type'], $this->notice['text'] );

				
		
	}
	
	
	
	
	
	
	/**
	 *		Enable the use of the global $_SESSION variable
	 *
	 *
	 *
	 */	
		
		
	public function start_session() {
		
		if ( !isset( $_SESSION )) {
			session_start();			
		}
		

			
	}
	
		
		
		
		
		
		
		
		
	
	
	
	
	
}

global $BricNotices;
$BricNotices = new BricNotices();

function add_bric_notice( $text = '', $type = 'success' ) {
	
	global $BricNotices;
		
	$BricNotices->add_notice( $text, $type );
	
}

  • Thanks, @herkules:

    I took what you did and amended slightly. This version offloads the domain replacing part to the MU Domain Mapping plugin:

    add_filter('wp_get_attachment_image_src', 'acf_multisite_url_fix', 10, 4);

function acf_multisite_url_fix($image, $attachment_id, $size, $icon){
	
	if( isset($image[0]) ){
				
		$image[0] = domain_mapping_post_content( $image[0] );
		
	}
	
	return $image;
}

  • UPDATE 1/28/16:
    I solved my issue. At the time I wrote that theme, I used the php spl_autoload_register() function to instantiate a class that uses ACF fields. Somewhere in the loading sequence, ACF no likey. Instead, I call that class w/ the WP action “init” and it’s good to go. Hope this helps somebody else!

    ———————
    ORIGINAL POST:

    I’m having a very similar issue, except the difference is I don’t have any tab fields, or any other fields with the same name as the multiple repeater fields that are throwing back the error.

    I’m using ACF 5.3.3.1 on a multisite environment. All the sites running the same theme have the issue. I have the exact same plugin running, and a different theme where these issues don’t exist.

    I know that sounds like it’s gotta be my theme! But I’ve looked for dup’s of the field name in my PHP registered fields AND the WP back-end registered fields.

    It looks like the problem is only happening with repeater fields that were registered via PHP. And the problem only has come up after an update of either WP and/or ACF 5. I didn’t realize it until after both those have been upgraded.

    What I’ve tried:
    -Recreate the fields and update the PHP code to register them. Creating them with the same name didn’t fix it. If I renamed the repeater field, it worked.
    -Comment out PHP registered fields and use same fields names in backend field creation tool. Same issue.

    These fields are also displaying on options pages. That is where the issue seems to be occurring. Not sure if this is related.

    These are the exact errors I’m getting:
    Warning: Illegal string offset ‘acfcloneindex’ in /home/creare/webapps/creare_websites_wpms/wp-content/plugins/advanced-custom-fields-pro/pro/fields/repeater.php on line 161

    Warning: Invalid argument supplied for foreach() in /home/creare/webapps/creare_websites_wpms/wp-content/plugins/advanced-custom-fields-pro/pro/fields/repeater.php on line 292

    I guess I’m asking, what else should I look for?

    Thanks in advance.

    Running WP 4.4.1

  • Update: I made sure to include the local JSON folder in my theme, deleted the repeater field, and then re-created it. Now it is saving content!

  • Actually, this issue is for any field type in a repeater…not just oEmbed. I read the thread regarding the fix that 5.1.2 brings, but I’m still having the problem. I downgraded to 5.0.2 and this issue still occurs…

  • I’m also experiencing the same issue. I’ve put an oEmbed field inside a Repeater Field, and each time I go to update the content on a page, the repeater/oEmbed’s content disappears. The oEmbed field works as a standalone on the same page.

    I’m running ACF v5.1.2.

    Thanks!

  • Hi @elliot:
    I’ve encountered a similar problem and have done some digging to try and get to the bottom of it. I tried the fix you mentioned above (got the new code from github: https://github.com/elliotcondon/acf/commit/df4386fa71f8392aaa6b1ac4aff3e3974b68a782) and it didn’t work.

    When the user type “subscriber” is logged in, they can see the custom fields that are assigned to “User = All”.

    However, both a “contributor” and an “author” cannot see these fields. The next step up, “Editor” and, of course, “Admin” can.

    I messed around with the capabilities assigned to the various roles. And when I add “edit_posts” as a capability to “subscriber” it breaks. I haven’t figured out what other capabilities “counter balance” the issue to where an Editor is able to see the custom fields in their profile.

    I even edited “everything_fields.php” to try and see if moving the placement of the custom fields helps. I changed line 424 to echo "$('#createuser > table.form-table:first > tbody').append( html );";. The same issue manifested.

    Thought that this may help to further address the issue. Of course I’m trying to achieve every user type to see the custom fields assigned to the post type = user.

    Deep thanks for the hard work on this family of plugins. I use almost all of them now on a daily basis. They rock!

    -Nic

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