crowinck

Thanks for responding!

Sorry, that url I gave you wasn’t quite accurate. I have some more info for you:

It looks like this only happens when the main stylesheet is enqueued in the functions.php file rather than hard coded in header.php.

So if you are using twenty ten with BWP Minify and WPML, it has this in the header.php:
<link rel="stylesheet" type="text/css" media="all" href="<?php bloginfo( 'stylesheet_url' ); ?>" />
You won’t have any issues.

But if you are using twenty fifteen with BWP Minify and WPML, it uses this functions.php line:
wp_enqueue_style( 'twentyfifteen-style', get_stylesheet_uri() );
And it does manifest the problem.

At this point I believe enqueuing is considered the better practice, so simply switching to inserting the link in header.php is not a good option.

As for your question, when BWP isn’t active there is an additional link element that leads to a standard site stylesheet. When BWP is active there isn’t, there’s a link element with an id of “language-selector-group-css” and one of its parameters includes the path to the theme stylesheet. The url looks like this normally: https://www.example.com/wp-content/plugins/bwp-minify/… but when the language is switched, and extra query parameter is inserted in the wrong place, and breaks it: https://www.example.com?lang=fr/wp-content/plugins/bwp-minify/…

I hope that helps.

Hi Michael, sorry I sounded abrupt. Thanks for responding, my employee will be emailing you shortly.

Actually, since you didn’t respond earlier, I figured this out myself.

The numbers displayed are content drilldown numbers. Child page views are included in the parent view numbers. The views shown for a static front page are actually the views for the entire site. I’m really surprised this hasn’t bothered anyone else.

It’s the GA dashboard plugin that is doing this, the widget is just following along. in the GA API, you can get views for an exact url or a partial url. I’m guessing a partial url is used so query strings, etc are counted. But child pages are also included in the partial url counts.

I ended up creating a separate shortcode that fetched views for the exact url to get the numbers I wanted.

Are you planning on doing a fix for this?

It would just be nice to know whether I’ll have to comment that conditional on every update to keep the plugin working.

The front page has three loops, one uses the_post() on the main query object, the second uses setup_postdata(), and the third uses the the_post() on a new WP_Query object. It’s this third one where the plugin used to work and doesn’t anymore. It’s possible I need to reset postdata after the second loop… naw, doesn’t make a difference.

Here’s what I’m seeing before loops 1 and 3:

Array
(
    [0] => page
    [1] => singular
)

Hi there,

First of all, the real issue is that the plugin isn’t filtering at all, the only immediate visual difference was the lack of line breaks, because I had a number of other filters for adding the more link, etc, when your plugin wasn’t in use. Sorry about the mis-assessment.

I have done bunch of testing, and determined that the plugin stops running on line 88 of class/advanced-excerpt.php, with this test:

`if ( !empty( $page_types ) && !empty( $page_type_matches ) ) return;’

The page in which the plugin is no longer working is front-page.php. This page has several loops, one from the page assigned as the front page, and others to draw in content from around the site. It must be falling through the cracks when you are doing your page types tests.

In the settings for the plugin, I have not disabled it for any specific page/page type, so it should be running.

Does this give you enough info to fix this bug? Do you need anything else?

Both templates are using the_excerpt()

I’m going to look through the theme where it isn’t working and see what excerpt filters it has, and if disabling them makes a difference.

Unfortunately this version didn’t make a difference. I tried disabling all the other plugins without effect. However, I did manage to see paragraph breaks in the excerpts by briefly switching the theme to twenty-ten and going to the search page.

So it could be a theme compatibility issue, though I haven’t made any recent changes to the theme that would affect content filtering, and I’m pretty sure it started with the last update.

If you want to try anything else that would be great, but if you don’t want to pursue it, I can troubleshoot potential theme issues for a while.

No, I ended up choosing a different plugin.

I was actually using the dev version posted on www.ads-software.com rather than the one on github. When I have staging vs live issues it’s always because of caching. Maybe the old author is being cached somewhere?

Since it was working for other people I tried it again, in case I made a mistake and uploaded the wrong files or something. It’s also working for me now.

Sorry for the mistake, thanks a lot for following up and fixing this.

Sorry, the bug is still there.

It looks like all the usernames in question have spaces, so yes, I believe they would. (I haven’t actually looked in the database or anything, let me know if you need me to confirm). The site is also a multisite install, in case that makes a difference.

This problem started with Co-Authors Plus 3.0.

Thanks for looking at it!

Thanks for the clarification. Let me also clarify.

What we’re saying is that on our sites, the storing of the first author as the WP ‘post_author’ is no longer working.

If user A creates a blog post, and then tries to change the first author to user B, (so user A’s name is no longer associated with the post in any way), all of the WordPress functions will still bring up user A, not user B.

We don’t expect the WP functions to bring up multiple authors, we just need them to bring up the right first author.

I thought you were saying this was intentional. It sounds like you just misunderstood us.

It’s unrealistic to expect every other plugin we are using to use your special functions rather than the WordPress ones. Other plugins and features that aren’t hooked into your plugin should be able to fall back on working with the main author. By preventing users from changing who is the main author for everything other than your plugin, you’re not playing nice with everyone else.

No one ever recommends rolling back, but it’s not any better to hack my other plugins to use your functions.