Forum Replies Created

Viewing 15 replies - 1 through 15 (of 32 total)
  • Thread Starter Deni

    (@dennis_f)

    Thank you!

    Thread Starter Deni

    (@dennis_f)

    Hi Andrew,

    Thank you so much for your reply!
    I actually need to show the status, so if the membership is expired, I would need to show status: expired, so since the pmpro_getMembershipLevelForUser function filters by “active” status, it won’t work for me in this case.
    I think I’ll just load the last created record for the user (with highest ID) – is there any edge case scenario when the last created record might not reflect the current membership status?
    Thank you!

    Totally agree – “Allow users to switch editors” should be set to “No” by default.

    I actually opened another ticket about this same issue, not realizing that this was already posted here:
    https://ww.wp.xz.cn/support/topic/classic-editor-plugin-encourages-using-block-editor-why/

    I just installed the 1.1 update, I went to the posts screen and the first option that I see when I hover the page title is “Block Editor”.

    If someone installs the Classic Editor plugin, it means that they don’t want to use the block editor. The option to switch between editors (Allow users to switch editors) should be disabled by default if one chooses to use the Classic Editor plugin.

    In the past several weeks, we’ve been instructing our users to install the Classic Editor plugin because with the current state of Gutenberg, there is no way to safely convert our elements to blocks. We had the peace of mind that the Classic Editor will help us keep the things in the way everything used to work.

    We’ve been relying on the Classic Editor plugin and now, all the Classic Editor plugin does, is encourage using the block editor as first option. The truth is that not every user is aware of the difference between Classic Editor and Block Editor and this option to switch between the editors can be confusing to many.

    If we, as developers, have decided to enable the Classic Editor plugin, it means that we don’t want our users to use the block editor as it is currently not ready and it could break their sites. What is the point to use the Classic Editor plugin if it by default encourages using the block editor? Are we now supposed to ask them to do the extra step and go and update their options to disable the editor switching?

    Please make the option to switch between editors disabled by default or at least make the classic_editor_plugin_settings filter work in themes. The classic_editor_plugin_settings filter runs upon the plugins_loaded action, which is before the theme is loaded and therefore, we cannot control this option from our themes.

    Thread Starter Deni

    (@dennis_f)

    Thank you!

    Hi Rick,

    The WordPress root directory is the folder on your WAMP setup that contains the WordPress files, it is not called “root” – you have probably set a custom name to it (such as “wordpress”) when you downloaded the main WordPress zip file, unzipped the folder and added it to your WAMP.
    So, you just need to navigate to the folder on your WAMP setup where you have installed WordPress, open this folder and you should see the wp-config-sample.php file in there.

    Hi there,

    The following snippet loads the related posts:

    $post_id = get_the_id();
    
    $args = array(
    	'posts_per_page' => 4,
    	'post__not_in' => array($post_id)
    );
    
    $cats = array();
    $post_cats = get_the_category( $post_id );
    if($post_cats){
    	foreach ($post_cats as $c) {
    		$cats[]=$c->term_id;
    	}
    }
    
    if(!empty($cats)){
    	$args['tax_query'] = array(
    		array(
    			'taxonomy' => 'category',
    			'field' => 'id',
    			'terms' => $cats,
    			'operator' => 'IN'
    		)
    	);
    }
    
    $loop = new WP_Query($args);

    Please note that if you use the code in the single.php file, you would have to prefix all of the variables, so that they don’t conflict with other global variables. Otherwise, if you use it in a function (like a filter) or in a partial template, you don’t need to prefix them.

    Hope this helps.

    Forum: Hacks
    In reply to: Change Tab Title Edit Mode

    Hi there,

    You can try adding the following code to the functions.php file of your child theme:

    function my_custom_edit_post_title($title){
    	global $pagenow;
    
    	if($pagenow == 'post.php' && isset($_GET['action']) && $_GET['action'] == 'edit'){
    		global $post;
    		$title = str_replace ( get_bloginfo('name'), $post->post_title, $title);
    	}
    	return $title;
    }
    add_filter( 'admin_title', 'my_custom_edit_post_title', 10, 2 );

    Hope this helps.

    Forum: Hacks
    In reply to: Database indexes
    Thread Starter Deni

    (@dennis_f)

    Hi there,

    Thank you for your reply.

    I’m working on a plugin that I’m planning to release here on ww.wp.xz.cn, so it’s not only for my site.
    A simple left join between the users and comments table is really slow with higher number of records, because of the lack of index on the user_id column in the comments table – I tested adding an index to that column on my site and it works really fast.
    So, I wanted to ask if adding an index to a default WordPress table would be something that is allowed to be performed in a plugin? I’ve been concerned that this might not be a good practice either.
    Many thanks

    Thread Starter Deni

    (@dennis_f)

    It turned out that the 3.9 Beta 2 version wasn’t installed correctly with the Beta Tester plugin. I have just reinstalled it manually and both this problem and the fatal PHP error don’t exist anymore.

    Thread Starter Deni

    (@dennis_f)

    It’s good to hear this 🙂

    Thread Starter Deni

    (@dennis_f)

    I can experience this with different themes, currently I have the TwentyTwelve theme activated and the only plugin activated is the Beta Tester plugin.
    I tried to trace the problem by comparing the WP 3.6 Beta 3 installation and another installation running WP 3.5.1

    In the WP 3.5.1 I found the img.mceWPmore class in the content.css file which displays the image:

    img.mceWPmore {
    	background: transparent url("img/more_bug.gif") no-repeat right top;
    }

    but I can’t see this class in the 3.6 Beta 3 content.css file.
    I opened the file directly from the file system to make sure that it is not a caching problem, also I can see that this class is missing in the WP trunk content.css file as well:
    http://core.svn.ww.wp.xz.cn/trunk/wp-includes/js/tinymce/themes/advanced/skins/wp_theme/content.css

    Thread Starter Deni

    (@dennis_f)

    Thank you for the reply!

    I can see that it is there now and it is loaded on all pages – both admin and fron-end pages, which is great as jQuery 1.9 removed many of the previously implemented functions and without the jQuery Migrate, it may result in many JavaScript errors and broken scripts.
    I really hope that it will be kept as it is now and loaded in the official release by default.

    Thread Starter Deni

    (@dennis_f)

    That’s great! Thank you so much!!! 🙂

    Thread Starter Deni

    (@dennis_f)

    Hi Andrew,

    Thank you for your replies – I really appreciate that you guys read our notes and consider what we say.

    I just wanted to say that I didn’t report this in the Beta releases, as the old Media window still existed then and for some reason I thought that it will stay there in the official release.

    But, it is likely to return for 3.5 RC3.

    It would be great if it returns, as it will be difficult for users to search the whole Media Library for a single image just to change its description, especially when they have hundreds and thousands of images.

    And I’m sorry to ask, but it didn’t really get clear to me from all the conversations – is the menu_order sorting going to be back in the “uploaded to this post” window or not?

    Thank you!

    Thread Starter Deni

    (@dennis_f)

    It seems that this issue:
    http://core.trac.ww.wp.xz.cn/ticket/22608
    is about how the gallery is displayed and not about having the default menu order functionality within all the post attachments.

    Anyway, I have already started working on my themes updates, for anyone interested, here is the solution that works best for me:
    – I perform just once getting all the pages that are from slideshow page templates (the ones that use the post attachments) and I insert the gallery shortcode in the beginning of their content. As these pages don’t display other content, it is safe for me to insert the gallery shortcode in there.
    – Now, when I load the images for the page, instead of using the get_children function to load the page attachments, I do a regular expression check by using the get_shortcode_regex() function to look for a gallery shortcode and load the images from the gallery.

    I know this is not the best coding solution, but I find this the best way for the users, so they don’t get very confused and so that I can make sure that their previous slideshows will be still working.

    WordPress core developers: next time, please make sure you don’t remove functionality that used to be working just like this – we love the new features you implement, but it is not good for both developers and users to delete existing functionality. Thank you!

Viewing 15 replies - 1 through 15 (of 32 total)