I think I've only seen the idea of a Drupal App Store floated on Twitter. However as the movement continues for the meta-issue on making core maintainable, I can totally see what the Drupal App Store people were talking about. It's just too bad they associated with with a highly profitable monster corporation.

One thing Drupal does leverage better than any other is a single, central authority for downloading contributed modules and Drupal doesn't use that to its advantage as I think it could. Let's not call that central location a Drupal App Store. Let's just call it the Drupal Module Installer. I bet someone at Lullabot can come up with a better name, but it can't have "App" or "Store" in it.

I think the overall Drupal maintainability issues is a symptom to the need for an improvement to the module search and installation process. If you could browse popular modules in contrib from your Drupal site, which don't come included in the .tar.gz, and then could install them without having to do extra chmodding, ftp, or sftp config, then that's the vision I see for the how to get this kind of functionality as part of an install profile.

The installer should have some magic sauce to handle the installation. It's possible that it could borrow from the Drush engine, but Drupal should never expect the average Drupal site administrator to need to resort to using a terminal to install a module. Solve the issue of difficult interaction with contrib, and issues like arguing about OpenID, blog, and poll in core I think will go away because then putting OpenID in core will be a transparent matter of `drush dl openid` in the background magic sauce.

When I was new to the Internet, I volunteered for a corporation that hosted websites. I wanted to help create a community where people share their graphics and text with passers by. That little company was named Geocities. It was popular and grew fast.

They had a program they fostered of members, called Community Leaders. They even hired a full-time team of staff to help coordinate the Community Leaders and provide infrastructure. We had a forum where we talked about TOS violations, design awards, greeting new members, etc. I wrote a weekly column I posted to the forum called, "My weekly suggestion." I had an opinion about everything. Soon Geocities went public, then was bought by Yahoo!. It got so big that they didn't need us volunteers anymore. We were cast aside, our forum disabled and deleted, and our contacts at Geocities were told not to talk to us anymore.

Fortunately, even though Drupal is growing, and its best parts are getting 0wned by venture capitalists, there's no entity (yet) to cut-off my unsolicited opinions about Drupal.

The Drupal Association has grown up and out-grown the need for a General Assembly now. It has regular, steady income from DrupalCons. The mere existence of the event seems to attract a minimum quota of people and their money.

The DrupalCon revenue for the Association is good, and it's good for Drupal. It funds the infrastructure and the people who host that infrastructure. Highly specialized and skilled technologists are in demand, straining their little bits of volunteer time, especially those with a bend towards Drupal. That's good, too, for the individuals.

Venture capitalists are interested in Drupal. I think I read a tweet from Dries or someone that Drupal runs 1% or 10% of all websites? Either is a crazy big figure. I've been trying to hire a great Drupal developer at Classic Graphics for months. People have found a niche within Drupal development, specializing in a specific clientele. They won't talk to me for the wrong portfolio. I don't talk to other shops since I turn up my nose at their portfolio as well. We're in such high demand, we can be the snobs that we are.

However in the face of all this growth, I left the Drupal Association GA just before the GA dissolved because it grew up to something out of my interest.

Now I face the upgrade task on my personal websites and at work to move from Drupal 6 to Drupal 7, just to keep up with the latest module updates. At Classic Graphics, the upgrade will take us months. It'll be nice to use the new coder update tools to get us started, but I can't imagine that doing the multitude of API updates alongside new feature development will come any faster than a timeline measured in months.

My blog is simple. I have few modules I actually need. It can probably all be wrapped into pathauto, blog, image, book, comments, and mollom. I consider myself a rather skilled developer, been at it for years, and in the path of Drupal news much more than the far majority of Drupal users. In a weekend, giving it a real effort, I failed to even get my site to stop white-screening in Drupal 7. I'm not at mad at any developer, maintainer, or myself, just disappointed.

When I tell people what I do, I still throw Drupal into the description somewhere. I describe Drupal as a "website management software package," but I see the Drupal core team, as nebulous as that is, struggling with the identity and target audience for Drupal. Is Drupal an enterprise platform for a Lullabot to run the Grammys, for major universities to serve websites to 50,000 students, for the US government to host the executive's homepage? Is Drupal for my non-technical, 60-year-old Aunt to download, find a host, and start her own blog, or is it for me to host this site, or will it be a good resource for me to throw up an alternative to a meetup group for a local mom's club where they can manage membership, send email announcements, and schedule meetings? Maybe it's good for a forum.

For anyone who's been looking at Drupal, any version, they should laugh a kind of pitiful laugh at the last, forum suggestion.

