Timani I

So it seems that i am being verbally bludgeoned to write, so if that was the request, then here we go.

Firstly there was no official word from WordPress for about 3 days. 3 days of radio silence while security “sources” had posted this information for public consumption for some time.

So i do not know what you want the community to do? Sit and close their eyes, and act like nothing is happening? Read no news sites or blogs until there is word from the official provider of the product.

If there was an actual breach and users had not been vigilant, i think you (annoymous) would not be as adamantly posting, and sending slightly over-zealous commentary?

To make it worse there was a code review for WordPress 3.0 beta when this happened, the EXACT same time this was all going, and not even an official notice. I think that would have been an opportune time to address this? No? The official note came on the 13th, that is 3 whole days after the issue was reported.

My question to you and WordPress is why not nip this in the bud then? Or why not at least issue a statement saying you are looking at it? My opinion will not change as i noted in the other article i wrote, linked, and updated on the 12th (with no official word still).

Much like Network Solutions is at fault, i think the response rate was inexcusably slow. People use the product personally, as well as run their business(es), so there is a obligation to be accountable even if its an issue indirectly affecting your product.

Unfortunately WordPress is no longer just a blog platform, its a BRAND.

After a point when your product reaches a such acclaim, and widespread use, there is a responsibility to the community to respond to critical issues in a timely manner. If you have a potential issue that is negatively affecting your product, you can not complain when community talks about it and as an entity do not address the issue in a timely manner.

I like WordPress a LOT, but Rome was burning and they were not there. Rather than put out the small fire now you have a full blaze to put out. You can decide how to apportion blame. Do you realize by simply making the announcement when the issue it was critical, all the chaos could have been avoided?

For me

#1 Network Solutions for the extremely poor handling of this.

#2 WordPress, firstly for the delay in responding to the matter, and secondly the handling of the negative publicity. Again but promptly adressing this we would have this conversation? Yes? And secondly even WP have to be accountable as they have to realize, but delaying and not saying anything that actually fuelled speculation.

Open Source is great, but after a time when you have a product becomes a household brand, the onus is on you to protect your brand’s integrity…. Period!

It is no longer a bunch of guys sitting around a some coffee shop sipping mochas writing “cool code”. Coca-Cola or Nike would not have sat for 3 days while a similar situation unfolded and hence this post. I told you that i would address this, and if you note most posts are on a weekend when i have free time, so sending a request multiple times in a number of different places isn’t going to help.

Do as you please, BUT even you can not deny that the chaos and hysteria was a DIRECT result of failure to communicate to the  community effectively and in a timely manner. Cheers!

Sorry, but this whole debacle spiralling out of control is the direct result of being REACTIVE rather than PROACTIVE!

It seems after the brief period of quiet and uncertainty the main cause of the vulnerability attacking WordPress blogs was revealed. The security magazine over at darkreading.com noted that is was the storing of critical information as plain text in the database is what left users exposed.

Earlier i had noted that there was a problem with sites going down, and on a variety of different hosts as a result of some malware, that used SQL injections.

“The attacker basically created a scanner to locate all configuration files containing incorrect permissions” – darkreading.com

From there the bot would then mine through to the database and inject the malicious iframes into the post content, and as a result all the visitors to the site would be infected  by malware.

It seems however, that the problem actually is the result in a flaw in the design of WordPress itself. This is because the loose permissions that the configuration files that were read are the default WordPress installation permissions.

Another important thing to note is that this is not actually a problem with the core code but a permisions problem. This is why over at WordPress the word was that there were a number of unanswered questions to around the circumstances surrounding the setup of these blogs.

As a result  Barry Abrahamson, a systems engineer at WordPress noted,

“WordPress can be installed a number of ways, and many hosts have built custom installers. I am not sure how WordPress was installed in these cases.”

From his prospective Abrahamson, also focused more attention on the hosting providers as the ones who should be on top of file permissions as he noted that,

“file level responsibility of the hosting environment, not the application.”

To some extent i think that this is true however, when the default permissions set by the application leave it at risk for exposure to injection attacks, they should make the changes within the application to protect their users.

This explains why  hundreds of blogs were able to breached at the same time. Essentially the fix for this one to make sure that your settings files like the wp-config.php and any other internal files have the correct permissions.

Also check with your host what the permissions are on your server and if they are secure enough to prevent your site getting attacked like this.

Again a clear example of why site permissions matter.

So i have to admit that one of my favorite new applications is Screener. What screenr allows you to do is to easily, quickly and painlessly record a desktop session, whether you are on a Mac, PC, or linux computer using a java applet (which is pretty fast).

Once you record your screencast, you can then manage and administer your own channel similar to a Youtube or Vimeo channel. You get the benefit of a sleek player that clearly distinguishes itself from the rest, simple and has basic sharing capabilities.

Here is a demo by Netuts of an editable list that takes advantage of HTML 5 and the localStorage attribute and works with compatible browsers.

This allows you to create, edit, update and delete elements, and keep the state of the browser even after you refresh the page. This used to be done using either a database or cookies but the nifty use the new localStorage:

More Info

Webstorage documentation – w3.org

localStorage demo -  people.w3.org

Basic information on localStorage – developer.mozilla.org

As the WordPress community eagerly awaits the final release of WordPress 3.0 it is always good news when you see positive reviews from Alex King, the WordPress innovator with plugins like the widely used Twitter Tools, the Carrington theme framework, and the WordPress ShareThis plugin, on how things progressed. This is also pretty re-assuring as this is essentially the first comprehensive code review of this type that they have done for the upcoming version.

