beer planet » Wordpress

How To: Disable/Block External HTTP Requests In WordPress

Artem Russakovskii — Wed, 16 Nov 2011 18:57:43 +0000

One thing that's been continuously annoying me when doing WordPress development on the go is when something somewhere inside WordPress decides to send requests to external urls when I don't even have Internet connection or it's slow and flaky (tethering, slow Wi-Fi, etc). This results in random lag when loading pages, especially if I haven't opened my dev WordPress instance for a long time.

Turns out there's an easy and undocumented (other than in code) solution. To block external HTTP requests right in WordPress's core itself, open up wp-config.php and add WP_HTTP_BLOCK_EXTERNAL like so:

1	define('WP_HTTP_BLOCK_EXTERNAL', true);

Whenever this variable is present, external requests will be ignored, unless you specify your own comma-separated whitelist of domains using WP_ACCESSIBLE_HOSTS like so:

1	define('WP_ACCESSIBLE_HOSTS', 'site1.com, site2.com');

You can examine relevant core code here and the relevant bug reports here and here.

Happy developing!

Similar Posts:

How To Add Shortcode Support To WordPress Comments And Sidebar Widgets

Artem Russakovskii — Sat, 16 Oct 2010 03:20:26 +0000

WordPress has a great way of letting you use simple text tags called shortcodes to provide a whole bunch of functionality, including custom PHP code. In this article, I'm assuming that you already know what shortcodes do and how they operate (if you don't, head over here: Shortcode_API).

One glaring omission in the way shortcodes are set up by default is that they only get triggered in the content of your post, leaving the sidebar and comments out. I'm sure this is done for security, so that your readers can't screw something up by posting shortcodes they're not supposed to – after all, shortcodes are PHP snippets on the backend.

However, let's assume you really know what you're doing and you want, for example, to allow certain shortcodes in the comments and all shortcodes in the sidebar. It's your site and you should be able to do whatever you want with it. For instance, I wanted to provide a way to include QR codes using a [qr] shortcode syntax that I'd written both in the sidebar and in the comments, except in the comments that was the only shortcode I wanted to allow my readers to use.

Since these cases can get complicated, let's start simple and then progressively get deeper.

Allow all shortcodes in the sidebar

Assuming you want to enable shortcodes in the PHP Code Widget widgets (I believe this is the most common way to add PHP support to the sidebar), use this code:

1	add_filter('widget_execphp', 'do_shortcode');

If you have some other widgets in mind, you have to find out the right filter and use it just like above.

Allow only whitelisted shortcodes in the comments

Since I don't want all shortcodes to fire here, things get slightly trickier.

function init_common_shortcodes() {
  add_shortcode('qr', 'my_shortcode_qr');
}
 
function init_comment_shortcodes() {
  remove_all_shortcodes();
  init_common_shortcodes();
  add_filter('comment_text', 'do_shortcode');
}
 
init_common_shortcodes();
add_filter('comments_template', 'init_comment_shortcodes');

The code above will remove all shortcodes when it gets to comments and reinitialize only the whitelisted one called "[qr]", which is exactly what I wanted.

Note: If your code somehow uses shortcodes after the comments (such as a sidebar or a custom post query), you will need the trick in the next section.

Allow all shortcodes in the sidebar AND only whitelisted ones in the comments

At this point, things get slightly tricky because if I combine the previous 2 solutions into 1, by the time WordPress gets to the sidebar, it'll be left without any shortcodes at all – they've been removed by the code dealing with comments. Therefore, I need to save the shortcodes before dealing with comments and then restore them after the comments and before the sidebar.

function my_remove_all_shortcodes() {
  global $shortcode_tags;
  global $temp_shortcode_tags;
  $temp_shortcode_tags = $shortcode_tags;
  remove_all_shortcodes();
}
 
function my_restore_all_shortcodes() {
  global $shortcode_tags;
  global $temp_shortcode_tags;
  if(!empty($temp_shortcode_tags)) {
    $shortcode_tags = $temp_shortcode_tags;
  }
}
 
function init_common_shortcodes() {
  add_shortcode('qr', 'my_shortcode_qr');
}
 
function init_comment_shortcodes() {
  my_remove_all_shortcodes();
  init_common_shortcodes();
  add_filter('comment_text', 'do_shortcode');
}
 