Almost 2 years, 2 days ago, I posted a test for the core development group. I titled it Remove OpenID from core. Today I saw a post from sun about The Drupal Crisis, attempting to sum up how "Drupal core is not maintainable anymore." He should know, he's a badass. Seriously, I mean that in the best light. However, the same commentary for an unmaintainable core is coupled with a comment on my openid issue about *expanding* the core implementation of OpenID and adding two more different implementations. I can't help but point out that chx closed my openid issue, though he tweeted about the article from @tha_sun in apparent endorsement of its contents, even before it was officially tweeted. Perhaps I'm mis-interpreting the entire connection I'm drawing?

If the reason that something needs to be in core is because it won't succeed in contrib, that's a bad reason. Core devs have a multi-specialized focus of talent on *system design*, or should anyway. I'd rather see the effort put into creating an interface, call it an API if you must, for contrib modules to plug into core authentication. If there is a team of developers interested in maintaining a specialized feature, those same people can be just as interested maintaining it in contrib as in core.

What makes it possible for me to use Drupal successfully at Classic Graphics is the hook system. I can plug anything in anywhere and keep it secure with database-scrubbing APIs. It manages users, their roles, and permissions for me. When I want to put data in Drupal, I can CCK-it in, and Views it out.

One thing that scares me about how Dries and Angie handled Drupal 7 was their tendency to follow shiny objects. It happens everywhere in the Drupal leadership. It scares me a bit in the Drupal Association. I went nuts the first time I was to vote on a Drupal Association budget and it projected spending far in excess of any previous DrupalCon revenues. Man oh man, do Drupal entrepreneurs shoot high! Most of the time, my grumbling was for nothing - it's all worked out. I'm a grouch. Ask my wife, she'll agree. However, I'm certain Drupal core has lost focus. It did not improve in Drupal 7 on the things that made it great. *The* reason for me to upgrade will be only to keep in step with the latest module releases.

This whole discussion isn't new. The theory of smallcore has been around for at least 2 years. Adrian Rossouw wrote about it in 2009. The smallcore.org domain keeps getting redirected to a new article about it by Eaton.

What's the plan to course-correct the development of core, and more importantly who will do it, as chx asked almost 2 years ago? I'd sure feel better if I heard Dries say Drupal is off course.

I barely keep up with my contrib modules. I decided 6 years ago that I didn't have the stomach for core development's atmosphere for bantering reviews on issues, so I tend to only snipe off patches which require a few lines. Dealing with simpletests is an outright deterrent to my participation.

All I have to offer right now is my long-term background with Drupal to arm-chair blog about it. My proposal, regardless of my specific distaste for OpenID and it's likeness to Microsoft's login, is simple and generic. A mission statement for Drupal 8.

Foster a Drupal core where features will succeed in contrib.

That's it. Broad isn't it?

Return Drupal to a website content management platform. Drupal's inputs and outputs should be more abstract than blocks. It should be more abstract than panels. Each needs a system to manage their outputs.

When did phptemplate become the only template engine? I don't mean when did xtemplate and smarty get removed, I mean when did it take over in the minds of developers as the only way to do template development? Why couldn't we drop a python-based template engine in and have it work just fine with the rest of core?

Maybe to handle contrib-friendly-ness, Drupal has to make the core (and security) infrastructure necessary to import modules for my aunt as database-stored, eval()-executed, magically-handled in the background, super sauce, while still supporting filesystem-hosted versions for the enterprise. I don't know, I just made that idea up tonight.

As an example of something I think is on the right track, take DBTNG. Why is the Drupal collective trying so hard to keep pgsql and sqlite in core? Damien and Karoly have done a perfectly fine job of creating alternate engines and they can work without being in core. The database.inc design is just right for dropping in new engines and keeping the API the same to other non-database contrib.

I don't think I'll do any good by pointing out specific modules I would target for contrib-formation. There are unfortunate matters of logistics to getting back on track. I think when Drupal realizes it's purpose in life, it will feel awfully silly about putting on so many module pounds and it will shed them to contrib.

I'd like to think there would be half as many modules in Drupal 9 core as there are in Drupal 7, but that's probably an inappropriate measure since what I hope for is a transformation of modules which have highly specialized use cases to ones which manage the inputs and outputs of data generically. By managing the inputs and outputs, that will require having some user access control, some file management, and some software management.

P.S. I mentioned a lot of specific names in this article. If one of them is you, it is because I see you as a figurehead in Drupal. You have done great things. By comparison, I have done very little, and for that, I should be thrown in the pool with all the dead, rotting kittens from bad patches. My intention was to be cautiously inspirational, but now it's 2am, I'm not going to review my rambling, and I'm just hoping somewhere in the previous paragraphs that I said something that accomplished that.

At DrupalCon Chicago 2011, Dmitri Gaskin had a presentation titled, "From Zero to Distribution using Features, Profiler, and Drush Make." If you don't already know how to make your own Drupal distribution, he summed up the entire process expertly, however there was one detail in his presentation I've never seen before; it was an ASCII Druplicon when he opened his terminal.

Linux users call that the message of the day, or MOTD. On MacOS, that file is located at /etc/motd, but isn't created in a default installation. If you'd like a Druplicon MOTD, I reproduced what Dmitri had in the video on archive.org. There are versions for white (like Dmitri) and black (like mine) terminal backgrounds.

I know I could hide the last login by touching ~/.hushlogin, but that would also hide the motd output, so if someone would like to leave a comment on how to print the motd, but not the last login, that's the last piece to rounding out this copycat job. Otherwise, the solution is to add extra newlines at the bottom of the motd to cause the last login information to scroll off the screen.

I started a node import of 700,000 address records to a custom content type in Drupal 6. I was only getting in input rate of about 91 nodes/minute, which would take about 128 hours.

Then I switched from MyISAM to InnoDB tables. No significant change.

Then I dropped all the database indexes from the content type table, node, and node_revisions table except for the primary keys. No noticeable change.

To speed it up, I disabled Xdebug and added APC. Then I disabled the following modules to bring the enabled module count down from 58 to 42:

• admin menu
• content copy
• color
• update status
• content form jammer
• generic jammer
• mail logger
• advanced help
• diff
• r4032login
• user import
• rules admin ui
• filter permissions
• log user filter
• bonus views export
• views ui

That changes things. It moved from about 91 nodes/min to 908 nodes/min.

nodes/min	Xdebug	Drop indexes	Disabled modules	Disabled modules w/ APC	Disabled modules w/ APC, no indexes
MyISAM	91	92	883	908	940
InnoDB	90	91	875	836	1003

I noted that the InnoDB import went faster than MyISAM without indexes on the content type, node, node_access, and node_revisions tables. I even took extra rate samples just to make sure that was correct, and it seems to be.

Another thing which isn't represented here is that the import clearly slows down as the tables grow in size, so if you're importing several hundred thousand records as nodes, expect that the rate of import will decrease as the import progresses. That fact is probably reflected in the difference between the "Disabled modules" and "Disabled modules w/ APC" figures as my timing in doing rate samples wasn't exactly the same when I did each case.

The summary is clear, though, and Khalid is right again. The single biggest impact you can make to speed up your node imports, or your site in general, is to disable some modules.

I have several websites installed in subdirectories on my Mac laptop at /Users/davidnorman/Sites where I pointed the OS-included installation of Apache to use as my DocumentRoot. This weekend, I switched one of the sites installed in a subdirectory to use the root of my DocumentRoot as the source of the "File system path" setting at admin/settings/file-system.

Since the private setting, outside the expected installation of Drupal is supposed to be able to support writing files, I had to chmod my DocumentRoot directory as 777 to get the setting to save, even though I just wanted to read some files there, not write. Note: Though I did not do it recursively, chmodding the root of your web tree as 777 is is a BAD thing in most circumstances.

After setting the private file system path in the subdirectory Drupal 6 install, none of the PHP scripts anywhere in my DocumentRoot worked anymore. The chmod wasn't the problem though. One of the reasons the file system path has to be writable is that Drupal adds a .htaccess file to that directory which effectively disables script execution for security's sake.

The result in the Apache /var/log/apache2/error_log was simply a mysterious, unhelpful bit:

[Sat Jan 08 21:08:16 2011] [error] [client 127.0.0.1] Attempt to serve directory: /Users/davidnorman/Sites/

That is the error I would get regardless of whether I tried to load http://localhost/, http://localhost/phpinfo.php, or http://localhost/drupalinstallation/.

The solution: Remove the .htaccess file that Drupal automatically added at /Users/davidnorman/Sites/.htaccess. Also, pick a different subdirectory, other than the web root for private files in your subdirectory installs of Drupal.

Let this serve as a reminder that chmodding your web directory, even in your sandbox, to 777 is a bad idea, and that the root of your web tree is not a good dumping ground for private file system path settings on subdirectory Drupal installations.