I'm not a Ruby developer, so I can't comment if this makes it easier for someone who lives in both Rails and Wordpress, but as someone who has to occasionally make a custom Wordpress theme and has no experience in Rails, this looks like a lot of complexity just to put together a theme. However, I could see this being very nice for someone whose time consists mostly of Wordpress themes, and you obviously put a lot of work into it, so I don't want to write it off. It's cool you were able to make such a feature-rich Wordpress plugin.
Just to make sure: the production/live machine doesn't need the Wordless plugin, correct? Basically you use the Wordless plugin on the dev machine then just distribute the created theme directory like normal? Or am I off-base?
ceol, that's almost correct. you need to keep the plugin also on your production server, but the compiled assets gets "baked", so wordpress just serves static files.
Gotcha. Thanks for your reply. Do you have any plans to include some sort of "conversion" functionality that turns Wordless themes into standalone themes that dont' require the Wordless plugin? I could see a lot of people who make and sell Wordpress themes using this like crazy, but the dependency might turn away most of them.
Well, there's not a "conversion" tool in the near roadmap. But you can somewhat easily drop this plugin inside a theme, require it and bundle everything together.
This seems like an awful lot of extra layering on top of WP's horribly ugly theming system... And adding Ruby as a requirement? What about building on PHP-based tools like Assetic, or a cleaner template format?
I've never understood why people were willing to jump through so many hoops building themes in WP's messy way.
As a comparison, here's a complete theme (based on the Twitter Bootstrap toolkit) for my current PHP-based project (self-promo, but illustrates the difference well IMO):
One HTML file, Bootstrap + one short CSS file, zero mixing of PHP code. Most WP alternatives offer similar theming, either Mustache-based like the above is based on, or Twig, both of which are much much cleaner options IMO.
I'm mainly an HTML and CSS guy, and know a healthy amount of PHP.
But I don't know enough to set up a server, databases, write a CMS from scratch (well, maybe I could), and I don't like spending a lot of time in the Terminal. I'm not a programmer.
Even as a designer, I'm able to use WordPress' powerful theming system (which is pretty easy to understand and, in my opinion, not ugly at all) to build out an entire easy-to-use site for a client without having to also hire a developer. The WordPress community is massive and helpful, PHP is well-documented and simple to work with if you know HTML, and you can literally use WordPress to make almost anything on the web. Maybe it would be better theoretically to hire a developer or learn to be one, but I don't like hardcore programming and sometimes just don't need a developer that I have to pay for, wait for, etc.
WordPress, in a way, makes the ability to make simple web apps, dynamic sites, and blogs a more democratic thing; many people can pick enough WP knowledge in a few weeks to do things that would take months or years of programming training.
From the point of view of an experienced software developer, writing a Wordpress theme is an ugly job because the Wordpress API is inconsistent, incomplete and badly documented.
Just as an example, it is better to make an app like BaseCamp or Campfire with Ruby on Rails than WordPress. But I can learn enough in a matter of weeks to make something like the P2 Theme (http://www.p2theme.com) with WordPress; god knows how long it'd take me to go from completely zero programming knowledge to the level required to build the same thing in RoR
Yeah, but if a client wants something custom you're stuck either modifying an existing plugin, or creating a new one, and creating Wordpress plugins is a godawful mess.
See, I still disagree. Working with WordPress has been nothing but (relatively) easy for me, even when making relatively complex plugins.
No one is arguing that WordPress is better, necessarily, than a custom build. But reality trumps theory. Theoretically a perfect diet may be out there, but if you can't afford it and won't adhere to it, for example, a less-theoretically-perfect diet that you can afford and can actually follow is better.
A lot of times I or my client can't afford a developer for a custom app. WordPress solves that problem, and I think it's only getting better, simpler, and more stable with time (as all open-source projects kinda do).
Wordpress provides little structure of framework for your plugin. There are plenty of hooks and functions to use, to integrate with each step of the rendering process, but other than that, you're on your own. Each plugin tends to provide it's own miniframework... or lack of one. A plugin tends to look like it's own self contained PHP web site from 2005.
Trying to integrate several different WordPres plugins is a challenge, as they each tend to be written in their own style.
It's php, there are a lot ways to write code that result in desired functionality - that's a plus in my book. There are thousands of differents types of programmers writing plugins for WordPress - more than any other open source project, so it's darn obvious there are going to be lots of different ways plugin writers approach their plugins.
Having said that, there are guidelines and best practices found in the codex (for one, all the hooks and filters that are available which are generally well documented) and there is some quality control when submitting plugins to the WP directory. In addition to that there is a fantastic handbook (professional WordPress plugin development) that gives both beginners as well as veterans a healthy education in the best ways to write plugins. And there's a big blogging community writing detailed tutorials.
I'm not sure what you mean with integrating plugins - what does that accomplish? Most plugins run fine when running concurrently on an install.
A lot of these criticisms toward WordPress in this thread are a bit ridiculous if you ask me. Yes it's written in PHP, big deal. Yes there's a lot of code that if written afresh today would look different. Yes there's variable quality in code written by various plugin/theme developers. At the end of the day WordPress is plain accessible for people - and that is a big reason for its success.
I started out years ago knowing zero about code to where I am today. My first plugin was shit and know I'm getting pretty good at it. Because developing on WordPress has been so much fun I taught myself Php, html, css, javascript (including ajax and jquery). Clearly, I'm not the only one as it is the most active community of all the CMS choices out there - and a lot of people are making a living thanks to it.
My point was that raw PHP is a little too unstructured and powerful for the tasks that many plugins are made to accomplish.
By integration, I mean adopting plugins from various authors and making them work as part of your theme. There are all sorts of issues involved... random visual design, clashing HTML doctypes, possible poor coding, adding functionality, fixing security issues... creating a coherent, secure and functional site by piecing together various WordPress plugins is not as easy as installing some plugins and whistling off into the glorious sunset. Simply finding a plugin for a certain purposes which actually works can be a challenge.
I wasn't attempting criticize WordPress or PHP in general, just the quality of the average plugin and the lack of consistency and order.
>>Ability to write PHP code using the beautiful Haml templating system;
>>Ability to write CSS stylesheets using the awesome Sass syntax [...];
>>Ability to write Javascript logic in Coffeescript;
Some may like that, but I want to write my PHP in PHP, and write my CSS in CSS, and write my JS in JS. I really never got why I would write one language in another language just to then use some tool to translate it (and if it gets a little complicated have to manually fix translation problems afterwards). Can someone explain please?
By similar logic scala is useless since it just targets the JVM as does Java. Hell, why use Java at all when you could just write JVM bytecode by hand?
Coffeescript, haml, and sass are useful because they reduce the complexity of coding html, css, and js. They allow you to get much more bang for your developer-hour buck. Why use jQuery when you can just talk to the DOM directly?
HAML and SASS offer higher-level abstractions. They leak, but rarely enough that the cost of an occasional context switch (to debug generated code) is outweighed by normal productivity games. It's a good trade.
You'll never need to doctor the generated code, by the way. Anything you'd want to do in HTML or CSS can be done in HAML or SASS.
Exactly, using higher level languages is a matter of DRY (Don't Repeat Yourself) and normalization (specify things in one place, have them change everywhere consistently).
Especially for CSS this is really useful as in itself is a crude, low-level language, things can quickly become very verbose especially if you consider cross-browser compatibility for the fancier effects.
I agree with you, but I think the claim is that for those familiar with language variants like these, it is possible to be more productive. It is, of course, also more difficult to find collaborators familiar with non-standard variant languages.
Well, you are not writing PHP, CSS and JS. You are writing an application (or a part of it), and these higher level languages allow you do that more efficiently, that's all.
No, I think you're wrong. It's not for everyone but I highly recommend you look into one of these. I'd say look at LESS or SASS (they're basically the same) because that's what I'm most experienced with. Here's why it makes sense to use these languages:
First off, these languages help you write faster, and more efficiently. They mostly take a lot of the repetition and mental strain out of writing code. In my experience with LESS I'm always able to do things faster and don't have to remember color names or keep track of certain styles that I repeat many times especially if they include vendor prefixes.
Then once you've "compiled" the code it's the same as if you were to write it normally. Some may say "so what's the point then?" but again I must repeat that you are able to work more efficiently and still have yourself normal, totally compatible CSS, js, or HTML.
As far as performance goes, there really is no loss in performance as your abstracted code is compiled to the everyday kind with option to minify it too. I use LESS for all ky styling and on my Mac I use either Less.app or CodeKit which automatically detects changes to my .less files and compiles them on the fly to normal .css ones. The source of every page always asks for normal .css files and I really don't have to do any extra work besides making sure the app outputs my stylesheets in the right folder. As a bonus, CodeKit also minifies most languages, detects and syntax errors, and does some image optimization. On my Linux box, I just run a quick terminal command and the compiling takes a couple seconds. Barely any extra work at all.
The only time I'd see ant performance issues is if you were doing client or server side parsing/compiling of these abstraction languages in production. For example, you can use less.js and have your .less files linked in your HTML and it'll turn it into CSS on the fly. That would be a problem. Otherwise, as long as you're taking your HAML, CoffeeScript, LESS/SASS/SCSS, and whatever else and converting it to everyday js, CSS, and HTML then you have nothing to lose and everything to gain.
I used to believe like you that these superset languages were just a novelty and had no truly useful purpose. Then I tried LESS and still thought it was lame for a short time (I only grasped the concept of variables and thought the only benefit was being able to name colors) until I really understood it and now I can't live without it. Give one of these a try and I think you'll appreciate them.
Edit: I understand that not all of these work the same. For those that require server or client side parsing with no option to convert prior to production then you have a point. But most of these abstracted, superset languages can be compiled to normal CSS/HTML/js before production and those are the ones that are truly beneficial.
Wordpress is far and away superior to any blogging platform available on Ruby. It makes wonderful sense to write Wordpress templates in a somewhat more productive environment than raw PHP, then compile them down into something which requires no dependencies on the actual server. This gets you all of the many, many benefits of Wordpress (great plugin support! huge community! deploys at any commodity web host! SQL vulnerabilities patched weekly+!) while having your template development not hindered by copious amounts of spaghetti code.
It is also big news to folks who write a lot of templates, because something like this allows them to create a toolchain which spits out WP templates, as opposed to having to e.g. having a template framework that templates are built against. This means that they can do across-the-board updates much more easily. That's a huge win if, for example, you're a company that publishes 100+ templates and somebody reports an XSS vulnerability in a commonly repeated component of one of them. (I don't know if their other 99 templates are patched yet so I won't go pointing fingers, but suffice it to say this happened.)
I got the feeling this plugin was for people who need to— for whatever reason, be it work or otherwise— make a lot of Wordpress themes. In that regard, it's pretty neat. I wouldn't go so far as to learn HAML and how to use the RVM just to make a friend a blog theme, though.
Still, I dislike how the programming community jumps on someone for making something interesting— even if it's not immediately useful for everyone. I get the same feeling in reddit's /r/programming whenever a post pops up about someone using a "NoSQL" database. It seems the majority of comments tend to be people negatively criticizing the OP's choice instead of providing something constructive to the existing project.
I'm not a Wordpress fan, but for better or worse, there are Wordpress plugins that do many, many things. For certain sets of needs, you can just grap WP and several plugins, throw them together with a half decent theme and you're done. I don't advocate that, because I enjoy craftsmanship and elegant solutions, but some businesses can be built in weeks, not months, using WP at very low cost--maybe the cost of the theme--if you're smart enough to put the pieces together yourself (you are).
> For certain sets of needs, you can just grap WP and several plugins, throw them together with a half decent theme and you're done.
until you are victim of a reddit-effect and your precious site goes down. or some yet another security hole is published and taken advantage of by thousands of spammers. I got nothing against wordpress and it's community, but AFAIR (nowadays I don't touch it) the wordpress ecosystem was full of unsecure plugins with awful performance, written by unqualified programmers.
I feel this is solving a problem that doesn't exist.
The problem with creating a WordPress theme isn't that it's missing buzzwordy tech like HAML, SASS and CoffeeScript. The problem is that the PHP behind WordPress is hideous. Even in version 3.x
If someone were to fork WordPress and fix all the spaghetti code, then I could stop writing themes like it was 1998...
I've dived in the Wordpress codebase a few times, I think it wouldn't be very hard to rewrite major parts. However, I don't think you can fix much without breaking tons of plugins, themes and 3rd party tools that integrate with Wordpress.
And if you are going to break the plugin ecosystem, might as well use Habari, which is much nicer: http://habariproject.org/en/
Exactly. I don't think that a re-write for WordPress will be the best solution for the moment as it'll wreak havoc on the thousands of themes and plug-ins that exists in the market.
I'm thinking of a theme framework that ease the theme creation process. It keeps you focused on doing what matters: putting the theme, CSS, HTML and JavaScript. Mainly there are three things to care about
- A routing engine. Similar to the Ruby routing engine. A plain and simple one.
- Views with a templating engine; and avoid the PHP/HTML mixing non-sense.
- A simple solution to create Admin panels on the fly.
I think this could serve as a solution for Theme Authors which helps them focus on the design rather than fight PHP loops and lookup WordPress functions.
This is awesome! I've often lamented how messy Wordpress is compared to Rails. Yet, there's nothing as mature and easy for anyone to use as Wordpress in Rails.
Rails is a framework, while frameworks do cool things, developers in any language are not always out to build a piece of software that's like a swiss army knife like Wordpress.
The rails communitys' exuberance to simplify and automate everything in sight hasn't quite reached wordpress yet. In the mean time there's gems, I guess.
I guess I was just thinking of rails very clear MVC pattern. Wordpress doesn't have this at all. Instead they have "the loop" which just ends up being a mess.
Yeah, Rails is one of many recent MVC patterned frameworks. It wasn't the first, and it won't be the last.
WP was created in a time where I think switches were used more.
Personally I find the MVC paradigm to apply to web apps easier, but there was a time when web apps maybe weren't so complex, and WP was around a long time ago.
Still, nothing provides a compelling ecosystem as Wordpress out there, so we can say the language, coding style seems to only matter so much in the end.
I think its a good idea and will give it a try next time I need to spin up a theme.
Ignore the negativity in these comments. This is a great example of scratching your own itch and being generous enough to place it on Github. Who cares if the bulk of WordPress users won't grok it? That's no reason not to build it. Thanks for sharing.
IF you're not already familiar with the theme creation process already. Seems like a solution for engineers whom are encountering WP for the first time. Which may not be bad thing as WP has been around some time.
Wordless, at its core, is just a big set of helper methods, plus a way to compile SASS/Coffeescript without the need to open a terminal, plus the embedded Phampl library to write views. So yes, the theme depends on the plugin, just like any other Wordpress plugin.
Looks like a whole bunch of stuff I'm not sure anyone (WP theme devs) was asking for. Cool project though, I'm just not sure the added layers really benefit developers much who are already used to the current system.
Jesus Christ. Can we stop all this "PHP Sucks" nonsense? We get it, a language like ruby is better for you. And hell, there's not much of an argument against how PHP looks; Ruby and Python, to me, look much much nicer.
But complaints about its technological capability are completely false. It's super easy and simple to learn, and even a HTMl/CSS guy like me is able to build pretty powerful, dynamic websites and simple apps with WordPress and (gasp!) PHP.
Before you start shitting on PHP, realize that
a) you're arguing over a programming language lol
b) it's been around for a long time and thus has a huge community, good documentation, lots of books and resources, and comes preinstalled on a lot of servers, etc,
c) great applications like MailChimp, Wikipedia, Digg, and FaceBook use PHP extensively
d) the learning curve is low
e) yeah, it is ugly. But its easiness to learn got me into quasi-programming with WordPress, and since seeing .rb files I've begun to get curious about ruby. But the basic programming knowledge is there from PHP experience and facilitates learning other languages.
Sorry, it's just frustrating to see people making fun of a language and criticizing the people who work with it.
Cool. As someone doing heavy WordPress development (and will be doing even heavier dev. in the future) this is a step in the right direction.
The available tools for WordPress right now are just awful. I'm doing plugin development right now (but will get to themes in a couple of months); and in order to setup unit testing it took me a full 3 days.
When coding plug-ins, I noticed that I'm using awful and very old patterns (like mixing PHP with HTML). It's like I'm working on PHP when I was 15 years old. Checking a few WordPress plug-ins (popular and premium ones), it even proved to be worse: They were using procedural code and patterns. Huge and long code, a bunch of functions with long names binding to WordPress actions or filters.
Here are the improvements that I'm looking for (and working on):
1. Better Unit Testing: A better stack for Unit Testing.
2. Better debugging: Debugging is just a nightmare when doing WordPress development and your project (I'm using Netbeans) should point to your plug-in repository.
3. Developers plug-in: A plug-in to manage your WordPress install
Include the assets in your Haml views using include_javascript() helper.
= include_javascript("application")
This will produce the following HTML, pointing to the assets/javascripts directory:
<script src="/wp-content/themes/YOUR_THEME/assets/javascripts/application.js" type="text/javascript"></script>
This is a very bad practice. You should use WordPress functions to queue scripts and styles.
Thanks, removed that point, maybe that was too much :) Also, Coffeescript is totally optional in Wordless. There's Sprockets under the cover, so you can write JS just fine, with the "//= require" directive bonus.
Or, you know, spend a day knocking together your own blog in rails.
I guess it could be good if you are wedded to a preexisting client base which demands wordpress, even for new projects, in which case my sincerest condolences go out to you.
To be fair, I'd imagine that those people who are raking in big $$$ doing WP themes must have something like this set up already.
I'll quote Wynn Netherland on a post about his take on the very same problem:
"I'm a Rubyist. But I'm also a pragmatic front-end developer. When I have to write a full-stack solution, I pick Rails or Sinatra because writing Ruby is a joy and the Ruby ecosystem is so darn cool. But when I have to create a CMS-based site for myself or a client I love the usability and community behind WordPress. Although I can reluctantly lay Ruby aside when I extend WordPress, I really miss my syntactically awesome stylesheets. Until now."
"Or, you know, spend a day knocking together your own blog in rails."
Understood you're exagerating for effect, but underestimating the complexity of a process like "blogging," over-estimating how much of it can be "simply" reëngineered, and dismissing the collective work of tens of person years is a real issue. I've witnessed that attitude cost businesses dearly.
Just because you can do something doesn't mean you should.
Just because you do do something, doesn't mean you didn't spend a ton more resource than was necessary. And because you spent more resource than needed doesn't mean you delivered the best possible result.
Not for me, though. When I got my current webcomic up and running I didn't even bother writing a custom theme like I did before - I just made a child theme of the Comicpress theme and started hacking away at the CSS.
It is inefficient, it is inelegant... but I got it up and running in a couple of days rather than a couple of weeks of tweaking the hell out of everything. Every now and then when the comic's being hard to write I procrastinate by tweaking the theme a little more.
I don't know if this means I'm a talentless hack or a pragmatic professional. Maybe some of both.
Then again I'm also not doing a crazy dynamic site that happens to be using Wordpress as its backend.
Although I've built WP themes and have "dabbled" in Rails (building a blog like everyone else) and consider myself more of a front-end guy, this seems like overkill to me.
Not to mention most designers I know would look at this and roll their eyes.
I agree with you darksaga. This plugin is not for every designer out there, and it's way too difficult for a PHP newbie. But, for people who already know these languages, it's an incredible timesaver. So that's its target.
I appreciate the work that must have gone into this, and it looks like it has been done well technically. However: How many people are this deep in the world of Ruby and yet also enjoy writing WordPress themes? I run a forum devoted to WordPress, and I can not imagine any of the experts (who post there) wanting to switch over to Haml or Coffeescript. Most people who use WordPress are either designers or programmers who are looking to put up a somewhat quick-n-dirty CMS.
If you have the skills and resources to install a Ruby environment and a bunch of gems, why not use Rails plus some CMS built with Rails?
I can only present anecdotal evidence here but I do most of my freelance web dev work in Rails but turn to WordPress for web sites. I'm definitely more conversant in Ruby than PHP, but I think the ecosystem of the WordPress platform, plugins, and developer mindshare is a big deal for the projects' futures.
That said, I don't see myself using Wordless. Aside from my personal gripes with HAML, I have some concerns about breaking WordPress and PHP conventions. Will future developers be able to continue my work? Will plugins work as expected? How about page templates?
I did use SASS for a couple of themes and that worked out well enough, but I doubt I'll use it for future projects. Idiomatic code and tools are a bigger productivity boost both for myself and others.
EDIT: I can see a sweet spot for this in teams that work primarily with Ruby/Rails but want to leverage WordPress on a site they maintain in the long term.
Interesting concept, but like others have said, I'm not sure if you're catering to the right crowd. I've taken a handful of computer science classes and am a web designer at heart, yet even I would not be very inclined to use this. I would rather do it from scratch if I'm interested in learning these newer languages like CoffeeScript. Wordpress is more for those who don't know anything and/or want to build a semi-customizable blog/website quickly.
That being said, this is a fantastic project and I applaud you for doing this. I hope those who do use it end up enjoying it.
I was wordpress hater for two reasons - messy templates and messy plugins. This hate came from my "consulting" days when I often had to fix and add more features to existing wordpress websites.
Nice to see someone investing time into building rigid structure for templates... (Although it looks like a bit too much for me :)) But probably it worth learning Ruby, Haml, Sasl, coffee-script, etc)
Now if someone could come up with something very defined for plugins and make somehow all "wordpress programmers" use it for both templates and plugins - word could be better :)
What I really want is to be able to download a word press theme and have it magically applied to my rails app or have some plugin that let's me do this.
Another project similar to this is Forge http://forge.thethemefoundry.com/
Embracing Sass, Less, CoffeeScript is not a bad idea for wordpress themes if you are familiar with them.
I thought I'd mention, for those who prefer a modern Ruby stack, it is possible to install a JSON REST plugin for Wordpress (like http://wordpress.org/extend/plugins/json-api/) on the back-end, and write your front-end display layer in Ruby.
I'm a PHP developer and use HAML and SASS in PHP projects.
Why? Because to build a website with these tools speeds up my development time.
You cannot forget anymore a </b> closure. You can forget all the 'echo' calls. You can forget all that horrible "nested" css rules with tons of repetition. You can forget all that <?php ?> tags everywhere around the HTML code.
Yes the cost to pay for this is ruby. Well, it took me about 20/30 minutes to setup a ruby environment with RVM ( https://rvm.beginrescueend.com/ ).
Now my PHP project are cleaner, easier to mantain, only with a little "trick": some really good Ruby tools...
At the end, I think that the advantages are worth the costs...
This is a "templated" way to do so in wordpress projects... Why not? ^^
I'm not referring to HAML and SASS, I'm referring to Ruby.
HAML and SASS are good thing and to integrate it with Wordpress is great. However, if you want Wordpress developers to make use of your efforts, cut the dependency on Ruby since no Wordpress developer will be willing to get up and running (or even installing) Ruby.
The comment you're replying to isn't making fun of WordPress. The WordPress community has this bizarre obsession with getting people to capitalize it the way they want them to.
It would probably help if the introduction to the project ("stop writing themes like it's 1998") could manage to be a little more matter-of-fact about the advantages it might have to offer and maybe a bit less opinionated.
Just to make sure: the production/live machine doesn't need the Wordless plugin, correct? Basically you use the Wordless plugin on the dev machine then just distribute the created theme directory like normal? Or am I off-base?