add_filter('comments_template', 'init_comment_shortcodes');
add_filter('dynamic_sidebar', 'my_restore_all_shortcodes');
add_filter('widget_execphp', 'do_shortcode');
init_common_shortcodes();

Here is what the code does:

Initialize custom shortcodes that I want to add all over the place.
When WP gets to the comment block, it removes all shortcodes (again, for security) and re-initializes only the ones I want, but this time remembers them so that they can be restored later.
After the comments, when WP gets to the dynamic sidebar, it restores all the shortcodes and applies them to each PHP Code Widget.

And there you have it. Of course, the code may need tweaking for your own scenario but the ideas are all there. If you spot an error or know of an easier/better way, please let me know.

Similar Posts:

How To Diagnose And Fix Incorrect Post Comment Counts In WordPress

Artem Russakovskii — Sun, 21 Mar 2010 10:42:10 +0000

Introduction

If your WordPress comment counts got messed up, whether because of a plugin (I'm talking about you, DISQUS) or you messed with your database manually and did something wrong (yup, that's what I just did), fear not – I have a solution for you.

But first, a little background.

Comment Counts In WordPress

Here's how comment counts work in WP:

Posts live in a table called wp_posts and each has an ID.
Comments reside in a table called wp_comments, each referring to an ID in wp_posts.
However, to make queries faster, the comment count is also cached in the wp_posts table, rather than getting calculated on every page load.
If this count ever gets out of sync with the actual number of comments for some reason, WordPress, while still displaying all comments properly, will simply show the wrong count.

How To Find Out Which Posts Are Out Of Sync

Fire up a MySQL shell or your favorite MySQL software (mine is Navicat) and run this query.

It assumes your database is called wordpress and the prefix is wp_, so adjust those accordingly.

SELECT wpp.id, wpp.post_title, wpp.comment_count, wpc.cnt
FROM wordpress.wp_posts wpp
LEFT JOIN
(SELECT comment_post_id AS c_post_id, count(*) AS cnt FROM wordpress.wp_comments
 WHERE comment_approved = 1 GROUP BY comment_post_id) wpc
ON wpp.id=wpc.c_post_id
WHERE wpp.post_type IN ('post', 'page')
      AND (wpp.comment_count!=wpc.cnt OR (wpp.comment_count != 0 AND wpc.cnt IS NULL));

The result of this query is a list of posts whose comment_counts differ from the actual number of comments associated with each of them.

The left count is the cached number, while the right one is the right one.

How To Fix The Counts Automatically

Please make a backup of your database before performing any altering queries such as the one below (I recommend mysqldump or the WP-DBManager plugin).

The following query will recalculate and fix the comment counts for all posts that are out of sync (ones we just queried for above):

UPDATE wordpress.wp_posts wpp
LEFT JOIN
(SELECT comment_post_id AS c_post_id, count(*) AS cnt FROM wordpress.wp_comments
 WHERE comment_approved = 1 GROUP BY comment_post_id) wpc
ON wpp.id=wpc.c_post_id
SET wpp.comment_count=wpc.cnt
WHERE wpp.post_type IN ('post', 'page')
      AND (wpp.comment_count!=wpc.cnt OR (wpp.comment_count != 0 AND wpc.cnt IS NULL));

I tested this approach on a few test cases but if you experience any problems, please do alert me in the comments and desribe your problem.

Happy WP hacking!

Online 642-892 training is the quickest way to pass 642-642 as well as 640-863 exams.

Similar Posts:

How To View A Specific SVN Revision In Your Browser

Artem Russakovskii — Sun, 21 Feb 2010 06:04:17 +0000

This is a quick recipe that I found pretty interesting and relatively unknown.

Everyone who uses SVN knows that most repositories are set up to allow viewing of their contents via a web browser. For example, here's the trunk of WP Plugins SVN: http://plugins.svn.wordpress.org/ and here is the current trunk version of a specific file, let's say http://plugins.svn.wordpress.org/stats/trunk/readme.txt.

The Problem

However, what if you wanted to view a specific revision of a file or directory in your browser?

Let's say I wanted revision 100,000 of http://plugins.svn.wordpress.org/stats/trunk/readme.txt

Normally, on a command line, you'd do something like

svn co http://plugins.svn.wordpress.org/stats/trunk/readme.txt stats
cd stats;
svn up -r100000 readme.txt

