sudo ntpdate ntp.ubuntu.com

It will sync your time with the Ubuntu Time server. You can even add a cron entry as suggested by this article. To display the current time and date, simply type date. Hope this helps :)

Source: Sync Time and Date in Ubuntu Linux by Konstantin Kovshenin

Source: Open-sourcing the Code Comments Trac plugin by Nikolay Bachiyski, from the WordPress.com VIP team. I haven’t ... by Konstantin Kovshenin

So… Starting today, I’ll be working on some really cool stuff with some of the most talented minds on earth. I’ve already met with some of the folks online and the energy is incredible, they got me even more excited, and now I can’t wait for my first meetup and of course WordCamp to meet everybody in real life.

This is a dream come true for me, thank you so much Automattic! Looking forward to “make the web a better place.” :)

Source: I’ve Joined Automattic by Konstantin Kovshenin

class Some_Plugin {
    function __construct() {
        add_action( 'admin_init', array( $this, 'admin_init' ) );
    }

    function admin_init() {
        // Whatever
    }
}

If you don’t, then you can stop reading now :) I’m addressing the naming technique here, the fact that admin_init is both an action tag, and a method that you assign to that action tag. So if I’m naming all my methods after actions and filters tags in WordPress, isn’t there a way to cut down the burden of having to add_action and add_filter all the time?

I’ve been thinking of an approach that could solve this problem in both, an easy to understand way, and a compatible way. Perhaps we’re lacking a WP_Plugin class in WordPress that would take care of this (along with a bunch of other things) for us, so that we can focus on writing our plugin, and not spend time matching tags to methods.

Here’s a concept that first popped into my mind, experimental and buggy, but something to get our heads thinking about it. If your class extends the WP_Plugin class, and your method’s name starts with a double-underscore prefix (or any other convention we may choose), and matches an existing action or filter, why not run the action or filter automatically without having to add_action or add_filter?

class Some_Plugin extends WP_Plugin {
    function __admin_init() {
        // Will run during admin_init
    }

    function __the_content( $content ) {
        // Will filter the_content
        return $content;
    }
}

Again, it’s just a thought and a lot of decisions should be made before implementing something like this. I went ahead and drafted a plugin file which works well to some extent. You can change the method name convention on line 18.

So my questions to you, dear reader are: is will this make things easier for the WordPress developers? Will this mess things up? What do you think of the prefix convention? How would you propose to handle the priority dilemma? What else could go into a WP_Plugin class?

Update! It seems like Reflection is a better approach at what I’m trying to do, and separating actions from filters logic too. Thanks so much for the heads up Ryan McCue, Kaiser and Daniel Dvorkin. Here’s Ryan’s improvement over my first Gist.

Thanks for stopping by and subscribing!

Source: Hey WordPress, How About a WP_Plugin Class? by Konstantin Kovshenin

127.0.0.1 *.multisite.lo # will not work!

There are quite a few solutions though, first and easiest of which is to run multisite with a subdirectories setup. The second solution would be to manage you hosts file manually and create an entry for each subdomain in you installation. This could be a pain if you’re working with quite a large amount of subdomains, in fact you can end up spending most of your time editing you hosts file and flushing DNS cache.

I wrote a little snippet that you can use in a plugin file or functions.php which prints out a string you can copy and paste into your /etc/hosts file. It generates an entry out of all the existing domains in your WordPress multisite install and maps them to the IP address you specify.

add_action( 'wp_footer', 'print_entry_for_hosts_file' );
function print_entry_for_hosts_file() {
    global $wpdb;
    $domains = $wpdb->get_col( "SELECT domain FROM $wpdb->blogs;" );
    echo "127.0.0.1 " . implode( ' ', $domains );
}

The wp_footer hook will get it to print the entry in your theme’s footer but you can attach it to any other hook if you like. When actually pasting the generated entry into your hosts file, make sure you remove the previous entry for your domain to keep the file clean and shiny. Comment out the add_action line to hide the mess until you add a few more sites to the network and need to update you hosts file again.

I agree it’s still a bit of a pain but it really helps! The third and probably most correct way of handling wildcard domains working locally would be to set up a DNS server. It’s not always worth the trouble though.

If you had experience dealing with wildcard domains in WordPress multisite, please share your thoughts in the comments section below. If you installed a local DNS server, feel free to link to any guide or tutorial on how to do that on your operating system. Thanks!

Source: WordPress Multisite with Wildcard Subdomains by Konstantin Kovshenin

Source: I turned 23 today, it doesn’t feel too much different from last year. I ... by Konstantin Kovshenin

