Juan

Aha!!! That’s why I had so much troubles trying to run wp-cron.php through php-cli (and the reason I found wp-cron control trying to find a solution).

Thank you very much.

Sorry, I’m still confused.

One option use php-cli and the other a web-get command, I knew taht. But they don’t execute the same sript. One execute the script wp-cron.php from the core of WordPress, the other executes the wp-cron-control.php script packaged with the plugin.

Can you elaborate the answer and explain why? I’m confused why each option executes a different PHP script. I wouuld like to understand it.

I can confirm it. It works perfectly again.

Shortcodes like [shortcode=XXX] seems to be back. Can you confirm it?

See -> https://core.trac.www.ads-software.com/ticket/34939

I think the opposite, you don’t understand what we are talking about. Even if you understood it and I didn’t, you should never recommend to modify a core file; never. You think carefully before doing such recommendation. Even worst if there is a way to get the desire result without doing it.

Anyway, having several point of views is always good. Who knows when someone with a different opinion can teach you something.

You are wrong Aj_rangoli, the filter is not used to fix the core. The filter is used to modify the title generated by the core. I hope you see the difference.

And yes, if you want to modify what the core generates, you have to use a filter or an action. Always. Never modify core files directly.

Ajesh_rangoli never recommend to modify core files. It is very bad practice and when you update WordPress you can lose the changes. You should use the acstions and filters that WordPress provides.

In the case of the document title, since WordPress 4.4 you can use these filters:

1. pre_get_document_title
2. document_title_parts
3. document_title_separator

To set the title of home static page like “Sitename – tagline” you could use, for example, this code:

add_filter( 'pre_get_document_title', 'my_document_title_filter' );
    function my_document_title_filter( $title ) {
        if( is_front_page() && ! is_home() ){
            // Add the blog name
	    $title = get_bloginfo( 'name' );
	    // Add the blog description for the home/front page.
	    $site_description = get_bloginfo( 'description', 'display' );
	    if ( $site_description ) {
                $title .= "  – " . $site_description;
            }
        }
        return $title;
    }

I’m really sorry that you don’t understand what I mean. The problem is not the users (webmasters) of your plugin, the problem is the users of the forum who can not use BBCode.

If you say that the toolbar of the pro version has not this issue is because you have not understood what I’m talking about.

I’ve dropped your plugin from my website. As I said, I prefer to say to my users that BBCode is not supported than saying to them that they need to learn “another” BBCode syntax only for my forum.

I don’t think it is easy. I just think what it is obvious for me. If the syntax of BBCode, which is quite standard acrross the web, doesn’t work, it is not BBCode.

In my forums (more tahn 6k users) I see everyday messages with true BBCode syntax that I have to edit to convert to WordPress syntax. It is really annoying, not only for me, but also and more importanttly for users. I’m pretty sure that you understand what I mean.

Maybe handling BBCodes by the plugin itself is not the best solution, but you and we need to think carefully about this issue. I think it is a serious one.

In my opinion, if this issue is not fixed, it is better to drop BBCode support from the forum. The users will understand that BBCode is not supported. But they don’t understand well that BBCode is supported but they get a mess in they use it in my forum because they need to learn a different BBCode syntax for my forum and not for any other forum on the web. It is very frustrating for them and I, like any other webmaster, want to care about my users experience.

What do you think? Any other opinion apart of keeping it as it is?

Imaging that someone hire you to program in PHP. When you start the job nothing work. Then the boss says to you: sorry I didn’t tell you, in my company PHP is written using C++ syntax. I hope I’m clear enough explaining the problem.

This issue comes with WordPress 4.4 and the new document title behaviour, no matter the theme you are using. And, also, it is not a problem of WooCommerce (I don’t use it and I have the same problem).

I’m afraid that it is a new behaviour of WordPress 4.4, not the fault of the theme. I’ve updated to WP 4.4 and the document title of static front page has become “Home – Sitename”, before the update was “Sitename – Tagline”. Note that “Home” is the title of the page set as static front page, you could give it another title.

I didn’t know bout the 30 days limit in trash. Good point. Nothing more to add. The restore feature would be nice.

I’ve read your post some weeks ago. Today I understand what you mean.

I’ve used the plugin first time in my live website. I display post publication date and last modification date. My surpise was that 2 years old post (duplicated, edited and merged back) has now “today” as publication and last modification dates.

It is not exactly what you described but another case of overriding, not merging.

@pckeys as I said, it was a wrong configuration in the server-side cron job I was configuring. Now I use a server-side cron job, just like before, but using WP-Cron Control (https://www.ads-software.com/plugins/wp-cron-control/, do not confuse it with WP-Crontrol)