or simply

svn export -r100000 http://plugins.svn.wordpress.org/stats/trunk/readme.txt

However, how would you do this in your browser? Trying something like ?r=100000 or ?revision=100000 parameters doesn't work.

The Solution

Here is the syntax to get a specific revision of a file or directory:

Take the root of the repository (in our case, http://plugins.svn.wordpress.org)
Append this string !svn/bc/REVISION_NUMBER right after the repository root and before the directory or file path.

Going back to our example:

http://plugins.svn.wordpress.org/!svn/bc/100000/stats/
shows the stats directory exactly as it was at revision 100,000 and
http://plugins.svn.wordpress.org/!svn/bc/100000/stats/trunk/readme.txt
shows our readme.txt at 100,000.

And that's how you do it, folks. Happy revisioning!

Update: this post is now sponsored by Wirefly Learn where you can find cell phone news and reviews, as well as comparisons and videos.

Similar Posts:

How To Remove Inline Hardcoded Recent Comments Sidebar Widget Style From Your WordPress Theme

Artem Russakovskii — Sun, 31 Jan 2010 09:45:15 +0000

The Problem

If you use the Recent Comments sidebar widget in your WordPress installation, it's possible that you want to customize this widget's style.

You will quickly find, however, that as soon as you add the widget to your sidebar, it injects the following inline, hardcoded CSS into the containing page (using !important to make things worse):

The code above comes from recent_comments_style() (found in wp-includes/default-widgets.php), which is in turn called by WP_Widget_Recent_Comments() in the same file (this is just an old-style PHP4 constructor – same as PHP5's __construct()), which is triggered when the Recent Comments widget is used:

add_action( 'wp_head', array(&$this, 'recent_comments_style') );

This leaves a bad taste in my mouth because:

the style is automatically forced into any page that embeds the widget
it uses !important to override any existing styles
it cannot be configured from the widget
this is a core WordPress widget and not some widget added by a random plugin. WordPress should not contain such bad practices.

After seeing this, I raised a new issue #11928 in the WordPress bug tracker but in the meantime, of course, I could go and hack the default-widgets.php core file to solve this problem. That, of course, would be a horrible thing to do – the next upgrade could wipe my changes or result in a conflict (if upgrading via svn). In general, one should never need to modify core files.

The Solution

Fortunately, there is a solution that doesn't involve modifying core files. Remember that we are talking about WordPress here, which gained its popularity due to the ease of customization.

Normally, we would just need to remove the recent_comments_style hook, which would prevent it from ever firing and injecting the CSS. In fact, somebody over at webstractions.com already took a crack at this approach with the following code, which may have worked for a while but doesn't anymore:

function remove_wp_widget_recent_comments_style() {
   if ( has_filter('wp_head', 'wp_widget_recent_comments_style') ) {
      remove_filter('wp_head', 'wp_widget_recent_comments_style' );
   }
}
add_filter( 'wp_head', 'remove_wp_widget_recent_comments_style', 1 );

This code doesn't work in the current version of WordPress because recent_comments_style() belongs to the WP_Widget_Recent_Comments class, and we need a tiny bit more effort to get through to the object of that class.

The following snippet, suggested by Andrew Nacin in a comment to the bug I opened up, does the job and works in WordPress 2.9.1:

add_action('widgets_init', 'my_remove_recent_comments_style');
function my_remove_recent_comments_style() {
	global $wp_widget_factory;
	remove_action('wp_head', array($wp_widget_factory->widgets['WP_Widget_Recent_Comments'], 'recent_comments_style'));
}

This code first gets access to the right object and then passes it to the remove_action() function, along with the right function name recent_comments_style. Stick it intoyour functions.php and it should do the trick.

And there you have it.

Similar Posts:

WordPress Developers – How Do You Make A Living [Poll + Discussion]?

Artem Russakovskii — Tue, 19 Jan 2010 01:33:45 +0000

The Question

I'd like to pose this question to all WordPress developers – plugin, theme, as well as core ones:

How do you make your living?

And, for clarification, by this I mean: "what are your primary sources of income?"

Open Source

Open source is a beautiful concept but it often comes with a price tag or, rather, the inverse price tag: most of the time you are not being paid for your time (of course, there are exceptions, such as companies hiring dedicated open source developers and keeping them on their direct payroll).

Everyone has to make a living, however, and everyone has their ways.

Developers can benefit from such income sources as:

advertising on their sites, fueled by boosted Alexa and Google PR ratings
freelancing and consulting work directly related to their open source project
presenting at developer conferences
creating products based on the open source projects they're involved with, as the technologies should be very familiar to them

WordPress

Since I've always been interested in WordPress development, I feel connected to the WordPress community and would like to get some insight into the lives of WordPress developers.

Therefore, in addition to the main question, I have some follow-up questions:

does Automattic pay WordPress core developers salary?
are there many WordPress core developers working for Automattic full time, besides Matt?
how about you, plugin and theme developers – are any of you successful enough that you can make a living off your plugins or themes?
what are your secrets?

So in your responses, please state whether you're a core or plugin/theme developer, and answer the questions above that you can.

Of course, it goes without saying that any extra bits of advice would be welcomed as well.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Update: this post is now sponsored by Wirefly Learn, where you can find a ton of cell phone tutorials, comparisons, and videos.

Similar Posts:

Follow-up To Loading CSS And JS Conditionally

Artem Russakovskii — Fri, 15 Jan 2010 20:07:40 +0000

First of all, I'd like to thank everyone who read and gave their 2 cents about the [Wordpress Plugin Development] How To Include CSS and JavaScript Conditionally And Only When Needed By The Posts post. The article was well received and will hopefully spark some optimizations around loading styles and scripts.

Here are some discussions and mentions around the web:

an article on Weblog Tools Collection
a forum post on WP Tavern
twitter retweets

Sure, there are drawbacks to this method and it does require some more processing on the backend and it's not for everyone, which is why we should always strive for an even better solution.

I stand by my point of view that, for instance, my dedicated gallery shouldn't load for people who will never even go see my photos.

I think an ideal solution would be for WP core developers, who had a lot of experience designing WordPress' internals and who know what can work and what can't, perhaps Matt included, to get together and think about a better solution really hard.

Conditional loading similar to the one discussed here is already possible in the admin area, which creates dynamic hooks by appending page ids to 'admin_print_styles' and 'admin_print_scripts'. It is, however, still not good enough to be used more generically because those hooks rely on the page you are on, rather than the content of that page.

Another possibility is using a PHP technique called output buffering (ob_start(), ob_flush(), etc) that grants second chances to data that had already been echoed. It intercepts all echo and print calls and redirects them into a memory buffer, so instead of printing data to the page right away, you can now modify the header even if it had already been processed. It's like giving it a second chance.

Would it work for WordPress? I am not sure but I sure could use your feedback, devs.

Update: Scribu, a WordPress master, came up with the approach that would at least handle loading JS, as it would put it in the footer, which can be done after the posts have been parsed.

His approach doesn't handle CSS which is why I decided to seek another solution but it doesn't require an extra pass through the posts and it benefits from using the shortcode API instead of stripos() or some hacky regex you'd need to come up with.

It's a great compromise for developers who do not want to take the approach I outlined in the article linked at the top of this page.

Similar Posts:

20 Inspirational And Original Comment Form Designs For Your Blog

Artem Russakovskii — Fri, 15 Jan 2010 17:00:00 +0000

Introduction

If you follow web design at all, you probably see 5 billion top NN posts on a daily basis mentioning site and blog designs, fonts, icons, etc.

However, nobody seems to be paying attention to these little but important guys: comment forms.

If you have an appealing comment box, you are more likely to receive comments (this is based on days of scientific research that I imagined I did in my head) and your content is more likely to be re-shared, voted up, and saved.

I really do feel that way when I visit blogs, especially when an otherwise aesthetically pleasing site has a plain vanilla comment box.

Let's Go

So here we go. I have looked through hundreds of sites to make this collection, go ahead and let me know if you like it (yeah, I know, my comment box is not as spiffy as theirs).

I've also included my notes with the parts that I liked.

1. blog.spoongraphics.co.uk

interesting submit button
fun background
great font
grungy
border glow
normal:

focused:

2. springydevelopment.co.uk

2 column
wide submit button

3. css-tricks.com

Chris Coyier doesn't mess around with crappy designs – his website is superb in general
normal:

focused:

internal disappearing labels
dimming labels
interesting submit button
custom images

4. net.tutsplus.com

tongue:

internal disappearing labels
appealing default avatar

5. smashingmagazine.com

simplistic
appealing submit button
absence of author website – less spam

6. branded07.com

fading
interesting background

7. depcore.com

simplistic
unconventional – looks like a pad of paper or a letter
contains an anti-spam measure

8. marcofolio.net

notify/don't notify option (for the first time the design is cohesive – not some random checkbox under the submit button)
lots of formatting buttons
smilies

9. jankoatwarpspeed.com

handy and appealing formatting buttons
flag next to the country – it then shows up next to each commenter, kind of cool:

10. dezinerfolio.com

highlight the field with focus – concentrate attention on one spot
large padding
by the way, they have an amazing header. I couldn't resist:

11. sohtanaka.com

I love it
custom submit button
hovering quote
very polished look

12. productivedreams.com

the comment box actually sits *above* the comments – a radical, yet interesting approach
custom icons
really nice custom highlight on hover effect:

usability and UX at their best

13. kevadamson.com

grungy, sloppy – looks great!

14. line25.com

clean
side by side
symmetrical, exact
I love it

15. markforrester.co.za

colorful, crayon-like (though it looks better on the site itself – you need to see it in its natural habitat)
internal disappearing labels

16. jrvelasco.com

simple, and yet sophisticated

17. gizmodo.com

very simple from the UX perspective:
- single line box, without the need to login first
- expands on focus
- no need to login even then, unless you want to – just enter your email

18. instantshift.com

this is one of my favorites
I love, love, love the way the comments look, especially the way the author ones stand out:

19. koodoz.com.au

internal disappearing labels
the design itself, while seemingly not too special, mashes with comment list very well. Check it out – I think the curvy lines are very creative:

20. elliotjaystocks.com

click the image – it's bigger than it looks
if you can't tell (), the elements are MASSIVE, which makes this comment box pretty unique

Conclusion

If you liked this post, you might also enjoy

BlogDesignBlog with 37 more comment form designs (though they're not as exciting).
1stwebdesigner with 77 comment form designs.
Queness with 20 stylish web form designs.

So, what did you think? The comment box you're looking for is at the bottom of the page.

Similar Posts:

[WordPress Plugin Development] How To Include CSS and JavaScript Conditionally And Only When Needed By The Posts

Artem Russakovskii — Wed, 13 Jan 2010 17:15:00 +0000

Introduction

In this tutorial, I am going to introduce a WordPress technique that I believe was unpublished until I raised the question a few days ago on the WordPress forums.

In short, the problem I was trying to solve was plugins unnecessarily loading their JavaScript and CSS on *every* page of the blog, even when doing so would achieve absolutely nothing and the plugin wouldn't do any work.

Update #1: I have posted a follow-up in response to some comments received around the web.

Update #2: There is a solution that can be considered a compromise as it works well for loading JavaScript but doesn't handle CSS.

I briefly mentioned this approach here but but Scribu decided to expand on it by providing a nice Jedi-themed tutorial. It is available here.

Let me explain using this example:

a code formatter plugin only does something useful when it sees a [code] shortcode in any post on the page.
most of your posts do not contain the [code] shortcode as you don't include code snippets that often or you only started using this particular plugin recently.
the plugin, however, loads the CSS and JS (which are most likely GeSHi and take up loads of space) on every page.
these CSS and JS do absolutely nothing on most page loads.
bandwidth is wasted, extra DNS and HTTP requests are processed, the browser is slowed down, and for what? For no good reason, other than the plugin author didn't know how to achieve this conditional loading.

If you think about it, there are many plugins that only do something once in a blue moon. Table of contents, text manipulators, galleries, sliders, etc, etc. If only they loaded their frontend code strictly when necessary, most page loads would suddenly become much lighter.

So what can we do to solve this? Let's look at a few techniques.

Loading CSS And JS In Place?

Here's one, albeit pretty bad, solution - only print the CSS and JS includes if and when you determine somewhere in the middle of loading the posts that the scripts and styles are indeed needed, then set a flag to avoid printing them again. In our example, that would be when the plugin detects the [code] shortcode.

This, however, is a mediocre solution because, while it's not a bad idea to load Javascript in the footer, CSS should be loaded in the header, otherwise the page might look unformatted until the CSS is reached.

Additionally, it's not the cleanest and most robust solution because you shouldn't be writing