And thank you so much for that, WordPress, but I’m tired of constantly having to open the media manager to insert an image into my post or page. Having the visual editor carry out the “drop files here” role would be awesome, it would save at least one click every time I need to insert an image.

Two clicks if we can get it to upload and insert the image into the editor without even showing the Add Media screen! But that might be a little more complicated because of positioning and sizing. A simple upload is where we should start.

So I went digging around Plupload last night — the library that powers the upload features of WordPress since 3.3. I spent almost two hours poking the tool around and I could get it to handle drag and drog events literally anywhere in the admin screen, except the freaking TinyMCE editor, because of the stupid iframe! Can you believe that!

I’m not loosing hope though, I’m quite sure that I (or somebody else) will come up with a solution. At least I can get to drop files in the HTML editor textarea ;) Thoughts?

P.S. An “idea” has been submitted to WordPress.org pool, I appreciate the votes there if you own a dot-org account. Thanks!

Update: Thanks to my brother @SoulSeekah we’ve been able to figure out that the TinyMCE editor is not loaded at the time I added the drop event listener. Okay now this is exciting, let’s see where we can take this!

Update: Proof of Concept

Ready? Are you sure? Great!

Sorry for the background noise, and low quality sound. In this video I’m demonstrating my first experiment, currently as a plugin. I’m not ready to share the plugin yet since it needs a little bit more work, and besides, I had to make changes to the plupload file shipping with 3.3.1 core.

As soon as I have something I’ll open a core trac ticket to see where we can take this. Thank you all for your support.. And ugh.. What do you think?

Update: Trac ticket created if you’d like to follow along. Thanks for the support everyone, it really means a lot to me!

Source: Dear WordPress, I Want to “Drop Files Here” in the Visual Editor! by Konstantin Kovshenin

What is MAMP and why MAMP?

WordPress is not a stand-alone application. In order to work, it requires a special set of server software that your hosting company will typically provide for you, but such software is not pre-installed on your local Mac. This means that in order to run WordPress locally, you would need to install and configure the set of software yourself, but luckily there’s MAMP!

MAMP is a stand-alone application for Mac OS X which brings server power to your home or office desktop or laptop. It bundles the typical software stack you’d need to run all sorts of web applications including WordPress; that is the Apache web server, a MySQL database server and a PHP interpreter. As you might have noticed, those three are the “AMP” part. The first “M” stands for Macintosh, or as we call it nowadays — Mac.

Installing MAMP

If you’re a Mac user, you’ve probably gone through the process of installing new software in OS X, and MAMP is not too different. Let’s browse to the MAMP website and get ourselves the latest copy of the software. It’s usually bundled with MAMP PRO trial (a commercial and more advanced) version, but we’ll be using the free version which is enough to get you started.

Once the download is complete (over a hundred megabytes,) extract the contents of the archive somewhere, your desktop is a good place. You’ll see that it contains a MAMP.pkg package which you can run. You’ll be greeted with a user-friendly installer where you’ll have to keep hitting Continue to get through each step.

Note that during the Installation Type step, you can hit Customize and uncheck MAMP PRO which would skip the trial commercial package.

After MAMP has been installed, you can launch it using the Applications tab in your dock or by searching for MAMP in Spotlight. Note that when starting and stopping services and changing the configuration, MAMP may ask you for your password, which is required to make system changes in OS X.

The Status section on the left will show you when the Apache and MySQL services are started or stopped. After changing any configuration, you might need to restart the servers for your changes to take effect.

Configuring Apache & MySQL Ports

This step is quite important. By default MAMP sets non-default ports for Apache and MySQL in order to avoid possible conflicts with other running applications, so unless you’re using some software that occupies the default ports, it would be nice to change them. Apache to port 80 and MySQL to port 3306.

Use the Preferences button, and then the Ports tab to make the necessary changes. MAMP will have to restart your servers for the changes to take effect.

Now while you’re at the MAMP preferences, hit the Apache tab to be able to select a directory root. This is like the public_html folder on your web hosting server, but a local one. That’s where you will install WordPress and store all your project files. A folder in your Documents is a good place to start. I’ll call it my_document_root.

To make sure everything is working correctly, let’s create a new PHP file in the directory we just set as our document root. Call the file index.php and have its contents say something simple:

<?php phpinfo(); ?>

Then get your web browser to point to localhost and if you’re lucky enough you’ll see the PHP info page that looks like this:

Hurray, now delete that file and let’s get a MySQL database ready for WordPress.

Creating a MySQL Database for WordPress

