Wordless: stop writing Wordpress themes like it's 1998.
github.com
github.com
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?
https://github.com/kriswallsmith/assetic
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):
https://github.com/jbroadway/bootstrapped
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.
It's pretty straightforward and easy imo.
Trying to integrate several different WordPres plugins is a challenge, as they each tend to be written in their own style.
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.
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.
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).
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?
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.
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.
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?
The terser the syntax, the less room for error in comparison to its more verbose counterpart.
"just to then use some tool to translate it (and if it gets a little complicated have to manually fix translation problems afterwards)"
If you're manually fixing compiled code, you are doing it wrong.
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.
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.
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.
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.)
+ Kidding, kidding. OK, mostly kidding.
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...
And if you are going to break the plugin ecosystem, might as well use Habari, which is much nicer: http://habariproject.org/en/
Too bad all the available plugins fit in a single page: http://wiki.habariproject.org/en/Available_Plugins
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.
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.
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.
After working with Active Record, it's really hard to switch back to Wordpress and write:
$today = getDate();
$my_posts->query('year=' .$today["year"]. '&monthnum=' .$today["mon"]. '&day=' .$today["mday"]);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.
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.
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
4. Bootstrap plug-in: Administration interfaces (styles/tables/forms/buttons...)
EDIT: I just noticed that the following
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.stopped reading right there.
Why not just go the whole hog and run wordpress inside ruby, using tenderlove's Phuby bridge/adapter/thing.
https://github.com/tenderlove/phuby
Demo of him actually using this to run wordpress inside rack: http://www.youtube.com/watch?v=MXERy8Y2eVo
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'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."
http://wynnnetherland.com/journal/sass-up-your-wordpress-the...
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.
Not to mention most designers I know would look at this and roll their eyes.
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?
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.
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.
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 :)
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.
C'mon. All this work and no PHP/Wordpress developer that will ever use this. What a shame.
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? ^^
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.
#capitalPdangit
http://www.wptavern.com/automatically-correcting-the-wordpre...
Then you said HAML, and I giggled.
Then you said SASS, and I started cackling.
Then you said CoffeeScript, and I nearly died of laughter.
Keep your Rubyist junk out of my (unbeloved) PHP.