piccart

ok, it seems to be working correctly indeed!

thanks very much for your help!

thanks for the super quick reply!

ok so just to be sure, the correct setup is to:

1. remove the facebook pixel and the GA script from my GTM setup
2. add the pixel ID and the GA Universal ID in your plugin

in that way my GTM will still work and fire all the ads and other tags, but then your plugin will handle FB Meta and the GA events. Is this correct?

marking this as resolved. Thanks again!

awesome!
many thanks for the help but also for this fantastic plugin!

p.s. I just realised I haven’t rated it yet, gonna do it now! ??

Hello Willem!

is there anything in particular that you want me to update/modify? are you experiencing any bug or malfunctioning?

In any case, I have been very busy with work in the last couple of years, but the plugin is not abandoned! I have updated it from time to time and I will surely check the compatibility with the latest major wordpress version and eventually fix glitches/bugs.

Unfortunately I haven’t had the time to rebuild the plugin and make an improved version as I promised in the past… I started a couple of times but then the months passed and in the end I didn’t like it and started from scratch… But I think soon or later I will finish it, just have faith! ??

in the meantime let me know if there are any problems or some feature that you really cannot live without. ??

another update.
for now I have implemented a workaround. I have set to display the icons in the bottom of the article as well as in our custom location.

at that point we had 2 icon set showing up on the page, but I have hidden the one in the bottom article with css.

That’s why now the page looks like it’s working. But it’s not.

The icons should be displayed in the custom location without the need to also have them in another default location.

and I still have those 2 errors in the console regarding missing sumotoken and sumopath

just a quick update.
the social icons are set to display inline into a custom container (which is on the left side of the article, you can see the heading “SHARE”.

so I’ve tried to also set a position for the icons in the Layout section, and after saving the settings the page was displaying both the icons in the custom container and in the chosen location.

though we don’t want to show the icons in 2 places, they should be only in the custom inline container, as they used to be…

p.s. in any case, the 2 errors mentioned in the first comment were still there when I set the layout-location and the icons showed up in the 2 spots..

• This reply was modified 5 years, 7 months ago by piccart.

What kind of post-type is that? is it a wordpress page or another custom post type?

the code pulls the thumbnail from the wordpress default “featured image”, you should have it in the bottom of the right-side boxes when you edit that page.

p.s. if it is a custom post type and doesn’t have the featured image box, ensure that when you register the post-type you add support for thumbnails in the args (and eventually other things you might already have there. like:
‘supports’ => array( ‘thumbnail’ )
‘supports’ => array( ‘editor’, thumbnail’, ‘etc…’ )

Hello,
thanks for your feedback and for the review! ??

what exactly is the problem with the thumbnails?
can you share a link of a page where I can see an example of the widget where you are having problems?

cheers!

ok I see, thanks!

though we really need those fields just for the import/migration, because then we will re-structure the entire website and use a different approach for the brands/sections.

in any case, excluding the relationship fields, I assume that if we switch to the premium version after the import, the other Types fields will still work even if they have been created/populated with the free version, is this correct?

p.s. the import plugin is adding a postmeta to the posts with the original drupal id, hence I can export a list of drupal ids from the db, filtering by brand, and then use that list in my code to populate the brand-relation field and also to add the posts to a category (which will be the new way to handle the sections).

many thanks for your help and precious information!

yes, indeed I’ve noticed that if I select something in the Brand dropdown and then save the post, it gets assigned a postmeta named:
_wpcf_belongs_brand_id

so I was thinking to code something which would set that metafield in bulk for different groups of posts.
so if I do something like

update_post_meta($post_id, '_wpcf_belongs_brand_id', $brand_id);

then I will see the brand selected in that dropdown within the post’s edit page. Am I correct?

fortunately the import-plugin is storing the original drupal ID as postmeta for each post, hence I can export a list of ids from the original site, and then code something which would update the brand metafield to the corresponding wp post_id.
Hacky but should do the job. ??

Hi Beda,
thanks for your detailed reply!

so, in the end we’ve purchased the premium Toolset Types but unfortunately it appears that the importer plugin is actually not supporting the premium post-reference fields and doesn’t even create those fields in backend (while with the free version of Types those fields where created in backend, and correctly populated with the list of posts from the other post-type).

That’s probably because, as you say, the post-reference fields are technically a different thing which is available only on the premium plugin, but the importer plugin probably assumes the structure and fields of the free Types in order to import Drupal’s Entity Reference Relations, and behind the scenes it probably uses something like the post-relationship workaround.

So at this point I guess (I’m still talking with them too about it) the problem could be that these fields are actually part of a bigger structure involving Drupal’s Organic Groups module. And the import is failing to setup the relations because it doesn’t understand the Organic Group structure…

in any case, many thanks for your help!

ok I see, thanks!

though even if I cannot create new relationship fields, it looks like the importer plugin has created the field correctly within Types, and in the post editor I can see the posts from the other post-type, and if I select them then they are correctly stored and remembered..

is the free version missing some core functionality to handle the relationship fields or is it just missing the backend UI to create/manage those fields?
I am asking because there might be some other reason why the importer is not populating those fields, and that won’t work even if I purchase your premium plugin…

thanks for your help!

perfect!

have fun, and maybe rate the plugin if you have 2 minutes. ??

thanks!

I don’t know why, but I don’t receive the notifications for this topic… sorry!

I’ve investigated a bit the situation and the problem is that when the code strips the shortcodes from the content, it will strip everything if it’s inside an open shortcode.

so by instance this:
[shortcode]Some content here that will be rendered in some custom way[/shortcode]

would result in nothing to show…

Visual page builders usually works printing out sets of shortcodes, with visual composer by instance you can switch to classic editor and you’ll see how the content actually look.

in any case, I’ve updated the plugin and changed the code so that if it’s not able to build a valid custom excerpt starting from the content, it will look for the actual wp excerpt.
That obviously would work only for post types which actually have the support for excerpt.

about this matter, be aware that you must fire the add_post_type_support() from within a function hooked to init. this is the complete and correct snippet that you need in your functions.php

function wpcodex_add_excerpt_support_for_pages() {
	add_post_type_support( 'page', 'excerpt' );
}
add_action( 'init', 'wpcodex_add_excerpt_support_for_pages' );

let me know if this will fix your problem.