DrupalCon Portland 2013

¿Es Drupal un CMS?

Larry Garfield  · 


Extracto de la transcripción automática del vídeo realizada por YouTube.

alright so this session asks a nice basic fundamental question is Drupal a CMS a story in five acts first off my name is Larry Garfield you may know me online is Krell i'm a senior architect at panel internet web development shop specializing in drupal

based in chicago for drupal 8 times the web services initiative lead i'm also the drupal representative to the PHP framework interoperability group which is trying to encourage collaboration between a variety of different PHP projects I'm an advisor

to the drupal association and general purpose busybody that's enough about me act 0 because we're geeks of course let's talk to some history we've all heard this statement for right actually sorry who here's been using Drupal for three

years or less okay yeah three or fewer Matthew def okay five or less okay who here's been using Drupal more than five okay this is the right right crowd down so you've probably all heard this debate before duple is an application no no wait Drupal

is a framework so which is it is a framework ramification well um it's both we're a Fram location whatever that means I don't know it's a framework II think application it's a problem why why is this debate there why was this debate there

this debate has been around for as long as I've been involved in Drupal which is getting on a very long time now because these are different mindsets to think about this thing we call Drupal framework think framework mindset is concerned with things like

why in the world is saving a node from code so hard why do I have to deal with making it into a pseudo form in order to do that from a framework mindset that is a problem to be solved that is a problem that must be solved and that is a priority and oh yeah

that the node form could be better but really the problem is that nodes you know working with encode is a pain in the butt this is the important thing from a framework think mindset if you're coming at Drupal from an application standpoint though then

a dashboard with widgets in Drupal 7 is important because that's feature that an application like drupal should have and that's a perfectly legitimate statement to make that it needs that kind of functionality but wait wait wait a second you want kisas

out of this you're going to reuse why is it a dashboard but what do you you know the priorities that these different mindsets have are very different and often conflicting and for years this debate raged through Drupal through every issue in every discussion

in every drupalcon and somewhere around four years ago there was a movement called small core who remembers small core okay so this is old history for some of you small core the idea of small core was that the better Drupal becomes at being one specific kind

of tool one specific kind of toy in this case a teddy bear then the less useful it becomes for all the other things we're trying to do with it the better teddy bear Drupal is the crap here it is as a toy train the better Drupal is as a bespoke in out of

the box CMS application the worse it is as an application framework because the pieces are too tightly coupled in the application and so the small core movement was very much a framework think approach and the idea of small core was that core should make fewer

assumptions not that it be physically smaller but the assumption list should be smaller and fewer assumptions means more flexibility more ability to use Drupal for different kinds of toys it means loser coupling loser coupling makes it development easier who

is here for marks on top session this morning all the stuff he was talking about with unit testing loose coupling makes unit testing easy unit testing forces you to make things loosely coupled these are both very good things and they make development easier

because you have less chance of breaking random things somewhere else more flexibility means a better platform it means a better system that we can then build on top of to build aside for clients build on top of to make a ticket tracking a project management

system like open atrium build on top of to make a news aggregation service and all these other wildly different things that Drupal is being used for and by the way you know as an example we really need stuff like Pole module and log module they're really

hard coded to one use case that's not really you know framework you think this is a good example we don't really we shouldn't really have those and of course everyone fixated on that last one and no that was not the point honestly this is like

the worst marketing ever from any effort in open source was calling things small core and talking about modules small core was never about removing modules from court that was never the point if you thought it was i'm here to tell you you're wrong

even Drees got that wrong in his core conversation in denver last year that was not the idea the idea was that with loosely coupled components that we can rearrange it's possible for us to then build a really strong CMS out of those loose components out

of that framework rather than trying to be a framework an application at the same time and not preferred in either one ending up ending up with this mud of an interface that tries to be a framework and tries to be an application at the same time and fails

and that was drooping up through Drupal 6 in some of Drupal 7 the way to build a better application small core argued was to build a better framework first and then build the application on top of it you have to build the framework first and then the application

on top of it okay these quotes are from 2009 why am I still talking about this I'm talking about it because never actually answered these questions this debate never ended we just stopped talking about so what has happened in the last four years well Symphony

happened and you know one could argue that great we went the small core route and you know simply is a big part of that and that's true sort of but that's true not because we decided that was the way we wanted to go not because we had a consensus that

we wanted to take that approach it happened because the people working on the core of Drupal 8 were stubborn people like me who took that approach and ran over anyone who disagreed that's a very bad thing I you know to a large extent I won that debate

because me Chris Vander water Greg Dunlap and people like that who thought in a small core way were the ones doing the work not because anyone collectively agreed that absolutely to do it simply the people who had the strongest force of will at the time went

that route that's bad that's not good as the person who was victorious and that's in a sense I think that's a terrible idea that's very bad for Drupal in part because that was only one part of the picture on the other side this is that

new node edit form that Ruiz was talking about as being this wonderful new creation and sure you actually have a we see big now we have this nice new interface on the side here we actually have a buttons down at the bottom that explain what publishing is and

that is great for the use case of a CMS that is great for a particular type of application but not for everything Drupal is being used for there was a very lengthy discussion about this save and publish button about do we want to force the concept of publication

on our users if you're building a forum does that make sense do we even want to expose the concept of revision to them at all is publishing something that matters we're forcing this into the UI to make it easier for one class of user but that makes

it harder for another the site that got me into Drupal in the first place that originally built out on Drupal 5 is currently migrating away from Drupal at my recommendation because of this not this forum in particular but so much of Drupal now is so much harder

to use as a general purpose framework Drupal is a general-purpose framework you know the core system may be a lot more loosely coupled what the entire package is much more of a CMS and much less of an application every version because we never actually answered

this question the more Drupal becomes a better CMS the less useful becomes for all the other use cases Drupal is currently being used to solve Act one so what exactly is a CMS well it's a content management system duh which is a system for managing content

I'm still not saying anything this is quote from daniel jacobson who coined the term cope creepy ones publish everywhere the goal of a CMS should be to gather enough information to present the content on any platform in any presentation at any time focus

is on content on any platform in any presentation a real CMS a content management system is just a Content capturing tool it is sig gnostic to how the discontent to displayed where does displayed when is displayed on what device it's displayed it is just

concerned with managing and curating content a CMS must be presentation agnostic if it is not presentation agnostic don't call it a CMS it's presenting something it's hard coded to a given presentation then it's not a CMS it may have seen messy

type of tools but that's not real content management its core from Kerala grain who I really wish this session was being given after a few keynote tomorrow morning because I suspect you going to touch on a lot of these issues so everyone go to her keynote

by creating presentation independent content that includes meaningful metadata you set yourself up for a future where your content can go anywhere content and metadata structure of content a CMS is a system for managing content and metadata that's it that's

the extent of what makes something as CMS as CMS consists of chunks of data and rules for managing it not presenting it managing it now managing it is hard this quote from Dean Barker gadget Opia the art in practice of contents assembly it's a great article

[ ... ]

Nota: se han omitido las otras 5.039 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.