Link: CSS sprite generator
If you ever find yourself needing to manually build CSS sprites, do yourself a favour and shoot yourself in the head. Then download this Photoshop script and use it.
Arnau March – CSS sprite generator.
(via Chris Coyier)
Recent Updates Page 4 RSS Toggle Comment Threads | Keyboard Shortcuts
-
Mohammad Jangda
-
Mohammad Jangda
[[Prototype]] vs prototype (Peter van der Zee on JSMentors)
Here’s a great explanation (by Peter van der Zee) of the key differences between [[Prototype]] and prototype in JavaScript. It finally makes sense now!
Note: to understand this explanation it would help to know what prototype is/does and how it works.
So we have [[Prototype]] and prototype. You can see prototype as the parent object to which [[Prototype]] (so __proto__) refers to on instances of the constructor. Hah, I’m sure that’s not confusing. So let me give an example :)
var A = function(){};
var a = new A();
log(a instanceof A); // true
log(A.prototype); // object
log(a.prototype); // undefined
log(a.__proto__); // object, in browsers that support the mapping
log(a.__proto__=== A.prototype); // true.“A” has a prototype property (A.prototype). If you add new properties to that object, they will automagically be available on “a”. “a” has a [[Prototype]] internal property. It refers to A.prototype. It is an essential part of the prototypal chain because it actually determines the next part of the chain. If you change a.[[Prototype]], changes to A.prototype will no longer be reflected on “a”. In fact, all not “own” properties of a will no longer be accessible and are replaced by a new set of properties.
via [JSMentors] Object creation.
-
Mohammad Jangda
Link: HackMTL was a blast! Montreal represented! « HackMTL
HackMTL was a blast! Montreal represented! « HackMTL
HackMTL was an awesome time. Lots of great food, code, fun, people, and more. Scoring second place didn’t hurt, either ;)
Oh, and more events HackDays events to come!
-
Mohammad Jangda
Link: Use console.app to view MAMP logs in OSX
Quick Tip: Use console.app to view MAMP logs in OSX by Roger López
I live by console.app now; it’s perpetually running in the background.
-
Mohammad Jangda
Dogfooding Edit Flow
Note: Most of the code here is specific to my environment on Webfaction, github and for use with WordPress plugins. You can make it work for other setups (i.e. different hosts, local gits, or even SVN) but will involve some tweaking.
Scott recently had a great idea to run the bleeding edge release of Edit Flow on our official site. I usually do this for most of my plugins before releasing, though, it’s a manual process: FTP up the latest code and give it a test run. That’s not fun.
Here’s a far better, automatized way to keep your repo up-to-date. You can either use cron or githooks. Pick your poison.
-
Mohammad Jangda
Edit Flow v0.6
We pushed out Edit Flow v0.6 last week. We’ve got a couple new features, cleanups, and bug fixes, all outlined on the official blog.
Excellent work by Scott, Andrew, and Daniel (and anyone and everyone else who’s helped us along the way) on getting this out the door.
More awesome coming soon, so stay tuned.
-
Mohammad Jangda
WordPress Plugin: Introducing Custom Metadata Manager
With the custom post type enhancements introduced in WordPress 3, site builders and plugins developers now have access to what you could call “dynamic scaffolding”. With a couple of lines of code, you can easily generate the necessary UIs to help users easily manage and create new types of content.
You can add new post types (e.g. Movies, Reviews, Products, Projects, etc.) and specify the features each should support (e.g. title, body, authors, revisions, etc.) . Beyond that, you can add use the ever-flexible hook and filter system to add your own features. Combine that with custom fields and you can add your own fields (so a “movie” post type can have new fields to add things like “release date”, “rating”, and so on) .
However the code involved in adding those additional fields can get cumbersome, especially when you start looking at lots of content types with numerous fields. Add in other object types like users and comments and you’re now looking at a huge code base that needs to be maintained, updated and so on.
Well, I’m making it easier.
Overview
Custom Metadata Manager introduces a very WordPress-like way of adding additional fields to your object types. The goal is to help you rapidly build familiar, intuitive interfaces for your users.
Consider this:
That one line of code kicks into gear some of that “dynamic scaffolding” magic I mentioned earlier. The Edit Post page now has a metabox with a text field. The plugin handles all the heavy-lifting for you behind-the-scenes, so that you can focus on more on building out and connecting your data rather than all the minor details. Checkit:
A magical new field with one line of code!
The API is similar to that used for registering custom post types and taxonomies so it should be familiar territory.
Object Types
But let’s not stop there. Let’s say I want comments and users to all have this magical new field. Let’s try something like this:
And we get the same field added for users and comments!
A magical new field for users with one line of code!
Note: I’ve omitted a screenshot for comments since it looks exactly the same as the posts screen.
Custom Metadata Manager supports fields for:
- posts (built-in and any custom post types)
- comments
- users
If/when links and taxonomies get metadata support, I’ll add support for them as well.
Labels and Descriptions!
Avoid cryptic slug-like names and make it easy for users by assigning friendly labels and descriptions!
'Field Label', 'description' => 'This is a friendly description for the field to help you enter your data.' ) ); ?>
Groups
To avoid clutter on the Edit Post page, you can group sets of fields together.
'Group' ) ); x_add_metadata_field( 'field-1', 'post', array( 'group' => 'group-1' ) ); x_add_metadata_field( 'field-2', 'post', array( 'group' => 'group-1' ) ); ?>
Field Types
Text fields can get boring, so I’ve cooked in a number of different field types (just specify the field_type in the $args parameter and go!):
All sorts of different field types
Custom Callbacks
Notice that last one in the screenshot above? That’s using a custom display callback! You can override a bunch of different things (display callback, sanitize callback, etc.) to get even more control over the fields you add. That means you can do cool stuff like this:
Custom callbacks make custom fields even more fun!
Columns
We’ll throw in an easy way to add your fields to the Manage Post/User/Comments pages as well (in your $args, just set display_column to true). By default, the column will just the value of the field, but if you’ve got something complex going on, you can just as easily include a display_column_callback.
Columns made easy!
Example Code
I’ve included fairly detailed docs on Extend and for kicks, I’ve thrown in example code along with the plugin. (To see it in action, turn on WP_DEBUG.)
Why this plugin?
Don’t get me wrong: this isn’t anything revolutionary. Lots and lots and lots and lots have come before me. But my approach is probably the most “WordPress-like” there is (Bonus points to Easy Custom Fields which uses a code-based and very object-oriented approach).
The API is simple, intuitive and very flexible, providing lots of overrides if you don’t like the default functionality (or have specific use cases).
The plugin doesn’t use extra tables and stores all data in a WordPress native way, so you can use the standard get_metadata function to retrieve your custom data. That way you also don’t have to worry about losing your data should you choose to stop using this plugin.
(I have already deployed and used the plugin across a number of production sites and it’s working great and saving me significant amounts of time and code!)
Why a code-based approach instead of a UI?
Because most of the plugins I mentioned above do the UI thing (and some it really well!) and it’d be lame to just copy them. The code-based approach, though, more closely aligns with the existing WordPress approach of registering new types of content (post types, taxonomies, etc.).
This is also a developer feature, aimed towards site builders. And real developers don’t need UIs ;)
TODOs
What stuff am I cooking up for future versions?
- Improved styling of rendered fields
- Ability Pass in attributes for built-in fields (e.g. class, data-*, etc.)
- Additional field types
- Limit or exclude groups and fields for specific ids (e.g. show only on post id = 145)
- Autosave support for fields on post types
- Option to enqueue scripts and styles
- Client- and server-side validation support
- Add groups and fields to Quick Edit
—-
Download
Grab it from the WordPress Plugin Directory or just search for “Custom Metadata Manager” from the Plugin Manager within your WordPress install.
If you’ve read all the way through, thanks! Like what you see? Want more field types and features added? Just want say hi? Get in touch.
Mohammad Jangda
Plugin Update: Plugin Notes v1.1
I pushed out an update to Plugin Notes last week bumping up the version number to 1.1. Only three changes in this update:
- Ability to add select HTML tags to notes, so you can now do cool stuff like the image above. Full list of allowed tags available here. (Thanks to Dave A. for the suggestion)
- Fixed a bunch of PHP Error Notices that were popping up across the plugin (thanks to WP_DEBUG)
- A small styling fix
Mohammad Jangda
Mohammad Jangda
Plugin Update: Zen v1.1
I pushed up v1.1 of Zen yesterday. Not much changed in this new version. Key improvement is that the content textarea is now a bit bigger so things don’t look really disproportionate on larger resolutions.
I’ve also added 3 new themes:
Zen Sea & Sky
Zen Sunset
Zen Foiled Again (My new favourite)
Daniel Bachhuber 10:01 pm on November 16, 2010 Permalink |
Awesome, thank you for documenting this. As an FYI, there’s an easier way to get Git on your WebFaction account.