At the moment WordPress is going through a major transition from version 2.0 released in December 24th 2005 to WordPress 3.0 Beta and 3.0 final scheduled for release in May 2010 according to WPDevel.

For those who have seen the gradual ascent of WordPress into the platform it is now, as the 2009 Packt Open Source CMS of the year, it is no longer just a “blogging script” but a leader in the Open Source PHP CMS game. Hence the particular interest in the eagerly awaited, and highly anticipated release.

Wordpress 3.0 Code Review completed

On another post i did note the malware currently attacking the WordPress as a whole, all the way up to installs of the current WordPress version 2.9 released on Dec 19th 2009.

Working with software and Open Source Web platforms as long as i have is that, the game played between developers and hackers is almost as tactical and calculated as the modern-day game between search engines and SEO professionals.

It is a constant battle to remain in front, luckily with platforms such as WordPress that have a millions of users, developers, and testers, so security patches are usually released with greater frequency than “closed source” products.

Some of the points addressed at the review were:

1. Differences between the current 2.9 and  upcoming 3.0 branches
2. Code review of the wp-admin directories
3. Partial review of wp-includes directories
4. Testing of a number of plugins using 3.0 development sites

Undoubtedly it is only the start, but sessions like this will help a lot considering the size of the WordPress community, and with more testing it will mean fewer bugs and hiccups as we all move to a new version.

One thing of i did find of interest is the fact that there was a lot of core functionality based on the WordPress MU fork. Personally, I did not find this too surprising as WordPress MU was fork of the original WordPress version and the progression was eventually bound to be circular in nature. Especially when you consider the advent of social networking and growth of community, and geolcation based services, the natural progression was a more community, multi-site, multi-user structure.

What did interest me was how current plugins built for the standard distribution would hold up? This was something we actually discussed over at WPBeginner (comments section) but so far things seem to be going as smooth as can be expected.

It is also remember that a lot of the active core WordPress developers have other permanent jobs and commitments so being able to have a comprehensive code review like this, at such a critical point, towards the release of 3.0 is even more important.

Recently i was working with the Facebook AP again, before i did my presentation at the Seattle PHP meetup . At the time one of the potential ideas was the linkedIn API and how to integrate linkedIn to your site, but obviously facebook was the API in demand.

As i was playing around with the linkedIn API and i managed to stumble upon the widgets that are one the developer site, and thought it would interesting to add them to your WordPress site.

I am sure that this is ideal for portfolio or sites, real-estate agents, companies adding some social networking flair to their site, blogs or in your mashups. Getting the work done is less than 5 minutes and does not require you to actually get into any code. The process really will only consist of a few steps:

1. Go to the developer site

From here you can get an idea of what the available widgets are and what they look like. There is an important note at the top of the page with Terms and conditions which you should check out first.

LinkedIn profile widget

2. Decide which type of profile widget you want to display

There are currently two versions, the popup and the inline version. The popup version is the one that i am currently using on my blog, where the name of the person appears with linkedIn icon beside it, and once you click on it the profile “pops” up.

The second is the inline version of the profile widget where the widget displays the entire public profile. I have made a video that you can check out at the end of the post where i actually do this, i chose the inline version for that demo.

3. Decide where you want the widget the appear.

You are going to need a widget area available so you can drop in you profile. Check the video at the end if you need a hint.

4. Grab and paste in the linkedIn profile widget script and copy it to your clipboard:

<script type="text/javascript" src="http://www.linkedin.com/js/public-profile/widget-os.js></script>

5. Go to you admin area and add the script tag

Widget Area on WordPress

Go to the Themes -> Widgets section of your site and grab a text widget.
Drag and drop the text widget on the to the Widget area you want.
When you are inside paste the linkedIn profile widget script you copied earlier.

6. Paste in your linkedIn profile code depending on which one you want

<a class="linkedin-profileinsider-popup" href="http://www.linkedin.com/in/timanitunduwan">Timani Tunduwani</a> - For popup
<a class="linkedin-profileinsider-inline" href="http://www.linkedin.com/in/timanitunduwani">Timani Tunduwani</a> - For inline

7. Add your public profile URL to the link

To do this i logged into my linkedIn account, and clicked the “Profile” link in the header. As you can see in the image if you scroll down on you just around the fold, you will see a label called “Public Profile” with a hyperlink next to it(this is going to be your public profile link on ).
Once you have done this replace your profile link and name with your desired widget code in step 6.

8. Finally add your newly formatted link

Go back to your widgets section and paste in the code you just modified into the same text widget as in step 4 below the script you had added before and you are done.

Demo:

Timani Tunduwani

In case you prefer to actually see a video on how to get this done here we go:

A couple of notes:

1. According to linkedIn the script tag should be placed in the head section for faster loading. (This could also be done from the admin area if you had enough permissions to edit theme files and depending on the theme)

2. Once you have added in the script tag in step 4 you can then add more than one profile link to a page.

3.After adding the script is you must keep the class names:  linkedin-profileinsider-inline or must be on the your desired links so the linkedIn script will know which links to parse and generate the widgets correctly

4. Using the inline method can be a bit slow at time and affect your page load, especially if you are going to have number of profiles on a page.

5. You can easily just paste the script tag into a widget or your header and then simply  add the popup or inline style to any post like i did in the demo above.

I think at the moment, there aren’t that many option i can see to play around with. With time as the API grows and you are able to configure things like which sections to display, the option of having your picture, customizing the look and feel more to match your site. I think then it would actually worth coding a plugin, but at the moment this is a decent fix.