Andrés Sanhueza

I had the same issue. I didn’t had a wp-edit-post dependence either, but I did had a similar line in a custom plugin I use:

wp_enqueue_script('wd-editor', plugin_dir_url( __FILE__ ) . 'js/editor.js', array( 'wp-blocks', 'wp-dom' ), filemtime( get_stylesheet_directory() . 'js/editor.js' ), true );

I changed to something similar to what @azragh said:

wp_enqueue_script( 'theme-blocks', plugin_dir_url( __FILE__ ) .'js/blocks.js', array( 'wp-blocks', 'wp-dom-ready' ) );

And now it works with the Lazy Blocks plugin activated. I’m not sure what’s the exact issue.

Edit: it didn’t work actually, but indeed the problem is related to Lazy Blocks as the widgets only works when the plugin is deactivated.

• This reply was modified 3 years, 3 months ago by Andrés Sanhueza. Reason: typo
• This reply was modified 3 years, 3 months ago by Andrés Sanhueza.
• This reply was modified 3 years, 3 months ago by Andrés Sanhueza.
• This reply was modified 3 years, 3 months ago by Andrés Sanhueza.

Update: It’s ?Partially solved?: It has something to do with the Lazy Blocks plugin, yet I’m not sure what it is, but there’s a thread for it: https://www.ads-software.com/support/topic/plugin-preventing-adding-blocks-to-widget-area/

I disconnected and reconnected and it started working again. Thanks!

I used another code based on a snipped posted on Github, but still don’t work

add_filter('pods_field_pick_data_ajax_items', 'show_first_and_lastname_in_pick_field', 1, 6);

function show_first_and_lastname_in_pick_field($items, $name, $value, $field, $pod, $id){
        if ($name == "lugar_de_eventos") {
            foreach ( $items as $key => &$data ) {
                if( $data['id'] ){
                    $p = pods('lugar_de_eventos', $data['id']);
                    $namer = $p->field('name');
                            $city = $p->field('venue_city');
							$country = $p->field('venue_country');
                   $data['text']  = $namer . ' (' . $city . ', ' . $country  . ')';
					$data['name']  = $namer . ' (' . $city . ', ' . $country  . ')';
                }
            }
        }
        return $items;
    }

BTW:

• The pod that the relationship field calls is lugar_de_eventos
• The pod where the relationship field is located is eventos
• The relationship field itself is venue_rel. It has a list view.
• The lugar de eventos fields I want to display on the venue_rel field when showing on the eventos pods (or any other relationship field) are name, venue city and venue_country
• I’m posting the snippets on a custom plugin.

• This reply was modified 4 years, 4 months ago by Andrés Sanhueza.

I wish to display related post from various custom post types, but not all, including the “core” page post type, but I don’t know how to officially exclude it while including the rest (unlike “custom” post types, that are added to the related post scheme at will).

I’m working with the core “post” type.

I have tried above solutions, but the problem persists. I don’t see any pattern in the tags that work to the ones that don’t. Something worth of note is that I’m using the tag taxonomy to support two kinds of post types, but I still don’t get why it don’t work at times.

No, I was thinking about these: https://codex.www.ads-software.com/Post_Formats . Some kind of Tumblr-like taxonomy put in core a while ago. The permalink for the archives is /type/[format]/

It could also be related to the fact if one disable showing some kind of twitts, like replies or RT, but I’m not sure.

I noticed there where some hidden files of a previous hack in a plugin folder, I deleted it and the problem disappeared for about a week, but it started again twice. Only the second time I got to see an access log https://pastebin.com/TXKGagBj . It looks that at first the ‘hacker’ looks for old files that are supposed to contain hacks. As those are all deleted or never existed, then the hacker logs into the site and edit a theme file. I’m not entirely sure about what to do in that case. I have two plugins that limit login attemp after a few failed tries, so I guess the hack knew a password beforehand. The obvious thing is to change my user password, yet there are other users on the site I guess I must ask them for the same. But even with that, I don’t know which user the hack used or if it was something else more obscure that is not obvious by the log itself and could have involved the MySQL database. Is there any way to keep track of it?

For some reason, the logs of the server don’t say anything about those hacks and the modified date of the files changed don’t change either. I deleted a bunch of older files unrelated to WordPress and tested some security plugins with no luck.

I solved it by reading the Codex and some TinyMCE documentation. Something like this has to be added to a plugin or theme function:

function myformatTinyMCE($in)
{
 $in['inline_styles']=false;
 $in['extended_valid_elements']="b,i";
 return $in;
}
add_filter('tiny_mce_before_init', 'myformatTinyMCE' );

Summarizing stuff I have proposed elsewere:

—A better approach to post formats, like something that actually simplifies the UI with only the needed fields instead of letting the theme do calculations of how interpret it, as I explained better here: https://www.ads-software.com/extend/ideas/topic/a-better-approach-to-post-formats
—Add a ‘question’ post format. This is very nit-picky, yet I suggest it because post formats are a fixed thing by now and it’s actually used in some micro-blogging systems. I try to explain it better here (including replies) https://www.ads-software.com/extend/ideas/topic/add-a-question-post-format
—Consider upgrading the Blicki plugin.
—Consider upgrading the self-hosted VideoPress framework (I think is considered for the 3.2 release, but still).
—Convert the links feature into a custom post type. By now it looks like something like a plugin should do, so instead of removing it, it could be better make a post type to harmonize better with the rest of the system and maintaining all the current features.
—Allow the taxonomies to hold metadata. This by itself may solve a lot of problems that by now have to resort to proprietary workarounds.
—Fix a great bunch of bugs with the shortcode API that are still waiting in the trac.
—In general, instead of adding to many nitpicky stuff for each release that’s hardly extensible for the users, try to make the API even more flexible and trying to get an approach similar to CCK in Drupal. Drupal has the problem of having a ridiculous learning curve, but it actually much more flexible in terms of how can you play with fields, views and stuff. For example, you may allow to put some of the default metaboxes more than once in a custom post type (if that’s already possible, don’t worry), and give more flexibility to the options of the default metaboxes, even if they aren’t used in core by default (something like, allowing something like a “post thumbnail” metabox that can hold any kind of file from the library, not just images and maybe more than one per page).

That works, thanks.
Is there a way to reset the count in each post (like when more than one appear in a loop)?

It works but I don’t want to limit the attribute to a single shortcode. More like when do_shortcode is used in the content of an enclosing shortcode.