VIVA99: Link Daftar Situs Slot Online Deposit Dana 20000

The Wayback Machine -

Recent Updates RSS

  • Download Modular Twenty Ten 

    After receiving a request a few minutes ago, I realized that examples are no fun unless you can play with them! I’ve decided make Modular Twenty Ten available to download.


    IMPORTANT: You must install modularthemes.patch before activating the theme. Otherwise, WordPress will fail horribly.

    Download the latest patch: modularthemes.patch (Requires WordPress 3.0)
    Download Modular Twenty Ten:

    Developer? Follow trac ticket #12877.

    How to install the patch and theme

    Don’t know how to apply a patch? Follow these steps. You’ll need access to a command line.

    1. Download and install WordPress 3.0 beta 1. (Using SVN is fine too).
    2. In the directory you just installed WordPress, save a copy of modularthemes.patch.
    3. Open the terminal, and navigate to that directory. Enter the following:
      patch -p0 < modularthemes.patch
    4. Congratulations, you’ve just applied the patch!
    5. Now save and extract it to the wp-content/themes/ folder.
    6. You’re all set!

    Modular Themes:
    Trac Ticket | Part 1: Why? | Part 2: Theme Organization | Download | Performance

    Comments Permalink | Comment
  • Modular Themes: Performance 

    A note, before we get started:
    This is an aside from a series about Modular Themes.
    You should probably take a look at part 1.

    I’m sure some of you are wondering about the performance of get_template_module() and how it affects load speeds. From my tests, it doesn’t: Based on average template load time over 100 loads, Modularized Twenty Ten was seven hundred-thousandths of a second faster than vanilla Twenty Ten. For those of you who don’t like math, that means they were the same.

    Average template load speeds over 100 trials:
    Modularized Twenty Ten is faster by 0.0000741 seconds.
    Twenty Ten: 0.0410812 seconds.
    Modularized Twenty Ten: 0.0410071 seconds.

    In addition, I tested get_module_template() on a nonexistent module 100000 times using various template hierarchies:

    An average template hierarchy: (i.e. home, a post, a page)
    Total time to run get_template_module('fake') 100000 times:
    6.023 seconds

    Average time to run get_template_module('fake') once:
    .00006023 seconds

    A complex template hierarchy: (i.e. a category)
    Total time to run get_template_module('fake') 100000 times:
    8.0706 seconds

    Average time to run get_template_module('fake') once:
    .000080706 seconds

    If anyone would like (me) to conduct a more thorough test, please let me know.

    Modular Themes:
    Trac Ticket | Part 1: Why? | Part 2: Theme Organization | Download | Performance

  • Modular Themes, Part 2: Theme Organization 

    Modular templates provide us with a new way to organize our themes. In this post, we’ll discuss how separating theme structure from theme content reduces repetitive code and makes theme code easier to follow. The concepts are based on this belief:

    When you edit theme content, you shouldn’t have to copy your structure; when you edit theme structure, you shouldn’t have to edit ten files.

    These concepts are best conveyed through example, so we’ll take a look at how get_template_module() can benefit the theme structure in Twenty Ten. However, these concepts (and this example) can apply to any theme.

    A note, before we get started:
    This is part 2 in a series about Modular Themes.
    You should probably take a look at part 1.

    Repetitive Code, Revisited

    The two glaring examples of repetitive code are the loop and page structure. We’ve already addressed the loop, but things like get_header() and <div class="container"> show up in almost every file. In addition, we often see html elements broken across files—definitely not poetic code. You know it’s bad when best practice is to write </div><!--#container--> because you’d have no idea which <div> you were closing otherwise.

    The initial thought would be to encapsulate the opening and closing structure in two template parts, but the workings of get_template_module() suggest an even smoother practice. Currently, nearly all changes between theme pages have to do with the presentation of the content on the page, not the header, footer, or sidebars. What if, instead of repeating structure code on every page, we made a content module?

    Our Example: Twenty Ten

    Ladies and gentlemen, get your (hypothetical) themes ready. I’ll be using Twenty Ten to illustrate. I’ll refer to several of the html elements (such as #header) within the examples, but they should translate easily for any theme. Here’s a look at Twenty Ten’s structure, and how it’s broken across files:

    	<!--title, etc go here-->
    <div id="wrapper" class="hfeed">
    	<div id="header">
    		<!--header contents go here-->
    <!--END HEADER.PHP-->
    <!--BEGIN INDEX.PHP-->
    	<div id="main">
    		<div id="container">
    			<div id="content">
    				<!--page contents go here-->
    		<!--sidebar goes here-->
    <!--END INDEX.PHP-->
    	<div id="footer">
    		<!--footer contents go here-->
    <!--END FOOTER.PHP-->

    Creating a Content Module

    To isolate our structural code, we’ll begin by creating a content module:

    • Move all of the template hierarchy files into the content folder (save an extra copy of index.php).
    • Open each file, and delete all of the structural code. If you’re following along with Twenty Ten, save only what’s inside the #content element (but not the #content element itself).
    • Then in our copied index.php, delete everything inside the structure (for Twenty Ten, everything inside #content) and replace it with <?php get_template_module('content'); ?>.

    So Twenty Ten’s new index.php would look something like this:

    <?php get_header(); ?>
    	<div id="container">
    		<div id="content">
    			<?php get_template_module('content');?>
    		</div><!-- #content -->
    	</div><!-- #container -->
    <?php get_sidebar(); ?>
    <?php get_footer(); ?>

    This is now the only file where we’ll find the page structure. Want to change it for a specific page? Add a new file (say, category.php) and edit to your heart’s content.

    A Step Further

    While we’re no longer repeating structure, we’re still splitting HTML elements across files—namely header.php and footer.php. The header file is a curious beast; it includes both the head element, and the actual page header, which itself is comprised of a mixture of structure (i.e. <body>) and content (i.e. #header, logos, menus, etc.). These two are grouped together as a result of our current system because repeating the page header over and over is considered a form of torture.

    Now that index.php is readable (and short!), it makes sense to separate the two parts of header.php. We’ll use header.php for only the head element (if I had my druthers, I’d rename header.php to head.php).

    Creating a Header Module

    • Cut the page header (everything from the body tag down), and paste it into index.php right under the call to get_header().
    • Then, make your header content a module: cut out the contents of the <div id="header"> element (or your theme’s equivalent), and paste them into header/index.php.
    • In index.php, add <?php get_template_module('header'); ?> where you just cut the content (inside #header).

    Creating a Footer Module

    The footer is similar to the header—it’s part stucture, part content. We’ll do almost the same thing:

    • In index.php delete get_footer() (we won’t need it anymore) and replace it with the code in footer.php.
    • Cut the contents of the #footer element and paste them into footer/index.php.
    • In index.php add <?php get_template_module('footer'); ?> where you just cut the content (inside #footer).
    • Finally, delete footer.php; we’ve moved everything!

    The Results: Cross-file HTML tags? Only one!

    That’s right, it’s the html tag itself. Let’s take a look at Twenty Ten’s new index.php:

    <?php get_header(); ?>
    <body <?php body_class(); ?>>
    <div id="wrapper" class="hfeed">
    	<div id="header">
    		<?php get_template_module('header'); ?>
    	</div><!-- #header -->
    	<div id="main">
    		<div id="container">
    			<div id="content">
    				<?php get_template_module('content');?>
    			</div><!-- #content -->
    		</div><!-- #container -->
    		<?php get_sidebar(); ?>
    	</div><!-- #main -->
    	<div id="footer">
    		<?php get_template_module('footer'); ?>
    	</div><!-- #footer -->
    </div><!-- #wrapper -->
    <?php wp_footer(); ?>

    It’s a little longer than before, but now all of the theme structure is located in the same file. If you look up at the overview of Twenty Ten’s structure, you’ll notice that only the opening html tag and head element are missing. Now, header.php contains the entire head element, while index.php contains the entire body element.

    Let’s run down where our code is now located:

    • header.php: Dedicated to the head tag. Opens the html tag.
    • index.php: Dedicated to the body tag and theme structure. Loads the other modules. Closes the html tag.
    • the “content” directory: Contains our original template hierarchy files, without the structure. Parent element: #content.
    • header/index.php: Contains header content. Parent element: #header.
    • footer/index.php: Contains footer content. Parent element: #footer.
    • footer.php: Doesn’t exist anymore!

    Wrapping Up

    More generally, this development pattern dedicates the root template hierarchy to theme structure, and the content, header, and footer directories to theme content. Since all folders apply the template hierarchy, themes become incredibly extensible. Code becomes much easier to pinpoint and customize, which is especially helpful when creating a child theme.

    It’s important to note that this development pattern does not rid us of repeated code—only a massive file with lots of conditionals can do that. Instead, it attempts to reduce repeated code by separating content from structure. As I wrote earlier: When you edit theme content, you shouldn’t have to copy your structure; when you edit theme structure, you shouldn’t have to edit ten files.

    Want to download this post’s example?
    Download Modular Twenty Ten.

    A Few Extra Thoughts

    Shortcut functions: Like this development pattern? We could propose shortcut functions to establish a naming convention: get_content_module(), get_header_module(), get_footer_module() could load modules from the content, header, and footer directories, respectively. Note that these are not part of the current patch.

    Performance: I’m sure some of you are wondering about the performance of get_template_module() and how it affects load speeds. From my tests, it doesn’t.

    The function name: I am by no means set on the name get_template_module; I just needed something to work with! Ptah Dunbar suggested get_template_file, which is likely a better fit. Any other ideas?

    On sidebars: Some of you may be asking why I shied away from modularizing sidebars (in fact, if it helps a theme, I’m all for it). Here’s the issue: get_sidebar() has an optional parameter that acts like get_template_part()‘s optional parameter. In cases where get_sidebar('optional') were called, you’d have to write the following:

    if( ! get_template_module('sidebar-optional') )

    Of course, that could easily be encapsulated in a function get_sidebar_module().

    On the <html> element: I realize that I could have had zero cross-file tags if I moved the opening html tag into index.php, but I think the DOCTYPE declaration is a natural companion to the head element.

    The <head> element could be module: Yep, it could! If your theme’s head could benefit by becoming a module (read: “has a lot of template conditionals”) go for it.

    If you’ve made it this far, thank you for reading! I’d love to know what you think.

    Modular Themes:
    Trac Ticket | Part 1: Why? | Part 2: Theme Organization | Download | Performance

    Comments Permalink | Comment
    • Jean-Patrick Smith 10:16 am on April 16, 2010 Permalink | Reply

      Awesome structural change, will implement ASAP. Thanks, tweeting…

    • Konstantin 2:42 pm on May 18, 2010 Permalink | Reply

      Wow, I LOVE it!
      Came across your presentation on and already liked the idea, but wasn’t able to comprehend it on base of the video itself.
      Great way of thinking, I will definately implement it.
      But I disagree respectfully on the part with the -tag in the header.php file ;)

    • Jason Pelker 1:42 pm on May 20, 2010 Permalink | Reply

      Do you mind if I use some of your examples in this post for a presentation I’m giving at WordCamp Chicago? I’m speaking on how to improve themes and modularization would make an excellent section of the talk. Thank you in advance.

    • Dan Gayle 8:49 pm on July 8, 2010 Permalink | Reply

      The way you’ve used header.php for the element and index.php for the element is exactly the way I’ve been building themes for a while. Breaking HTML across different files sucks, and it usually requires extensive commenting (I use PHP // comments for this rather than cluttering up the rendered html).

      I’ve been working on building modular themes, and I always come back to just having one template file (index.php) and each of the different “loops” and sidebars withing a separate lib directory.

      • Dan Gayle 8:50 pm on July 8, 2010 Permalink | Reply

        Sorry, comments filtered out the html tags. The first sentence should read:
        The way you’ve used header.php for the <head> element and index.php for the </body>
        element is exactly the way I’ve been building themes for a while.

    • Lee Willis 8:31 am on September 17, 2010 Permalink | Reply

      Yes, yes, and thrice yes.

      I’ve had a bit of an issue with this recently – see here:

      @nacin pointed me here, and what you’re proposing is mostly what I would have written up – although you’ve undoubtedly done it more elegantly that I would have!

      One area this doesn’t cover (That I saw), was splitting “archives” (Whether they’re date, category, custom taxonomy term, whatever), into:
      a) The fluff around the list (Introduction text & , ?)
      b) The list items themselves (archiveitem.php)

      You’d also want to allow differentiation based on content type, so archiveitem-post.php versus archiveitem-customposttype.php.

      The same applying for single item view (item-post.php versus item-customposttype.php)

    • Alex Koti 11:56 pm on February 4, 2011 Permalink | Reply

      Great improvement! Will be in the new version(3.1)?

  • Modular Themes, Part 1: Why? 

    Have you ever wanted to change a class in the loop? You’re likely going to have to edit upwards of five files. The worst part? Most of the code you’re editing is identical.

    A note, before we get started:
    If you already know about get_template_part(), you’ll probably want to skip down to the section entitled “Using get_template_part() to Simulate the Template Hierarchy”.

    If you’ve seen my session at WordCamp Ireland, this will seem very familiar.

    What causes repetitive code?

    As theme developers, our needs and our development pattern form a paradox: We need the ability to completely change any page, but most of the time we only change small sections and want to keep the rest in sync.

    The problem lies in how our code is organized. In the current system, each file represents a page within the template hierarchy. However, we often don’t want to change the entire page, but a small section of code. As a result, we copy large chunks of code to a new page.

    The system does not provide us with a viable way to manage code blocks below the page-level scope. At the moment, we have three alternatives:

    1. Copy code, and create a new page.
    2. Use template conditionals such as is_archive().
    3. Encapsulate your code in a separate function.

    While template conditionals have their place, they must be used in moderation. Otherwise, files quickly become bloated and unreadable. Functions are a little trickier: at first glance, they seem to be an ideal solution. Combined with template conditionals, they can produce the desired results without swelling template files. The problem? PHP functions cannot be overridden.

    When you define a function in a parent theme, it cannot be changed in a child theme. To tweak the code found in parent_page_title(), a child theme will have to copy parent_page_title() into a new function, child_page_title(), and then copy every theme file that calls parent_page_title() and replace it with child_page_title(). That’s like the Grand Poobah of repetitive code.

    The First Step: get_template_part()

    Okay, so if you’re using the latest beta (or trunk, if you’re awesome), the current system has a treat for you. In WP 3.0, theme devs get new function for their toolbox: get_template_part(). In the words of the documentation:

    get_template_part() “makes it easy for a theme to reuse sections of code in an easy to overload way for child themes.”

    Sounds good, I’ll take two. This function is just what we needed—now we can call get_template_part('page-title') and WordPress will load page-title.php, and even check the child theme first.

    get_template_part() has an optional second argument that will first look for a specific version of the template. So if we were to call get_template_part('page-title', 'special'), WordPress would first check for page-title-special.php, and if that’s not found, look for page-title.php.

    Using get_template_part() to Simulate the Template Hierarchy

    As the new default theme on the block, Twenty Ten sets a good example for theme developers everywhere. Let’s look at how Twenty Ten uses get_template_part():

    • In archive.php: get_template_part('loop','archive');
    • In author.php: get_template_part('loop','author');
    • In category.php: get_template_part('loop','category');
    • In index.php: get_template_part('loop','index');
    • In search.php: get_template_part('loop','search');
    • In tag.php: get_template_part('loop','tag');

    As you can tell, Twenty Ten uses get_template_part() to load the loop. While doing so, Twenty Ten loads custom versions of the loop in a fashion identical to the template hierarchy. Note that Twenty Ten only defines loop.php; it anticipates that child themes will use the more specific files.

    I think that taking the template hierarchy into consideration when creating template parts is a fantastic idea, but I have a few problems with this implementation:

    1. The burden is on the user to implement the template hierarchy. What if the theme only defines archive.php? If the author wants to include a category-specific template part, they’re back to template conditionals or copy/paste.
    2. There is no naming convention. Yes, Twenty Ten follows the template hierarchy’s naming conventions, but what if a theme references “cats” instead of “category”, or ”archives” instead of “archive”? There is no way to know without inspecting the theme files.
    3. Only part of the template hierarchy is implemented. In a Twenty Ten child theme, what if a user defines loop-date.php or loop-category-news.php? Their code will never be called, and again, they won’t know why until they read through the theme files. Developers who aren’t familiar with PHP will likely end up bewildered. Silently failing is bad.

    This begs the question:

    Instead of simulating parts of the template hierarchy, what if we just applied the template hierarchy to template parts?

    Modular Themes

    Well, we can. I’ve proposed a function get_template_module() that loads the best match in the template hierarchy from a given folder. While get_template_part() still has its place, get_template_module() is ideal in situations where a theme developer wants to vary a block of code depending on the template hierarchy.

    Using Twenty Ten as an example, we would move loop.php to loop/index.php, and replace all calls to get_template_part() with get_template_module('loop').

    When you’re viewing the “News” category, with category-id 4, get_template_module('loop') checks for the following and loads the first match:


    Not Just for the Loop

    get_template_module() has a whole bunch of uses, including potentially changing the way we organize our themes (which, incidentally, is the subject of my next post). Want to see get_template_module() in core? Read the trac ticket.

    Modular Themes:
    Trac Ticket | Part 1: Why? | Part 2: Theme Organization | Download | Performance

    Comments Permalink | Comment
    • Alexandre Simard 10:24 pm on May 1, 2010 Permalink | Reply

      Hey Daryl! I remember talking to you in the bar after the Day 1 of WordCamp NYC. I had seen your presentation of Elastic. My impression was that you had a ton of great ideas, but that your project was perhaps too ambitious for its own good. You were talking about pretty much rewriting from scratch the WordPress template engine.

      I’m happy to see you’ve come around to appreciate the default engine for what it provides. Your proposed additions are very simple, yet they open up a world of possibilities, not just for Elastic, while staying true to the spirit of WordPress’s template engine.

      I think you’ll find a lot better support from other developers for your new ideas. I, for one, am very enthusiastic about them and can see myself contributing to them much more easily than with the previous Elastic incarnation.

      Keep up the good work!

    • R'phael Spindel 7:20 pm on May 29, 2010 Permalink | Reply

      I agree.. much better approach. I’ve waited for get_template_part to be included in WP, and now, I will wait for get_template_module!!!

    • martcol 12:54 pm on December 1, 2010 Permalink | Reply

      Thanks for that.

      I’m a bit of WP novice here but I’m interested that the codex, as you quoted, says “makes it easy for a theme to reuse sections of code in an easy to overload way for child themes.”
      Is it meant to be “overload?” That sounds like a bad thing, or am I missing something.

    • Joel 11:38 pm on December 13, 2010 Permalink | Reply

  • GSoC Proposal: Visual CSS Editor 

    Please note that due to the personal nature of some sections of the WordPress GSoC proposal template, this post only contains the project description and schedule of deliverables for my proposal.


    In short, I would like to create a CSS editor that will be easily integrated to existing themes and provide users with a better alternative to theme options.

    As some of you may know, I worked on a similar project for WordPress in last year’s summer of code. This proposal represents a year’s worth of thought and revision with regard to the larger subject of theme editing and development. Put simply, this is what I want to do this summer.

    User Groups

    Theme editing is tricky business: there are many user groups to please. As a general rule of thumb, I plan on targeting users with least experience (to reach the broadest audience), and providing additional functionality and extensibility for more advanced users.


    • The average WordPress user serves to benefit the most from an interactive theme editor as they currently have no similar tools at their disposal. As a result, we cannot assume that users know CSS, and must design the UI accordingly. If and when features are added for developers, they should be added in a separate “developer mode” so as not to overwhelm the average user.


    • Many theme developers are unfamiliar with PHP (despite the fact that it’s the backbone of WordPress). Beginners should be able to easily add CSS editor support to a theme. Easy-to-understand APIs will both result in fewer errors, and increased usage. That said, we should not sideline advanced developers; providing advanced APIs and adding hooks will allow advanced developers to tweak functionality and extend the editor through plugins.


    Iterate, iterate, iterate.

    User Interface: This plugin should look and feel at home in the WordPress admin panel. I plan on getting UI feedback from Jane and if willing, #wordpress-ui. If released, I plan on following the forthcoming WordPress UI guidelines.

    Extensible: Like WordPress, the plugin should be light and extensible.

    Core Features

    Edit CSS through a GUI:

    • The core function of the plugin; users will be able to edit CSS using a visual GUI, and view their modifications in a live preview (if they’re editing the activated theme, site visitors will not see changes until they are saved). Elements of the GUI are described further below.

    Theme developers specify which elements are editable:

    • To prevent potentially thousands of HTML elements from overwhelming the end user, theme developers will register editable CSS selectors with the editor. Developers will provide selector descriptions (i.e. “the post header”) and manage editable properties to prevent users from breaking the theme.

    Central event bus:

    • The UI elements will communicate through a central point using custom JS events. This allows for rapid iteration and makes the UI extensible.

    Automatic child themes:

    • Since we’re altering the CSS, it makes sense to automatically generate child themes upon modification. This project would benefit immensely from a theme revision API being implemented in core, as much of the following would already be implemented (and then some). By saving child themes in a custom post type, the plugin can gain theme revisions, MultiSite support, and inherit media features from the post editor. However, the plugin would also have to be capable of exporting these themes, and alter the “Manage Themes” page to display them as well.

    Developer Features

    Edit CSS with live preview:

    • Strip away the GUI and provide a text editor in its place, allowing users to edit the child theme’s CSS and see results live. The plugin could embed the WordPress core theme editor, provide client-side validation, and apply updates live.

    Multiple active sessions and cross-browser preview:

    • By allowing users to have multiple active sessions, the plugin editor could provide cross-browser preview. This has several nice implications, such as allowing users to make the CSS editor full screen and see updates live in other browsers. If average users have the ability to edit CSS properties that are not supported in all browsers, this could be of use in the plugin core. Implement this by keeping track of the sessions in PHP. When certain events pass through the Event Bus, send them to the server, which will push them to the other sessions via ajax with long polling.

    Edit CSS Properties: Features & UI

    Users will be able to edit CSS properties for specific selectors. Some features/UI:

    • Users can select elements either by hovering over elements (akin to Firebug’s “Inspect” feature), or selecting elements from a list/dropdown.
    • Like properties will be grouped together as tabs in the UI.
    • Color-based properties will present users with a color picker and a color palette (consisting of other colors within the theme), and also accept hex values.
    • Image-based properties will hook into the WordPress media library, and take cues from custom-header.php and custom-background.php in presentation and function (use wp_handle_upload, etc).
    • Properties with various set text values (i.e. border-style) will have options presented in either a dropdown or a radio button-set (think align left/center/right in TinyMCE) depending on how many options are available to the user.
    • Numerical properties will present users with a “value” slider and a “units” dropdown (or radio button-set).
    • To edit margins and padding, users will be shown a visual box model (a box inside another box for padding and margins, respectively). Top/bottom/left/right values are positioned according within each box, and are clickable; once selected, they can be edited like a regular numerical property.

    Potential issues:

    • Not all browsers implement the same CSS properties; certain properties, like opacity, will have to be normalized across browsers. However, the trickier issue is how to deal with browsers that don’t implement a given CSS property (such as text-shadow). One option is to simply not implement them (which is viable, since most, if not all, are CSS3). Otherwise, there would have to be a system to warn the end user if they were using an incompatible browser (as they would see no changes), and warn them of other incompatible browsers.

    Feature: Color Palette Editor & Dynamic Selections

    Color palette editor:

    • Color is a huge part of theme design. Users will be able to quickly change their theme’s color scheme, without repetitive clicking (or the chance of missing a property).
    • This wouldn’t be revolutionary to developers; it requires a simple find/replace.

    Dynamic selections:

    • These are element-filters. Users could select all elements where property X equals Y, and then modify their CSS. (You can almost think of it as SQL for stylesheets, but with a friendly UI).
    • A color palette editor requires the dynamic selector: “Select all elements where any property is a color.” As a result, it makes sense to (at the least) include dynamic selectors in the editor API. The question is: do we expose it in the UI?
    • This is incredibly useful for developers dealing with complex properties such as background or border: Want to select all borders that are 1px wide and dotted? Simple. In a text editor, not so simple (unless you already know what you’re looking for). Matches include:
      • p{ border: 1px dotted; }
      • p{ border-width: 1px; border-style: dotted; }
      • p{ border: 1px white dotted; }
    • For users, usage of the raw feature is questionable, and has the potential to overwhelm. However, it could become more palatable in the form that lets users say “Select all elements like this.”

    Plugin, theme, or core

    I believe the editor would be a good candidate for a core plugin. If the editor is lightweight enough and the community was behind it, parts of the editor could be integrated into core.


    I’ve done a considerable amount of research on numerous topics surrounding the editor. Most of them are quite technical (such as the benefits of using the native DOM StyleSheet over a JavaScript CSS parser, and the effects of browser reflow), and I don’t want to overwhelm you with implementation. If you’d like me to post a more in-depth technical analysis, please let me know. Here is one example:

    I’ve played around with several ways of designing the API for themes to register selectors with the editor. While I initially thought that registering selectors in the PHP was the best option, I now plan on using CSS, as more developers are familiar with the language, and the notation is more concise. This CSS will be located in a separate file (such as visual-editor.css), and could either be automatically read or triggered by add_theme_support(‘visual-css-editor’). I’ll leverage custom properties to detect descriptions and registered properties.

    Example syntax would look as follows: {
    -editor-description : “The site header”;
    -editor-add-property : “background font”;
    -editor-remove-property : “line-height”;

    This file would be read in the PHP, and sent to the JS as JSON. If a plugin registers an action to “visual_css_editor_selectors”, the JSON could be converted to a PHP array, passed through the action, and converted back to JSON.


    One of the larger challenges will be developing a UI that users are comfortable with. This will require a considerable amount of user testing and revision, which I am prepared to do. This project entails heavy use of JavaScript and jQuery, and I am quite experience while using both. As I learned from last summer, maintaining JavaScript code is difficult. If left untended, files can grow to massive sizes and be incredibly hard to read. I plan on separating my JS into numerous pieces that will be concatenated together using Sprockets.


    In discussions in both wp-hackers and #wordpress-gsoc the idea has been met with positive feedback. Andy Skelton suggested the idea for cross-browser preview, which I think is a fantastic feature. Jeremy Clarke suggested looking into other similar plugins, which I have done, and plan on doing further. I received additional help and feedback from Ptah Dunbar, who helped me solve issues with the Same Origin Policy; Andrew Nacin, who discussed how a core theme revisions API could benefit the editor; and John James Jacoby, who discussed the API for registering CSS elements. Finally, Beau Lebens, my mentor from last summer, has provided continued help and feedback.

    Potential mentors

    I’d love to be mentored by anyone who is interested in the project, and likes talking about the best way to implement a feature (also, long walks on the beach, chocolate covered strawberries…).

    Noel Jackson expressed interest, as did John James Jacoby, provided he doesn’t mentor a BuddyPress project. Beau expressed interest as well, and has already heard much regarding the scope of the project.

    Schedule of Deliverables

    I am proposing a condensed schedule consistent with WordPress GSoC custom, and plan to have a working version by midterm evaluations. This project has intensive UI requirements, and I plan to continually user test and refine as I develop new features. In addition, this schedule allows for the inevitable roadblocks, tweaks, and bugs I’ll face along the way.

    • Week 1: Make wireframes, write core JS events system. Do research, and read lots and lots of code.
    • Week 2: Build APIs for live CSS editing and generating the resulting stylesheet.
    • Week 3: Begin to build UIs to edit CSS, excluding media features. User test.
    • Week 4: Continue building and refining UIs. Color pickers, sliders, etc, should all have prototypes by now.
    • Week 5: Add theme saving and management using custom post types, or a core theme revisions API. Begin building cross-browser preview.
    • Week 6: Continue testing theme saving/management. Finish cross-browser preview. Begin media features.
    • Week 7: Complete media features. Midterm evaluations. Prototype complete!
    • Weeks 8-12: As per WordPress GSoC custom, dedicated to debugging, documentation, and refining the project.

    Other commitments

    I will be abroad and taking exams during the community bonding period, so my time will be somewhat limited. By the start date, my exams will be over, but I will still be in the UK (and coding!). I’ll likely return home that week.

    Tags: gsoc,
    Comments Permalink | Comment
    • Asif 4:56 pm on April 24, 2010 Permalink | Reply

      Hi Daryl,
      Nice work that you decided to do. i think it would be great tool for the Developer which allows seamless & Live visual Css Editing without losing the functionality.
      I really admire your efforts.


    • R'phael Spindel 7:17 pm on May 29, 2010 Permalink | Reply

      @Daryl Definitely looking forward to seeing what your work produces. Could very well be one of the top 10 promising WordPress projects of 2010

  • Hello world 

    Well, hello. Lately I’ve come across the desire to share thoughts, code, and random minutia that falls outside the scope of the project blog. That desire, combined with my blatant lack of a web presence and love to tinker has led me here. It also gives me a wonderful excuse to play around with all the new features in the WordPress trunk.

    The design you see now is a child of the illustrious P2, which provides a nice blend between stream-of-consciousness and essayist blogging. The visuals aren’t set in stone by any means; at the time of writing, the site doesn’t even have any widgets (the horror!). What’s a personal site, if not a work in progress?

    In the near future, you’ll likely (hopefully?) hear about the Google Summer of Code, tidbits from Europe (especially Edinburgh), and anything else I feel worth sharing.

    Comments Permalink | Comment
compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help