Forum Replies Created

Viewing 15 replies - 196 through 210 (of 3,660 total)
  • Plugin Author Chip Bennett

    (@chipbennett)

    Hi Federico,

    That’s really outside the scope of the Plugin. The purpose of the Plugins is solely to send the notification emails to additional email addresses.

    I’m not inclined to make other changes to the content of the email itself (because it’s not the purpose of the Plugin, it’s not something I would want to try to maintain, and is something that ideally would be handled by a separate Plugin specifically for that purpose), and in fact, if/when a couple of core patches I submitted get implemented, I’ll pare the Plugin down just to adding a filter to the email address directly.

    Plugin Author Chip Bennett

    (@chipbennett)

    I also notice that you have a Theme-defined Twitter script enqueued, as well as one or two Twitter-related Plugins. Any or all of those could be interfering/conflicting.

    To debug:

    1) Switch to Twenty Twelve Theme
    2) Disable all Plugins except cbnet Twitter Widget
    3) Verify that the Plugin works properly
    4) Re-enable other Plugins one-by-one, verifying that each in turn does not cause the problem
    5) Once all other Plugins are enabled, verify cbnet Twitter Widget Plugin still works properly

    At that point, you’ve either identified a problematic Plugin, or ruled out all Plugins. If you’ve ruled out all Plugins, you’ll need to repeat the process, with your own Theme active:

    1) switch to your normal Theme
    2) Disable all Plugins
    3) Verify that cbnet Twitter Widget works properly
    4) If it doesn’t, then the problem is with your Theme
    5) If it does, then you’ll need to repeat the process of re-enabling each Plugin, one-by-one, to find out where the conflict occurs.

    Plugin Author Chip Bennett

    (@chipbennett)

    What happens if you switch to Twenty Twelve? Do you observe the same thing, or does the Widget properly display?

    Chip Bennett

    (@chipbennett)

    Thread Starter Chip Bennett

    (@chipbennett)

    From further testing, I am unsure if this is related or not, but it appears to be: the_post_format_image( $attached_size ) is also not rendering the image size specified by $attached_size.

    Calling the_post_format_image( 'custom-image-size'), using a custom image size properly registered via add_image_size() (and regenerated), outputs the image as the thumbnail size.

    Thread Starter Chip Bennett

    (@chipbennett)

    Just had another go. Selected “Thumbnail” followed by “Select Image” and got the full size image dropped into the post! Repeated the process and got exactly the same result. Something is definitely borked somewhere.

    I get the same thing; the full-sized image is inserted in the post; e.g:
    http://design.chipbennett.net/oenology/2010/05/03/fire/

    I’m unsure what that caption code is, or why it is displayed, for the image post format. But, whatever it is, it is incorrect based on user selection.

    Thread Starter Chip Bennett

    (@chipbennett)

    FYI:
    http://core.trac.wordpress.org/ticket/24260

    (I decided to go ahead and open a Trac ticket.)

    Thread Starter Chip Bennett

    (@chipbennett)

    I just repeated the process with a new/uploaded image, with the same outcome.

    Thread Starter Chip Bennett

    (@chipbennett)

    All of the images I try to select from the Media Library are defaulting to “Full size” – not “Thumbnail”. If it helps at all, I initially went straight for image-landscape-9001.jpg (which was part of the previous unit test data) but got exactly the same for every image I tried to select.

    Is there anything else I can try that might help?

    What happened when you inserted the image? Did it respect your choice, or revert to the default value?

    Chip Bennett

    (@chipbennett)

    I’m going to take a stab, and guess that the difference is whether the sticky posts are on the first page, or subsequent pages, in the current pagination.

    Of the 3 sticky posts, 2 are on page 2, and one on page 3, with 12 posts per page?
    Of the 4 sticky posts, 1 is on page 1, 2 are on page 2, and 1 is on page 3, with 12 posts per page?

    Of the 9 sticky posts, 3 are on page 1, and 6 are on subsequent pages, with 12 posts per page?
    Of the 9 sticky posts, 8 are on page 1, and 1 is on a subsequent page, with 20 posts per page?

    I believe that WordPress pulls sticky posts out of the normal post flow, including posts per page/pagination. If the sticky posts would normally fall on the first page with the current pagination, then the number of posts displayed on the first page will be unaffected. But, if the sticky posts would normally fall past the first page with the current pagination, the first page will display more posts than the posts_per_page setting.

    Chip Bennett

    (@chipbennett)

    The extra load is minimal.

    Bingo. The law of diminishing returns applies here. There are usually far greater opportunities for page-speed improvement.

    If it bothers people that much, they can always create a custom header.php file and load their parent & child theme’s stylesheet that way.

    And if it’s *that* much of a problem, just copy/paste the parent style.css declarations directly into the child style.css file.

    Chip Bennett

    (@chipbennett)

    More than likely, the attack vector is something other than WordPress itself, or your Theme.

    Most often, the issue is an insecure hosting environment. Next most likely is compromised FTP credentials (possibly related to a local-machine virus).

    After that, it is possible that a Plugin is the issue. What Plugins do you have active? (Two major caching Plugins recently had security vulnerabilities patched.)

    As for safe Themes: get them from the official Theme directory:
    http://wordpress.org/extend/themes

    They are all human-tested for, among other things, security issues.

    Chip Bennett

    (@chipbennett)

    When in the text edit mode, not the visual side. If I ad <br><br><br> I only get one line break instead of 3.

    Do you, by chance, switch between the HTML and Visual editors?

    Chip Bennett

    (@chipbennett)

    It’s a fair point and I don’t see any argument against it.
    @syrinx32123 Can you create a thread on the Requests and Feedback forum regarding this please?

    There is no need to make such a change. There is nothing wrong with using @import.

    If you have a site that legitimately needs to performance improvement between the two methods, then you’re big enough that you probably already have a paid developer on staff, who doesn’t need to be told how to enqueue stylesheets. Otherwise: you’re not going to notice the difference.

    Using @import is the easiest and most user-friendly approach, and should remain as the default/recommended implementation.

    Chip Bennett

    (@chipbennett)

    Should the Codex recommendation change from @import to enqueue?

    No. There is absolutely nothing wrong with using @import, and it is, by far, the more user-friendly approach.

Viewing 15 replies - 196 through 210 (of 3,660 total)