Now, before installing WordPress we need a database where it would store its data and settings. MAMP ships with a database manager application called phpMyAdmin and the WordPress Codex has a guide on how to create a database with that, but let’s take a shortcut here and fire our Terminal in OS X. You can find it in your Applications folder or easier, through Spotlight.

The Terminal is a command line utility to your Mac, sort of what you might have heard about Linux, DOS and so on.

If you’re planning to become a kick-ass WordPress developer, you’re going to have to learn this tool. We’ll type in a few commands (which you can easily copy and paste) that will connect to your local MySQL server, create a new database for WordPress and then create a new MySQL user with access to that database. Ready?

mysql -uroot -proot
CREATE DATABASE wordpress;
GRANT ALL PRIVILEGES ON wordpress.* TO wp@localhost IDENTIFIED BY 'hello';
EXIT;

Don’t get too scared yet, it’s quite simple if you understand what each command does. The first one connects to our local MySQL server using root as the username (the -u argument) and root as the password (the -p argument.) These are the default settings in MAMP. Note that there is no space character between arguments and their values. If that gives an error, you should explicitly tell Terminal where the MySQL binary is (where you installed MAMP,) in my case it’s:

/Applications/MAMP/Library/bin/mysql -uroot -proot

If everything’s correct, the first command will open a MySQL command line (in the same Terminal window) to which you type in the rest of the commands or as they’re called SQL queries. The first query (second command) is straightforward — it will create a new database called wordpress and the second query will grant all possible privileges (read, write, delete, etc.) on every table in the wordpress database, to the wp user originating from localhost identified by the hello password.

The third query exits the MySQL shell, at which point you no longer need Terminal so feel free to close it. Here’s a screenshot from my Terminal to make sure you’ve done everything right:

As you might have guessed, the bolded words in the paragraphs above are the values we’re going to use when setting up WordPress, so we’re really close now!

Installing WordPress

Okay, I assume you already know where to get the latest version of WordPress. Download the ZIP archive and extract it to that document root directory. The one where we created our index.php file, remember? Note that the archive might (and probably will) extract an additional folder called wordpress with all the WordPress files inside. Feel free to move all the contents of that folder back to your document root and then delete the empty WordPress folder.

Now, open your browser and point your web browser to localhost again. This should bring up the WordPress welcome page and then on to your database settings, which you probably are familiar with already.

The database name, username, password fields are the ones we used when creating the user and database, remember? The host field is localhost because MySQL is running on the same computer (your computer) as the Apache web server. The table prefix is up to you. I generally leave it wp_ for local installs.

The rest is pretty straightforward, blog name, admin username, password and e-mail. After having filled those in you’re left with your brand new and empty WordPress installation, on your local machine, running MAMP. Congratulations!

Conclusion

I’d like to end this tutorial with a few short tips you might find useful when working with WordPress locally on MAMP.

• While MAMP itself is a lightweight application, when working for a long time without turning it off (and without restarting your computer,) it can get a little laggy and use too much memory. Kick it around from time to time.
• If ever needed, Apache and PHP configuration files are located in MAMP’s conf directory, that’s /Applications/MAMP/conf.
• Apache and PHP binaries and service scripts are available in MAMP’s bin directory, Apache, PHP and MySQL logs are in the logs folder (duh.)
• You don’t need MAMP PRO unless you’re 100% sure you do.

Final tip — whenever you become a MAMP ninja, don’t stop there! Your next goal is being able to run a local virtual machine with your favorite Linux distribution linked to your Mac OS X with a network file system or something similar. That would really get you closer to the real world hosting environments, and a better WordPress pro.

Thank you so much for reading, hope you enjoyed it and feel free to ask questions, post comments and come say hi on Twitter too. Cheers and thanks again!

Source: Installing WordPress with MAMP on Mac OS X by Konstantin Kovshenin

Source: Stop SOPA Ribbon for your WordPress site or network. A plugin I made in ... by Konstantin Kovshenin

Andy Stratton gave a presentation called “Diet Pills, SEO, and Theme Frameworks” at WordCamp Chicago 2011. He talked about WordPress themes, frameworks, marketplaces and a lot of related misconceptions, and some of the many problems with commercial themes including SEO, customization, child themes. Here’s a quote if you haven’t got time to watch the whole video.

There are no shortcuts to awesome!

So if your clients think that $30 themes are flexible, customizable and awesome products that will solve all their business problems, they might be wrong. Thank you Andy for clearing that out! Andy’s presentation is on SlideShare too!

Source: Andy Stratton gave a presentation called “Diet Pills, SEO, and Theme Frameworks” at WordCamp Chicago ... by Konstantin Kovshenin