The official website describes it pretty well:

etckeeper is a collection of tools to let /etc be stored in a git, mercurial, darcs, or bzr repository. It hooks into apt (and other package managers including yum and pacman-g2) to automatically commit changes made to /etc during package upgrades.

All it took me to set it up on my Debian Lenny slice was:

$ aptitude install etckeeper
# aptitude will install Git as the version control system, which is pretty neat!
$ cd /etc/
$ sudo etckeeper init -m "initial commit"
Initialized empty Git repository in /etc/.git/

The best part is that it’ll detect changes made by apt, commit whatever changes you had made previously, and even enable you to make your own commits, after your manual modifications. Do try it out!

Related posts:

1. WP-o-Matic 1.5: What to expect
2. How to change Wordpress default emoticons

To migrate ereg():

ereg('\.([^\.]*$)', $this->file_src_name, $extension);

becomes

preg_match('/\.([^\.]*$)/', $this->file_src_name, $extension);

Notice that I wrapped the pattern (\.([^\.]*$)) around / /, which are RegExp delimiters. If you find yourself escaping / too much (for an URL for example), you might want to use the # delimiter instead.

To migrate ereg_replace():

$this->file_dst_name_body = ereg_replace('[^A-Za-z0-9_]', '', $this->file_dst_name_body);

becomes

$this->file_dst_name_body = preg_replace('/[^A-Za-z0-9_]/', '', $this->file_dst_name_body);

Again, I just added delimiters to the pattern.
If you are using eregi functions (which are the case-insensitive version of ereg), you’ll notice there’re no equivalent pregi functions. This is because this functionality is handled by RegExp modifiers.

Basically, to make the pattern match characters in a case-insensitive way, append i after the delimiter:

eregi('\.([^\.]*$)', $this->file_src_name, $extension);

becomes

preg_match('/\.([^\.]*$)/i', $this->file_src_name, $extension);

Related posts:

1. Append your blog description to the window title in Wordpress

• check option, which can allow you to specify a function to filter out new boxes that do not meet a requirement
• encode now receives the complete values, not only the id or string of the bit. This gives you full control of what you want to send to the server.

• Autocomplete now works with on-demand suggestions. As easy as this:

  • Download code

  new TextboxList('form_tags_input_4', {unique: true, plugins: {autocomplete: {
  	minLength: 3,
  	queryRemote: true,
  	remote: {url: 'autocomplete2.php'}
  }}});

And some bugfixes:

• Fixed missing index when unique: false and autocomplete were used, which resulted in an error
• Fixed problems with items with id 0, which incorrectly evaluated as false.

Head to the demo to see the new autocomplete in action, and as usual, report any bugs you might encounter.
Update: 0.5 is out already, which fixes a bug with the traditional use of Autocomplete. Sorry for the trouble!

Related posts:

1. TextboxList 0.3 and jQuery version out!
2. WP-o-Matic 1.0RC4 released
3. WP-o-Matic 1.0RC3 beta shipping.

try
{
  $mailer = new Swift(new Swift_Connection_NativeMail());
  $message = new Swift_Message('The subject', 'The body <b>html</b>', 'text/html');
  $mailer->send($message, 'to@user.com', 'noreply@company.com');
  $mailer->disconnect();
}
catch (Exception $e)
{
  $mailer->disconnect();
}

However, due to API changes in Swift 4, that would have thrown an error:

Fatal error: Cannot instantiate abstract class Swift in /[...]/apps/frontend/modules/[...]/actions/actions.class.php on line 40

It turns out that now the class Swift is defined as abstract, which means it can’t be instantiated. Now, classes that you used to instantiate directly, like Swift_Message, have been added factory methods called newInstance

require_once('lib/vendor/swift/swift_init.php'); # needed due to symfony autoloader
$mailer = Swift_Mailer::newInstance(Swift_MailTransport::newInstance());
$message = Swift_Message::newInstance('The subject')
         ->setFrom(array('noreply@company.com' => 'Mailer Name'))
         ->setTo(array('email@email.com' => 'Name Lastname'))
         ->setBody('The body <b>html</b>', 'text/html');  
$mailer->send($message);

Remember that it’s good practise to get the body HTML from a partial, instead of hardcoding it into the action.

$mailBody = $this->getPartial('emailPartial', array(/* parameters */));
// ... 
->setBody($mailBody, 'text/html');

The code has become a lot more readable, easier to customize and write.
More information here and here.

Related posts:

1. Custom fields in edit/new admin generator views in Symfony
2. Symfony scaling: moving your uploads to a NFS share

This ambivalence is what still drives people, like myself, to keep writing about the infamous browser.

The tradeoff

The first premise we have to take into account is best summarized by this little website. There’s only two scenarios in which you can go to great lengths to make your website look (almost) exactly the same on IE6 and the rest:

• You have a very big budget, and a potentially huge IE6 audience. This is the case of websites like Facebook. If you read the Javascript and CSS of their widgets, you’ll know what I mean. The tradeoff here: money invested, poor markup and hacks all around
• Your website is just too simple. Why would you not try to fix a few CSS issues if your website is just too simple? If there’s no complex Javascript going on, and you have a nice little fixed-width website, there’s no reason why your site should look extremely different.

Mistake 1: make your site look like crap on IE6

The Universal Internet Explorer 6 CSS is the first big mistake I want to talk about. The idea here is that instead of wasting time on IE6 hacks, you just use a premade stylesheet, instead of disabling styling altogether. This is what A List Apart would look like if it was implemented.

