In this article I might be wrong at any of the parts as Drupal is huge and my knowledge might be not up to date and I might be wrong anyways. These are my thoughts currently that I want to share them with the Drupal Community...
I really think Drupal has a few issues. These are mainly related to previous generations of Drupal. Current Drupal versions come with pretty much relations to previous ones.
I started using Drupal like 2 years ago. Maybe earlier. I really loved its idea however before finding drupal I've started writing my own CMS. When I didn't even know about the expression 'CMS'. This thing doesn't mean much. It only means i really understand the basic reason why it was made.
My belief is that things can be much easier. Here I am about putting some idea together how Drupal can be (and hopefully will be) much better.
- No exceptions: Each and every node type info (publishing options, display settings) should be normal fields. With all the options a field gives: Widgets, Formatters, etc. On Entity Type Properties there are Title, Author, etc now. Great. We need all the rest I believe.
- Views: Views should give all the options an SQL query can give you. It might be not views. I would call it 'Query Module'. D7 has the Query now. An interface for Query with some drag and drop, and formatters for fields for its output, pagination, and that's it.
- Module builtups: Modules Should have the options so developer can set which of its field comes from where. Lets say on Developers UI I can set for Notifications module Which field is the title field and when to send a notification. At this moment its so closed. I need to use Tokens to do it. A better way is setting which field is going to be its title. Also it works as: it sends notifications when node goes to published state. Why? I want to decide what goes into what state to fire this event. Organic groups is still full of exceptions. Basic thing that doesn't work.
- Alter function for each and every function without explicitly defining that an alter is possible. This way there will be no worry of not being easily alter some behavior. This should be standard. Is it maybe very processor time expensive? Maybe there is solution: when modules are scanned built these hooks and have a list of them. Module builders should not worry about making it able for others to alter their stuff.
Generally i'm thinking of a Drupal with NO EXCEPTIONS. Drupal is made for programmers. We basically know what we do. We want to be free. We don't like limitations do we.
Comments
Drupal goes the right direction
PS: I believe Drupal goes the right direction. I want to open everyones mind and start a revolution like thing: How to think in/of Drupal, which way to go.
I believe that that's where Drupal will end up anyways sooner or later.
Actually, I agree in general
Actually, I agree in general with the ideas you are describing here. They are not new.
A little bit of this is happening in D8 (with title becoming a first-class field I think).
1. Much of the reason it's not there is just that it's a lot of work - how many hours would you volunteer to ensure that 'display settings' can be converted into field_api without breaking everyone elses site?
A lot of the reason is plain efficiency. What is to be gained by making a nodes 'published state' a field with all the field_api layer of redirection on it when a built-in INT flag will do? How much more work would it be at every step if the 'published date' was changed from being a sortable timestamp in a single column out to a 'date field' or similar abstraction? Generally, stuff like this has no payoff and a LOT of disadvantages. So no to "no exceptions" - some data is just a data column.
2. If you want to add more options to views, and still keep the UI usable without exposing code for security reasons, you can write your own extensions and plugins. Views supports that incredibly. Please do contribute your code there!
3. This sounds like a specific problem based around a specific job you are doing today. You'll find that all the other modules out there appreciate the fact that each node is guaranteed to have a 'title', and to know how to find it.
4. Efficiency is also the reason why function alters are kept to a listed number. Also sanity.
It's hard enough already to try and guess what module might be changing the output of an execution path with all the possible hooks out there. At least with a few named points where modules say "OK, now everyone else can tweak this", and a registry, it's possible to trace these side effect.
If, as you propose, "each and every function" could be altered whether it wanted to or not ... learning the API and tracing an existing site would be hellish.
Plus, the execution overhead of going and looking through all modules for a hook override every time *any* function is called is way too heavy. It's just not appropriate in an interpreted language like PHP.
I see where you are coming from with your post, but none of these suggestions are really going to go far - not without a lot of effort. If you can write some patches that demonstrate how you think it should be done, and include the performance tests that would be needed for it, then you'd have a strong point. Join in!
.dan. is the New Zealand Drupal Developer working on Government Web Standards
OP, bsandor, says Drupal is
OP, bsandor, says Drupal is made for programmers. I think now it a long way down the path to become a professional tool. Historically, when Wordpress was much more limited, Drupal was also a tool for hobbyists and non-technical site builders, and has not abandoned that space. Indeed, Acquia, by far the most dominant Drupal shop, whilst working largely in the enterprise market, also maintains and has invested in a SaaS business for entry-level users, comparable with the Wordpess hosted offering.
Of course, the discussion about where Drupal should go does not take place here. It belongs mainly in the core issue queues, with some conversational element on IRC and at DrupalCons etc. Currently is rather late in the development cycle for Drupal 8 for significant change. Early in Drupal 9 might be a better time. And if you look at that discussion, you see that core developers are smart, and certainly alive to these issues. It is partly a question of time, also a question of getting community agreement (being a community-driven project). See for example this blog post http://www.garfieldtech.com/blog/private-composition-inheritance .
As for contributed modules, it is pretty much the Wild West.
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors