The Drupal.org D7 upgrade launch is confirmed. Today is Monday, 28th of October, we have 0 launch blocking issues and performance tests are looking fine. Therefore, we are going to launch on Thursday, October 31st, 2013.

What will the launch process be like?

Drupal.org will be down for approximately 24 hours during deployment. It will be replaced by a static page with a download link for the latest Drupal release available. Sub-sites will stay online, but with user logins disabled. Both updates.drupal.org and ftp.drupal.org will stay online. drush make / dl will work fine, update status module as well.

We will start deployment around 15:00 UTC on October 31st. We expect the site to be back up by 15:00 UTC on November 1st.

We realize this will be a significant inconvenience for users who rely on Drupal.org, and will try to minimize downtime as much as possible.

What if there are problems? Do you have a backup plan?

Yes, we do. If we encounter significant problems during migration, we will roll back to the Drupal 6 version of Drupal.org and restore with a backup made right before migration started.

How can I find out what’s going on during deployment?

Twitter accounts to follow are @drupal_org and @drupal_infra . IRC channels: #drupal and #drupal-contribute.

What changes will I experience when the site comes back online?

You can find information about the changes in functionality or UI in the Drupal.org D7 F.A.Q. Most pages on the site won’t change as far as layout or functionality. Our goal for this project was a straight port from Drupal 6 to Drupal 7. The only place where you will see significant UI changes is the issue page. This blog post explains what is changing on the issue page and why in detail. In general Drupal 7 gives us more flexibility to implement new features and there will be a boost in performance for some of the pages.

Why aren’t we waiting and upgrading to Drupal 8 once it releases?

The Drupal 7 upgrade began in March 2012. The upgrade took longer than we anticipated due to a variety of reasons that include the scale and complexity of Drupal.org and resource contstraints. We decided to push ahead and complete the Drupal 7 upgrade so Drupal.org can be on the latest release of Drupal, and so we can use the learnings in future upgrades.

Comments

yngens’s picture

It's good news if we will see new features and boost in performance on Drupal.org. Good luck with upgrade!

Drupion.com — Drupal-centric, Drupal-specific, Drupal-optimized hosting company.

chuta’s picture

Thanks for taking time out to explain things. It will be great if this effort can make the search tool on drupal.org a little bit more relevant to users.

drumm’s picture

We don't have any functionality improvements ready for search, but Drupal 7 will of course give us a good place to build on.

rooby’s picture

I recommend google for searching :)

joshtaylor’s picture

Subsites - includes api.drupal.org? :)

drumm’s picture

API.Drupal.org has been on D7 for a few months. Each site moves at its own pace.

adam_bear’s picture

Strange that it isn't configured for multisite...

drumm’s picture

Each of the Drupal.org sites has very different sets of modules and we want to be able to deploy one site at a time, so multisite isn't ideal for our use case.

jatbhatti’s picture

Thanks for the information, Good to see drupal 7 on live site soon.
Best Luck!
Thanks!

Drupal Dev,
Jatin

pravat231’s picture

I really appreciate this step for moving onto Drupal 7. Which I would say Awesome for us to see the benchmark.

abghosh82’s picture

I am feeling excited and waiting to see the new drupal.org on D7 and improved features. Good luck with the upgrade!!

Abhijeet Ghosh

igor.ro’s picture

Will reps for download be avaliable?
I'd like to use drush make on that time.

Igor Rodionov
Omsk, Russia
tel: +7 (905) 942 6391
email: rodionov.ig@gmail.com
skype: goruha12
blog: http://drupal-you-need.blogspot.com/

tvn’s picture

Yes, ftp.drupal.org will stay up and drush make will work.

lslinnet’s picture

I am assuming that drupal.org/files will be unavailable doing the downtime, due to this all drush makes that relies on patches like:

projects[xmlsitemap][patch][] = "http://drupal.org/files/1295742.xmlsitemap.xmlsitemap_base_url-unrequired_0.patch"

Will fail to build.

or is there an alternative to drupal.org/files path?

tvn’s picture

The files will be available during downtime, drush make should work.

kalidasan’s picture

Wishing you all the best for upgrade.

Natpudan,
Kalidasan
http://kali-dasan.blogspot.in

RajeevK’s picture

Feeling exitement to hear about D7 launch of drupal.org, Best of Luck :)

RajeevK,
+91-9650361380
http://rajeevk.me/

ishwar’s picture

Wishing you all the best for upgrade !!!!!!!!!!!!

IC tiwari
Software Engineer

gauravjeet’s picture

good luck

I have also migrated projects from D6 to D7, I can understand the delay in schedules for D7 upgrade launch.. :)

jackenmail’s picture

Best Luck Team for new upgrade. we are waiting.....

helios.drupal’s picture

Its good news, I appreciate this step and will nice to have Drupal.org in Drupal 7..... all the best......

Ashvin Sanandia,
Helios Solutions,
India

juanjo_dv’s picture

I like the red bar over the page, I want it. Is there some module which provides it?

drumm’s picture

A copy of that functionality is in the drupalcon_base theme. http://drupalcode.org/project/drupalcon_base.git/blob/refs/heads/7.x-1.x... injects the text into the page and the first couple lines at http://drupalcode.org/project/drupalcon_base.git/blob/refs/heads/7.x-1.x... are the CSS we use.

rakesh.gectcr’s picture

Its nice hear the news...

Wishing all the very best for those who doing the great hard work behind this....

I can understand this because , i have done this quite number of websites....

@tvn

I am little curious to know how you guys porting the users.

Once again Cheers all...

Rakesh James

drumm’s picture

Users are done with the regular drush updatedb. We did deploy https://drupal.org/project/phpass long ago, so we don't have rehashing time with this deployment and have had secure password hashes in the meantime.

Sajjad Dehghani’s picture

i'm very very happy to this change. i'm waiting to see this big change...

mmz81’s picture

Good news!

shantanu2683’s picture

Best of luck... for upgradation.... Looking forward to see new view....

Thanks

Shantanu Karmakar
Mail: shantanu2683@gmail.com
Skype: shantanu.karmakar

Vacilando’s picture

24 hours without d.o.? A real risk of an abstinence syndrome!


Tomáš J. Fülöpp @vacilandois

nimazuk’s picture

excited and waiting to see drupal.org on D7!

Nima

kdevanshu’s picture

All the best.

kdev

lohithsunchu’s picture

Wishing you all the best for upgrade ..

lohith sunchu

amarbijay’s picture

This is awesome..we can see Drupal in latest versions.

Drupal the power of CMS

sfdrummer’s picture

Good luck with the launch guys and gals, thanks for the heads up.

dersuchende’s picture

that's nice!!! Let us know which are the problems that you encountered during the migration when it's done, as should them be a great use case for migrations done by the users on them website.

rta’s picture

Thank you for notifying us, good job!
hope all's done peacefully.
--
:)

Abdallah

kareemzok’s picture

Its great news to upgrade the site by adding new features and improving. Good luck .

lav.k’s picture

Wow! waiting for now ...

Lav Rai

ARUN AK’s picture

Best of luck for upgradation. And waiting to see drupal.org in Drupal 7.

Thanks and Regards
ARUN AK
http://www.developersdoc.com

goose2000’s picture

I don't feel so bad, now that I know drupal.org has been stuck on D6, for their own complex reasons. Wow, they're just like real people. YAY team Drupal.org!

gp177’s picture

I can't help but feel that this highlights one of Drupal's biggest weaknesses; the migration process.

1.5 years of development and a 24 hour downtime seem steep for an update process that doesn't sound to be adding any new features.

DoctorOW’s picture

Keep in mind Drupal is a big site with over a million users and tons of pages created by them. This doesn't represent any weakness in the Drupal software as one can typically update over the course of a few minutes. They are doing additional steps to make sure that the best experience is being had as opposed to upgrading just to upgrade.

gp177’s picture

I fully understand that and am very appreciative of the work that is done by the community.

My point, however, is that in order to maintain a supported version of a Drupal site, you're looking to migrate every 3 years, which requires significant development resources. Many other frameworks/CMS that take a much more progressive approach.

API changes as part of a point release system are being discussed as part of a possible future for Drupal 9 and I think the Drupal.org update process highlights why this is a good idea.

rooby’s picture

To do an upgrade properly it can take hours to roll out even on a small site.

drupal.org is not a small site by any means.

Jaypan’s picture

Also consider that Drupal.org wasn't built with D7 in mind, it's been ported since early versions, and therefore will be complicated with each upgrade. The size of the size is also quite vast. So many things to check.

ryan88’s picture

I would also think that the hosting presents a problem. I assume drupal.org is load balanced over several front-end and database servers with a master/slave setup. I know from first hand knowledge how much of a pain that can be!

DoctorOW’s picture

None of these are really Drupal weaknesses.

arunnayak’s picture

looking forward to see the new look of drupal.org using D7

ADN

Beanjammin’s picture

Too late for this time around, but a static copy of the existing site would have made for a much less significant user impact while the upgrade is taking place.

Good luck with the upgrade.

gp177’s picture

We've used Varnish to this end during an emergency of our NAS.

I have no idea of the infrastructure behind Drupal.org but it may have been possible; and they are deffinately using Varnish.

coolestdude1’s picture

This is fantastic work from d.o. we all hope that the release goes as smoothly as it can. Thanks to the various teams that worked on this deployment, take some time off would ya!

pachabhaiya’s picture

Good luck team!!!

---

Chhabi Pachabhaiya

http://c.pachabhaiya.com

Contact Me

dariosantacruz’s picture

Hey guys, remember that you know exactly what you are looking for (or maybe not exactly) you can search on Google and use the cached version of the website to read the information :) (maybe not download the files, but something is better than nothing).

Joseph Zhao’s picture

Welcome to Drupal 7 :)

dillix’s picture

Great news! I think D8 stable will coming soon after d.org upgrade:)

In Dillix we make highload projects on FreeBSD with Drupal;) Our lessons for Drupal available at WebDev.

ronrons’s picture

Thanks for the info, Good to see D7 on live soon.
Best of Luck......

Regards,
Rony

bikramth19’s picture

Its being a good to know that the drupal website is migrating to Drupal 7. It will be more responsive & hope to be good design
All the best...

Regards,
Bikram Singh
website: thokchom.in

Bikram Singh
OpenSource-Hacker

joelwallis’s picture

Is there any new feature coming with this upgrade? Like a better issue tracker management interface?

Joel Wallis Jucá
http://joelwallis.com

BigMike’s picture

Good luck with the entire process, hope everything goes smoothly! We'll be doing this soon on our site once a few more modules are ported to D7 :-)

lisarex’s picture

Exciting!

Good stuff, everyone involved.

The good news is that after this upgrade is out of the way, we can start to work on other improvements to drupal.org.

==================================
http://about.me/lisarex

ryan88’s picture

Funny, I thought when the theme changed a year or two ago, that the site had been updated too...

ArtActivator.com’s picture

Hello. Good news!
We all know, that Drupal 7 is a _little_ bit slower than Drupal 6.
And drupal.org is very busy site. Please tell us after move, what modules you used to give best speed.
DB is MySQL or Postgres? Should I use mongodb module?
Now I have installed Advagg, Entitycache, all caches enabled + nginx + php5.5-fpm + Zend Opcache+ and it gives me 50 req/s on ab stresstest of main page. (Xeon Quad Core 3.3Ghz, 16GB 1366Mhz)
I plan to try boost, but now it have problems with securepages module.

Thanks

arvind.kinja’s picture

how to hide panel node link and add new comment link from page.tpl.php .
I am trying to add css on predefined class 0 on link add new comment but csss not work.

gp177’s picture

Drupal 7 is faster than Drupal 6, once you enable comparable modules.

I'd be willing to bet they are also using something Pressflow-ish for D6 core since they are running Varnish.

ANUWerkz’s picture

This is good news!

cosminadrianpopescu’s picture

So you are still on Drupal 6? No wonder, considering the backwards compatibility that you've never heard of. I would be embarrassed.

Cosmin Popescu

a.ross’s picture

Bad troll

Peace to those who follow the guidance.

cosminadrianpopescu’s picture

If you consider normal that drupal.org site uses Drupal 6 (when Drupal 7 was released in 2011, so almost 3 years ago). And why are they using still Drupal 6? Again, because of the backwards compatibility. And the best example is the drupal_json_output function. I mean the body is the same with the body of drupal_json (the 6 version) just the name changed? WTF is this? What kind of moron does this?

Any at least normal framework would have some kind of backwards compatibility between major versions. I am not speaking about compatibility between version 2 and version 7, but between version 6 and 7. See the Qt framework for this.

As soon as someone points out the truth he is a troll. So again, if you consider this normal, then yes, I am a troll.

Cosmin Popescu

a.ross’s picture

You're conveniently hiding behind proclamation of the truth, but that's not why I called you a troll.

You're a troll when you use hyperbole and sarcasm in your criticism. Sure, Drupal can do more in the backward compatibility department, but for the most part it's a development choice. It has significant advantages, in the same way that choosing to drop support for old versions of IE is a development choice which allows you to build a more modern interface. Backward compatibility vs fast innovation is mostly a dichotomy: can't have it both ways.

Peace to those who follow the guidance.

cosminadrianpopescu’s picture

Common,

You cannot be serious. The support for IE6, for example in jQuery is dropped just now. How many years after IE7 (2006 if I am not mistaken)? As I was saying, I did not asked for backwards compatibility from Drupal 2 to Drupal 7. But Drupal 6 to Drupal 7 has to be compatible.

Not to mention that you speak about innovation. Look at the source code of the drupal_json and drupal_json_output and tell me where the innovation is. As I was saying, only a moron would just change the name of the function because it sounds better or respects some new coding standard without at least deprecating the old method.

I was using sarcasm because I did not want to use words as "moron" or "idiot". As toward criticism, I think that this should be allowed no matter how good the product is (not that this is the case of Drupal).

Cosmin Popescu

a.ross’s picture

If you don't like Drupal, go somewhere else. If you want to help Drupal, criticize it without resorting to silly hyperboles and sarcasm. Your trolling will be called out.

You gave a very specific example of something that's wrong with Drupal's backward compatibility. If you think that's such a major problem, then just re-open this issue and submit a patch with the old version and clear documentation. The Drupal community has always been a lot about scratching one's own itch.

Drupal is still a great product both from a technological standpoint and judging by adoption rate. You make it seem like backward compatibility is the single criterion by which to judge a software product.

Peace to those who follow the guidance.

cosminadrianpopescu’s picture

It's not just about the backwards compatibility. How about:

* no consistency in the code
* no MVC
* no OO
* extremely poor documentation
* 100 modules doing the same thing
* slow sites
* no foreign keys in the db
* no consistency in the db
etc.

I was just pointing out that even the creators of Drupal are affected by how bad their code is. This is why I only enumerated this reason.

Drupal is popular because is very easy to use it and to install it and it's not very complicated to extend it. But that doesn't make it a good product. It just makes it a popular product.

Take for example Windows. Although compared with other operating systems on the market (GNU, Unix, BSD, OSX) from a technical point of view it's by far the worst, it's still more popular (I am referring to the desktops). Why? Because every dumb person can use it. The same with Drupal. That's not to say that every Drupal user is dumb. It's just to say that a lot of dumb developers are just Drupal developers.

Cosmin Popescu

a.ross’s picture

Yeah, no clue what you're on about. This is the last reply in this worthless discussion.

no consistency in the code

Well of course there are legacy elements in Drupal. Like I said, do you want backward compatibility or fast innovation? Can't have it both ways.

no MVC

Yeah, there we go again with the whole MVC thing. This article is old, but still good: http://www.garfieldtech.com/blog/mvc-vs-pac
There's also this one that's a bit newer: http://robknight.org.uk/blog/2011/02/explaining-architectural-tiers-drupal/

no OO

You do know that PHP's OO support is pretty young, right? And that it didn't really work very well in PHP4? Well, that's what Drupal 6 supported: PHP4. Drupal 7, on the other hand, requires PHP5, so you could argue that it should have been a complete OO shift. Which completely and utterly contradicts your backward compatibility argument. However, many OO elements have been added in D7, and many more are yet to come in D8, which, AFAIK, is the complete OO rewrite everyone wanted.

extremely poor documentation

You've got to be kidding me. Drupal's documentation is excellent when compared to other open source projects I've had to work with.

100 modules doing the same thing

Yeah, more hyperbole there. Hurray. And while you have a point here, that's basically a side-effect of a community like Drupal. It's also not nearly as bad as in the case of Joomla or Wordpress, as Drupal is much more framework oriented.
But, if you want a walled garden ecosystem, look elsewhere, and don't complain that you will lack the merits of the Drupal community.

slow sites

While Drupal sites may not usually be the fastest out there, you just have to know what you're doing to get it to perform. http://buytaert.net/drupal-performance

no foreign keys in the db

The entire Entity API and Field API uses foreign keys. There is also the excellent Entity Reference module, which basically contains foreign keys of other entities. That's also part of D8 core.

no consistency in the db

Again, Entity API and Field API, just to name an example.

Peace to those who follow the guidance.

cosminadrianpopescu’s picture

Well of course there are legacy elements in Drupal. Like I said, do you want backward compatibility or fast innovation? Can't have it both ways.

As I was giving example, take the Qt framework and lots of other frameworks. The backwards compatibility does not necessarily prevent innovation. Windows XP still contains old legacy code from Win 3.11. And you cannot argue that Windows XP is not an innovation over Win 98, over Win 95 over Win 3.11.

Yeah, there we go again with the whole MVC thing. This article is old, but still good: http://www.garfieldtech.com/blog/mvc-vs-pac
There's also this one that's a bit newer: http://robknight.org.uk/blog/2011/02/explaining-architectural-tiers-drupal/

Quoting an article saying the PAC is better than MCV does not make it better.

You do know that PHP's OO support is pretty young, right? And that it didn't really work very well in PHP4? Well, that's what Drupal 6 supported: PHP4. Drupal 7, on the other hand, requires PHP5, so you could argue that it should have been a complete OO shift. Which completely and utterly contradicts your backward compatibility argument. However, many OO elements have been added in D7, and many more are yet to come in D8, which, AFAIK, is the complete OO rewrite everyone wanted.

You know that PHP 5 is out in 2004 and Drupal 6 in 2008, don't you? So 4 years I would say that they could've have a complete rewrite, considering that they do not have any backward compatibility what so ever any way. So, what's holding them back? OO is not that easy any more. Not any dumb Drupal developer will be able to handle it. You need a little bit more knowledge for OO.

You've got to be kidding me. Drupal's documentation is excellent when compared to other open source projects I've had to work with.

Yes, take for example the db_query documentation (https://api.drupal.org/api/drupal/includes!database!database.inc/function/db_query/7).

To quote from there: "$options: An array of options to control how the query operates". That is soooo clear. The options variable is cristal clear. I read the documentation and I have to guess what the hell I am suppose to send as options. Or, being a Drupal guru probably I know it already by heart. Not to mention the total lack (for Drupal 6 documentation in the past) of a see also, of examples on the help page. Again, see the documentation from the Qt framework.

I know that now they are a lot of improvements in the Drupal documentation, but still the documentation is extremely bad.

The entire Entity API and Field API uses foreign keys. There is also the excellent Entity Reference module, which basically contains foreign keys of other entities. That's also part of D8 core.

You got to be kidding. That is a module. The Drupal core has no foreign keys. Absolutely none. Again, because dumb developers will not be able to cope with them. It might be part of D8 core, but is not part of D7 or D6 core. I was speaking of D6 and D7. I haven't yet used D8.

Again, Entity API and Field API, just to name an example.

Again, not part of the core. Like that you can argue that the Views are fully OO.

Cosmin Popescu

a.ross’s picture

Well alright one more.

Quoting an article saying the PAC is better than MCV does not make it better.

All you're demonstrating here is that you have not read the article at all. He's arguing that any kind of separation is good, that MVC is a kind of separation, but that many people have an incorrect understanding of what MVC is and basically just spout buzzwords. That's you he's talking about.

You know that PHP 5 is out in 2004 and Drupal 6 in 2008, don't you?

While PHP5 was first released in 2004, it wasn't widely available until 2008-ish. That's because Debian has had support for it since Debian 4, which released in 2007, and CentOS supported it since 5.0, which too was released in 2007. And webhosts usually take a long time to upgrade to the newer version of $platform. So there is no way that D6 could have required PHP5. You could argue that D7 should have been a complete OO rewrite and have made some slight sense, if it weren't for the fact that it would have been a lot of work due to resource constraints. And again, that contradicts your backward compatibility argument.

Yes, take for example the db_query documentation

I could quote examples of great documentation. Anecdotal evidence does not count as such.

You got to be kidding. That is a module. The Drupal core has no foreign keys. Absolutely none.

Drupal 7 entities use field storage, which means every field has their own database table, which are linked to their corresponding entity with a foreign key. Then there is the taxonomy field, for example, which contains the foreign keys of taxonomy terms. The only issue is that the foreign keys are not enforced on the database layer. The Schema API does allow for defining them on the database level.

Again, because dumb developers will not be able to cope with them.

That's just conjecture. And it doesn't make any sense, considering that "dumb developers" (or any developer for that matter) use the Drupal APIs to communicate with the database. Unless they don't use Drupal...

Again, not part of the core.

What are you talking about? Entity API and Field API are part of core!

Peace to those who follow the guidance.

cosminadrianpopescu’s picture

All you're demonstrating here is that you have not read the article at all. He's arguing that any kind of separation is good, that MVC is a kind of separation, but that many people have an incorrect understanding of what MVC is and basically just spout buzzwords. That's you he's talking about.

Yes, sorry, you are right. I didn't really read it, just skim it. But anyway, where do you see the separation in form API? Again, saying that drupal is PAC does not make it PAC.

While PHP5 was first released in 2004, it wasn't widely available until 2008-ish. That's because Debian has had support for it since Debian 4, which released in 2007, and CentOS supported it since 5.0, which too was released in 2007. And webhosts usually take a long time to upgrade to the newer version of $platform. So there is no way that D6 could have required PHP5. You could argue that D7 should have been a complete OO rewrite and have made some slight sense, if it weren't for the fact that it would have been a lot of work due to resource constraints. And again, that contradicts your backward compatibility argument.

Please see the post before. Having legacy code does not impede innovation. The could still have a great drupal_json_output function in Drupal 7 and have a drupal_json function calling the drupal_json_output and generating a warning about the function being deprecated. I know, it's more work, but that's what makes a good framework.

I could quote examples of great documentation. Anecdotal evidence does not count as such.

This demonstrates that you really did not read my post regarding the db_query documentation or read the documentation itself. I quoted from the page: "$options: An array of options to control how the query operates". Are you really going to argue that this is good documentation? And like this function, in the past there were literally tens (maybe hundreds) of function in D6 documentation. I admitted already that the things are improving, but still the lack of "see also" or "examples" on many help pages makes it a very bad documentation.

Also the modules documentation is so poor. I know that this is no the fault of the Drupal developers, but when I have no docs what so ever on modules, no docs what so ever on the core it self, I tend to say "what the hell"?

And in the end, please have a look at an free framework with an excellent documentation: https://qt-project.org/doc/qt-4.8/qapplication.html

This is how good documentation looks like.

Drupal 7 entities use field storage, which means every field has their own database table, which are linked to their corresponding entity with a foreign key. Then there is the taxonomy field, for example, which contains the foreign keys of taxonomy terms. The only issue is that the foreign keys are not enforced on the database layer. The Schema API does allow for defining them on the database level.

I am not 100% sure that you understand what foreign keys are. The fact that you draw them in some diagram does not make the db have foreign keys. Enforcing them in the db layer means that you have foreign keys. The fact that you consider the vid from taxonomy_vocabulary to be a foreign key in the taxonomy_data_terms table does not make it a foreign key. Look at the table definition. Where do you see foreign key work?

If I want to manually delete a vocabulary, I need to go and also manually delete the terms. Because of the lack of foreign keys. And then I need to know the database structure very well to also delete what ever else needs to be deleted.

So, again. There are no foreign key what so ever in the drupal db.

That's just conjecture. And it doesn't make any sense, considering that "dumb developers" (or any developer for that matter) use the Drupal APIs to communicate with the database. Unless they don't use Drupal...

Some times is faster to skip the Drupal API and go directly for the database.

What are you talking about? Entity API and Field API are part of core!

I thought that you are referring to the entities module, which is not part of the core. However, even though Entities API is part of the core, is still not using foreign keys (see above).

Cosmin Popescu

a.ross’s picture

Yes, sorry, you are right. I didn't really read it, just skim it.

I rest my case.

But anyway, where do you see the separation in form API?

Form API is an extension of Render API and has got nothing to do with the DB. Don't know what you're on about then. Did you mean to mention the Entity API, which includes creation/form logic? That does have clear separation.

Please see the post before.

No. We're moving in circles. I get your backward compatibility point, and I said from the beginning that Drupal can do more in that department. Again, you gave a very specific example which doesn't bear any weight. Talking about backward compatibility of the Node, Taxonomy and comment modules would be interesting. And in those cases it's near impossible to be backward compatible, as those use the new Entity API.

This demonstrates that you really did not read my post regarding the db_query documentation or read the documentation itself.

I don't know how I gave you that impression. I said that anecdotal evidence is not evidence, which is in no way a contradiction nor a confirmation of your argument. In fact I know the documentation of the db_* functions and I think that @see explains what you need to know. What's your point? In D6 there was no $options parameter! Examples are plentiful, if you just care to have a look under the 'calls to X()' section.

I am not 100% sure that you understand what foreign keys are.

Oh I understand just fine. Just look at the docs for hook_schema. And then look here (notice the foreign key definitions?): https://api.drupal.org/api/drupal/modules!node!node.install/function/nod...

Some times [when?] is faster to skip the Drupal API and go directly for the database.

Clarification needed. When you have drush eval, the Devel module and other possibilities to directly access the Drupal API, why would you browse through PHPMyAdmin for CRUD operations?

Peace to those who follow the guidance.

cosminadrianpopescu’s picture

Form API is an extension of Render API and has got nothing to do with the DB. Don't know what you're on about then. Did you mean to mention the Entity API, which includes creation/form logic? That does have clear separation.

I mean to say that there is no separation what so ever between the html and php code. If I want to modify a div, to make it bigger, or smaller, many times I need to go into the php code to find the shitty form api element and modify in php code. This is the worse way to develop for web. And if I want to use the templates, to skip the form API, the Drupal way strongly discourages this.

No. We're moving in circles. I get your backward compatibility point, and I said from the beginning that Drupal can do more in that department. Again, you gave a very specific example which doesn't bear any weight. Talking about backward compatibility of the Node, Taxonomy and comment modules would be interesting. And in those cases it's near impossible to be backward compatible, as those use the new Entity API

Why would it be impossible? It's not just the drupal_json_output function. There are a lot of functions which changed the name just for the sake of changing name. And this is moronic to say the least.

I don't know how I gave you that impression. I said that anecdotal evidence is not evidence, which is in no way a contradiction nor a confirmation of your argument. In fact I know the documentation of the db_* functions and I think that @see explains what you need to know. What's your point? In D6 there was no $options parameter! Examples are plentiful, if you just care to have a look under the 'calls to X()' section.

Again, I was admitting that the docs for D7 are getting better. But the calls to X is not an example. That's not showing how to use it. It's just a convenient way for the creators of the docs to just finish their job quickly. Nothing more. Again, see the doc for the Qt framework.

Oh I understand just fine. Just look at the docs for hook_schema. And then look here (notice the foreign key definitions?): https://api.drupal.org/api/drupal/modules!node!node.install/function/nod...

Oh, but I really think you don't. Also, the fact that is in some code file does not make it a foreign key.

show create table node;

CREATE TABLE `node` (
  `nid` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'The primary identifier for a node.',
  `vid` int(10) unsigned DEFAULT NULL COMMENT 'The current node_revision.vid version identifier.',
  `type` varchar(32) NOT NULL DEFAULT '' COMMENT 'The node_type.type of this node.',
  `language` varchar(12) NOT NULL DEFAULT '' COMMENT 'The languages.language of this node.',
  `title` varchar(255) NOT NULL DEFAULT '' COMMENT 'The title of this node, always treated as non-markup plain text.',
  `uid` int(11) NOT NULL DEFAULT '0' COMMENT 'The users.uid that owns this node; initially, this is the user that created it.',
  `status` int(11) NOT NULL DEFAULT '1' COMMENT 'Boolean indicating whether the node is published (visible to non-administrators).',
  `created` int(11) NOT NULL DEFAULT '0' COMMENT 'The Unix timestamp when the node was created.',
  `changed` int(11) NOT NULL DEFAULT '0' COMMENT 'The Unix timestamp when the node was most recently saved.',
  `comment` int(11) NOT NULL DEFAULT '0' COMMENT 'Whether comments are allowed on this node: 0 = no, 1 = closed (read only), 2 = open (read/write).',
  `promote` int(11) NOT NULL DEFAULT '0' COMMENT 'Boolean indicating whether the node should be displayed on the front page.',
  `sticky` int(11) NOT NULL DEFAULT '0' COMMENT 'Boolean indicating whether the node should be displayed at the top of lists in which it appears.',
  `tnid` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'The translation set id for this node, which equals the node id of the source post in each set.',
  `translate` int(11) NOT NULL DEFAULT '0' COMMENT 'A boolean indicating whether this translation page needs to be updated.',
  PRIMARY KEY (`nid`),
  UNIQUE KEY `vid` (`vid`),
  KEY `node_changed` (`changed`),
  KEY `node_created` (`created`),
  KEY `node_frontpage` (`promote`,`status`,`sticky`,`created`),
  KEY `node_status_type` (`status`,`type`,`nid`),
  KEY `node_title_type` (`title`,`type`(4)),
  KEY `node_type` (`type`(4)),
  KEY `uid` (`uid`),
  KEY `tnid` (`tnid`),
  KEY `translate` (`translate`)
) ENGINE=InnoDB AUTO_INCREMENT=29535 DEFAULT CHARSET=utf8 COMMENT='The base table for nodes.'

Please notice that the engine is InnoDB (so don't tell me that my db layer does not support foreign keys) and still no foreign key. Again, only the foreign key keyword in the creation of the table makes a foreign key. That's it. You could say that that is a foreign key, write it in 1000 php files, in 1000 text files, in 1000 docs. Still, if it is not in the DB, it is not a foreign key.

Clarification needed. When you have drush eval, the Devel module and other possibilities to directly access the Drupal API, why would you browse through PHPMyAdmin for CRUD operations?

For example, when I need to do complex views that take to long to run. I really think that the Views module is one of the good things in Drupal. But sometimes the queries would just take too long. In this case I usually use the View XML module (to take advantage of all the formatting options offered by the view module) to create my own optimized query. This way I am able for example to reduce the running time of a view from 2 minutes to 2 seconds.

And they are also other situation in which I need to go directly in the db. For example when a module does only do 80% of what I want it to do. In order not to modify the module code, sometimes I prefer to go and do some operations manually in the db.

Also, if you check the code of the taxonomy_vocabulary_delete (https://api.drupal.org/api/drupal/modules!taxonomy!taxonomy.module/function/taxonomy_vocabulary_delete/7) you'll notice that this is far from optimum. A foreign key would've make it far more rapid.

Cosmin Popescu

a.ross’s picture

Why would it be impossible? It's not just the drupal_json_output function. There are a lot of functions which changed the name just for the sake of changing name. And this is moronic to say the least.

You're not answering my statement about Node, Comment and Taxonomy modules. You're just continuing about minor changes that, even when combined, don't carry a lot of weight.

the fact that is in some code file does not make it a foreign key.

You're right, in fact. But does that necessarily mean it's a "bad" thing? Let's have a look: https://drupal.org/comment/5986132#comment-5986132 Be sure to read the rest of the discussion in that thread, make your contribution if you want.

Peace to those who follow the guidance.

cosminadrianpopescu’s picture

You're not answering my statement about Node, Comment and Taxonomy modules. You're just continuing about minor changes that, even when combined, don't carry a lot of weight.

I am sorry, but are you sure you understand what backward compatibility is? The fact that the function name is the same (node_load, for example) does not make it backward compatible. The result of the function differs. So, where do you see the backwards compatibility when it comes to nodes?

The taxonomy: do a taxonomy_term_get in D6, then do it in D7. Ooops, that's right. It's not there. Where is the backwards compatibility?

As for the comments, I didn't really used it, but I have doubts that there is any backwards compatibility there also.

You're right, in fact. But does that necessarily mean it's a "bad" thing? Let's have a look: https://drupal.org/comment/5986132#comment-5986132 Be sure to read the rest of the discussion in that thread, make your contribution if you want.

Although I completely agree with a shift towards a no SQL db, as long as they are offering the possibility to have a relational db, they should enforce the foreign keys. That if we want to have a good consistent framework. Otherwise, we have Drupal.

Cosmin Popescu

a.ross’s picture

I am sorry, but are you sure you understand what backward compatibility is? The fact that the function name is the same (node_load, for example) does not make it backward compatible. The result of the function differs. So, where do you see the backwards compatibility when it comes to nodes?

The taxonomy: do a taxonomy_term_get in D6, then do it in D7. Ooops, that's right. It's not there. Where is the backwards compatibility?

Wow! Reading comprehension much? Like I said, it would be fair to speak about backward compatibility in major components like those modules. Because combined, they make up a major part of the system. And - let me make this crystal clear - backward compatibility in those components is nearly impossible. Why? Because they use the new Entity API. Remember my argument that innovation vs backward compatibility are (mostly) a dichotomy? That's what I was talking about here, not that those modules are an example of backward compatibility, on the contrary. Hope that clears that up for ya...

Although I completely agree with a shift towards a no SQL db, as long as they are offering the possibility to have a relational db, they should enforce the foreign keys.

Sure, I'd say help to make it happen. That's not an easy feat to the best of my knowledge. Resource constraints? Drupal needs more contributors and less whiners.

Peace to those who follow the guidance.

cosminadrianpopescu’s picture

Wow! Reading comprehension much? Like I said, it would be fair to speak about backward compatibility in major components like those modules. Because combined, they make up a major part of the system. And - let me make this crystal clear - backward compatibility in those components is nearly impossible. Why? Because they use the new Entity API. Remember my argument that innovation vs backward compatibility are (mostly) a dichotomy? That's what I was talking about here, not that those modules are an example of backward compatibility, on the contrary. Hope that clears that up for ya...

Yes, that clears it now, but it was an honest mistake. Just so you know, I read it again (the original post) and still I think it could be interpreted either way. I was thinking that you tried to give me an example on where they have backwards compatibility although it was very difficult.

And now, to the point: I am giving a very general example where functions just changed their name. It's not just drupal_json. There are lots of functions which just changed the name without any innovation what so ever. You want examples:

* taxonomy_term_get => taxonomy_load_term
* drupal_set_header => drupal_add_http_header
* db_fetch_* => gone. Now the db_query (another example) returns directly the PDO object.
* db_query
* taxonomy_get_vocabularies => taxonomy_vocabulary_load_multiple
and I could fill at least one screen.

You want to change the name of the function? Fine. Nobody says don't do it. Just retain for a little longer the other function and the other format. You can even fill in the screen with warnings when I call that function. Just don't take it out completely. You want to see how to deprecate things? There you go: http://www.php.net/manual/en/oldaliases.oci8.php

As for the nodes using the new API entities? So what? They can still maintain the same format (for example for node_load) and you could set it for example in the preferences to return the Drupal 6 format or the D7 format. Just an idea. Of course there are other ways to maintain backward compatibility. But again, more work.

Sure, I'd say help to make it happen. That's not an easy feat to the best of my knowledge. Resource constraints? Drupal needs more contributors and less whiners.

I have lots of contributions to the free software (not as many as I would want, but any way). And although I created lots of Drupal modules, I will never ever contribute a module or a line of Drupal code. Why? Because I totally disagree with their backward compatibility policy. I do not think it normal that I develop a module for D6 (in my own time) put it out there, and then when D7 comes out, I have to totally rewrite it. It's one thing if a new API is out and I rewrite the module to take advantage of that and to improve it and it's another thing to just rewrite it to change db_fetch_object to $query->fetchObject().

And don't tell me that some one else will do it if it's a good module, because that's not the point. I don't do it because I don't want to encourage this practice (not having any backwards compatibility between major versions). And I really consider that the community should stop develop any Drupal modules until this major huge bug it's fixed.

Cosmin Popescu

a.ross’s picture

So you boycott the Drupal community. Fine. Be on your way now.

Peace to those who follow the guidance.

cosminadrianpopescu’s picture

So again, when you ran out of arguments you send me on my way. Because I boycott the community, I should not be allowed to criticize the project?

I boycott the community because Drupal has no respect for its community, for the work that community is doing.

I am not saying that I will only contribute if they solve all the things that I consider wrong with Drupal. I solved already some of those myself. And I would gladly contribute the code. But first, solve your biggest issue and have some respect for my work.

Why do you consider that if I am not with the community I am against it? I don't have anything against Drupal community. If you want to create modules for Drupal, if you don't care that your work is not appreciated, fine. Create modules. But don't tell me that I should also accept this, because I don't. I don't use Drupal by choice. It's just life. But because I use it, yes, I improved it here and there. And normally of course I would give the code back. But have a little respect for my work, Drupal creators.

Cosmin Popescu

a.ross’s picture

Have a little more respect for the Drupal creators/maintainers, is all I'd like to say.

Peace to those who follow the guidance.

cosminadrianpopescu’s picture

This is the last reply in this worthless discussion.

I am sorry if I upset you, but I really don't think that it was worthless. Somebody has to point out also the Drupal flaws.

Cosmin Popescu

Jaypan’s picture

Somebody has to point out also the Drupal flaws.

Well, you've done very well in pointing out what you believe to be flaws, but you haven't shown that they actually are. Example:

You want to change the name of the function? Fine. Nobody says don't do it. Just retain for a little longer the other function and the other format. You can even fill in the screen with warnings when I call that function.

I don't see this being a good idea in the least. Websites need to run fast (you even complained that Drupal is slow). Leaving in a whack of old, unneeded code, with checks to see if it is being used, and warnings to tell you that it's deprecated etc are going to add a whole lot of unnecessary overhead to the system. And this overhead will slow down the system. And slow systems lead to worse SEO (search engines prioritize faster page loads).

So because you think that the system should be backwards compatible, the rest of us have to deal with a sluggish system, less innovation, and issues that directly affect our clients (and our own sites)?

I can understand *why* you want backwards compatibility. You just haven't made a good case for the benefits it would provide outweighing the disadvantages it would add.

So to get back to the original comment: "Someone has to point out the Drupal flaws" - let us know when you find some flaws to point out. And maybe try to do it in a more palpable manner, as:
1) You haven't paid a cent for Drupal
2) The people building it are doing it for free

Right now you are just screaming entitlement.

Jaypan’s picture

Look at the source code of the drupal_json and drupal_json_output and tell me where the innovation is.

Well, the clue isn't in the code of the function itself, but rather in the overall scope of the Drupal JSON API.
Drupal 6 JSON functions: https://api.drupal.org/api/drupal/6/search/drupal_jso
Drupal 7 JSON functions: https://api.drupal.org/api/drupal/7/search/drupal_jso

You'll notice that Drupal 6 only had one function - drupal_json(). There wasn't a lot of need for a descriptive function name, because there was only one function with nothing to compare it to. Drupal 7 has four drupal_json functions. Having a single function named drupal_json() would not be particularly descriptive.

Now, you could say 'well they could leave the function name the same for backwards compatibility', but the fact is that it was decided long, long ago that Drupal wouldn't be backwards compatible, so calling someone a 'moron' because they changed that function name, when there was requirement of backwards compatibility that would be an imperative to keep the function name the same, is well immature really. The person wasn't a moron, they were simply developing the system under the circumstances of which the system was expected to be developed.

To be honest, your whole attitude doesn't paint you well. I'd suggest asking for a full refund, and using your money to buy a system that meets your requirements of backwards compatibility. Either that or fork Drupal, and create your own backwards compatible Drupal derivative, I guarantee that others would support you in it. You wouldn't be the first to want to go in your own direction: http://backdropcms.org/

But in the meantime, calling people morons, and saying you would be 'embarrassed' doesn't do anything for anyone, other than make you look rude. It doesn't help the community, it doesn't improve the product, and it doesn't improve your situation other than maybe making yourself feel better for lashing out at some anonymous developer.

gaydabura’s picture

Good luck

maryus88’s picture

Looks faster. Nice job!