This approach is flawed for a wide range of reasons:

• The idea behind this universal stylesheet is that disabling style would make your website look broken. However, your sites will look broken.
  • If you use a logo with a dark background, it’ll definitely not fit the white background the stylesheet imposes. The same goes for menus and any other graphical item that might not be ready for a white contrast.
  • If a prior version of your website or brand did work on IE6, and after a redesign you implement this, again, people will think something is really off.
  • There’s no “Universal JavaScript” solution. And as we all know, many of our scripts interact with the CSS present in the page. Disabling styling will also mean either disabling JavaScript or having to fix it for IE6 too, with the sort of hacks the universal stylesheet wanted to avoid in the first place (for example, conditional styling).
• It shouldn’t be black and white, there’s gray. At this time, most IE6 quirks have been perfectly documented. Most have very easy solutions: it’s almost a second-nature for me to add zoom: 1 to clear floats. Of course, making border-radius work on IE6 can be painful, but that’s exactly what you should be doing. Don’t go for all the small details: shadows, rounded corners, transparency. Or do it if the budget and time allows it. The key here is that you can still deliver your brand identity to IE6 without major efforts.

Developers strive to deliver an identity to all possible mediums. If they design custom iPhone versions, why can’t they streamline their stylesheet to make it look fairly good on IE? As an example, my website worked almost perfectly on IE6 with little work. However, when I triggered the rain in my clouds, it just crashed. As a result, I just disabled that particular effect.

Mistake 2: not explaining the user why IE6 is bad

As I was reading the comments on Jeffrey Zeldman’s post, I couldn’t help but be reminded of how condescending developers can be towards their users. The key here is that people will switch if they understand why.

Let’s look at some of the proposed solutions to make users switch.

• IE 6 Blocker overlay. Blocks content, doesn’t explain why the switch is encouraged
• Push up the web. Doesn’t block content, but doesn’t explain why the switch is encouraged and to top it off, it presents itself as sort of a deceiving “operating system important notice”.
• IE6Update takes the cake. Not only does it completely imitate a Microsoft warning in a deceptive way, but chances a very high that the user itself closed a similar message box a long time ago! Remember that Microsoft itself pushed the upgrade to IE7, even through the system automated updates. To top it off, this message doesn’t remotely explain how your website is better in a modern browser, so it’s an “easy close” for your average IE6 visitor.

The correct approach

1. Deliver the content
2. Make your website look OK on IE6, and somewhat similar.
3. Encourage the switch. If you’re looking for a universal solution for this, I would suggest placing a prominent link to PPK upgrade page. He presents the information in a very concise and reasonable way, that everyone can understand. The best idea, however, is to customize the message for your visitors. Explain why your website would be better in another browser. What they’re missing. How easier some tasks would become with better JavaScript widgets or how nicer the navigation could be.

Related posts:

1. IE7 still creating problems for developers?

• New project page with documentation and how to use explanation
• It includes the upcoming, updated and optimized Fx.MorphList
• The download package has been fixed for a very easy deployment.

Related posts:

1. BarackSlideshow and MorphList updated
2. The new TextboxList is here
3. BarackSlideshow - An elegant, lightweight slideshow script

Encoding and decoding is a simple as this:

$s = new PHPShortener();
// encode a long url
$shorturl = $s->encode('http://devthought.com/projects/php/phpshortener/', 'is.gd');
// decode a short url (autodetects the service)
$longurl = $s->decode('http://tr.im/jBBp');

Head to the project page for downloads and documentation. Fork me on GitHub if you want to contribute!

Related posts:

1. PHPShortener
2. WP-o-Matic 1.0RC4 released
3. WP-o-Matic 1.0 to be released

<?php
 
/*
 * Package-Name: Theme name
 * Package-URI: http://yourwebsite.com
 * Package-Description: Your theme description
 * Package-Author: Your name
 * Package-Author-URI: http://yourwebsite.com
 */
 
$wp_smilies = array(
	'>:o'      => 'angryface.png',
	'>:-O'   => 'angryface.png',
	':-['       => 'blush.png',
	':['         => 'blush.png',
);
// add as many as you want respecting the same format:
// 'emoticon' => 'file.jpg',

Now you’re done!

Related posts:

1. Append your blog description to the window title in Wordpress
2. Improve your 404 pages with Google
3. FeedBurnerCount

• HTML for bits not showing properly fixed
• highlightSelector not working (due to a typo) fixed
• GrowingInput missing pad function added (only affected if you customized growing.mini option)
• Improved clicking the whole widget behavior
• Other tiny enhancements / cleanup

Secondly, in the best interest of the JavaScript community, I’ve ported TextboxList to jQuery. The API changes slightly due to the different OOP approach, but all the functionality is intact. Head to jQuery TextboxList project page for more.

Update: 0.2 is out for jQuery. Bugs in autocompleter and IE have been addressed.

Related posts:

1. TextboxList 0.4: On-Demand suggestions
2. JavaScript RegExp based highlighting for MooTools and jQuery
3. The new TextboxList is here

Event.implement({
 
   hasCapsLock: function(){
      return ((this.code > 64 && this.code < 91 && !this.shift) 
           || (this.code > 96 && this.code < 123 && this.shift));
   }
 
});

And then access the method from a keypress event:

$('test').addEvent('keypress', function(event){
   if (event.hasCapsLock()){
      // do something
   }
});

The only drawback is that it relies on sniffing alphabet characters and whether the shift key was pressed. This means that if the user presses the caps lock key, you won’t know it until another character is inserted.

No related posts.