The drop is always movingYou know that saying about standing on the shoulders of giants? Drupal is standing on a huge pile of midgetsAll content management systems suck, Drupal just happens to suck less.Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]Drupal makes sandwiches happen.There is a module for that

Don't hack core

Submitted by nk on Sun, 2011-06-12 05:53

Unless you are architecting core or interested in how that particular sausage is made, please leave in peace and don't hack core.

We try to create APIs that serve a real lot of use cases. However, every API has boundaries. Despite the multitude of alters, there are always more to add. On the OOP side of this, I had a lot of clashes in the past because I did not want to see the protected keyword in core APIs because I was afraid that use cases will rise we couldn't think of before and I felt leaving the object "open" is better. Turns out, the "properties starting with an underscore are private" notation is a PHP4 pecularity that noone knows any more. Marking something protected makes the API easier to understand. And we have an answer in case you (and you alone!) need to something core didnt think of.

The agreement, the common understanding now is this: we are (and always were) trying very hard to find the possible use cases while designing, involving all the high profile people who are doing something related, patching in the open in the hope that others in the community will chime in wih use cases. However, at the end of the day, if you need to do something really crazy and core does not allow for this feature and very few people need it and the change would make everyone's life harder then it is okay to say that yes, you hack core. You do not get to those crazy places without the help of people who already know Drupal rather well, anyways. Of course, this is not an endorsement of hacking core. It is an answer to my question: "And what if a use case we couldn't thought of comes up later?": "If a lot of people need it, we fix it in a later release. But if you are one of the sites with eighty database servers who needs this then you just hack core for it and that is OK."

Ps. Any comments not relating to API design will be deleted.

Commenting on this Story is closed.

Submitted by Anonymous on Mon, 2011-06-13 13:42.

Isn’t this partly the rationale behind having forks of Drupal. Obviously there are cases were someone is doing something unique and will not benefit from a community, but there are also classes of users where particular additions to core may be required.

Having forks is a good way for the Drupal community as a whole to try out API additions, and allows for people who may not be comfortable with hacking core to benefit from such additions.

Should we perhaps examine Drupal and see what can be stripped out with this in mind?

Submitted by Anonymous on Mon, 2011-06-13 23:13.

Forks indeed. Pressflow exists because core can't be all things to all people - it directly addresses the "I have 80 database servers" market, not that anyone *really* has 80 database servers... do they?? o_O

Submitted by Anonymous on Wed, 2011-07-27 15:33.

I learn so many things here after i read your article. I also enjoy reading your this one from the start until the end. This is really informative.