Re: Call for Help: Drupalify the KDevelop website
Milian Wolff <[email protected]> Thu, 30 Dec 2010 15:36:23 +0100
| Newsgroups | gmane.comp.kde.devel.quanta.user,gmane.comp.kde.devel.kdevelop,gmane.comp.kde.users.kdevelop |
|---|---|
| Message-ID | <[email protected]> |
Sam S., 29.12.2010: > Hi again KDevelop team, > > this seems like a fitting occasion for me to throw in some lines again > on this mailing list. Hey Sam, long time no see :) > > our current website is unmaintainable and contains lots of obsolete > > legacy content. I want to improve that by creating a new website based > > on Drupal and link to the current website for legacy content (KDevelop > > 3.x). > > The old custom CMS does have its charm, and is certainly well > customized for the specific content that has accumulated there over > time (and there is *a lot* of content there, especially considering > translations, etc). > > But if you plan to make a "fresh start" with new KDevelop 4 content, > then Drupal is indeed a great choice. > The Drupal nodes, fields, views, and taxonomy features should easily > satisfy all the content structuring and displaying needs the KDevelop > website might have. > Even "advanced features" which I envisioned in my original design > mockups[1] (in case you still care about that), like a breadcrumb-bar > and context-aware "quick access link" boxes, should be fairly > straightforward, once the underlying content structure is set up > properly. Yep, Drupal is powerful and works well. > > My current WIP is already in git, in the kdev-www drupal branch, see: > > https://projects.kde.org/projects/extragear/kdevelop/kdev- > > www/repository/show?rev=drupal > > A few comments after taking a quick look at the repository: > > 1) I'm not sure how much sense it makes to track a Drupal installation > in a Git repository, seeing as the actual website data (structure, > content, configuration, customization...) lives inside the MySQL > database, not in the file tree. > The only thing that definitely makes sense to track with Git is the > implementation of the custom theme. > Furthermore, a script of "Drush"[2] commands, or a "Drush Make"[3] > makefile, capable of reproducing a Drupal installation file tree > (Drupal core + modules + theme) identical to that of the live website > could be kept around (and up-to-date) either in Git or in the Wiki. I didn't know drush make before, thanks I'll try that out eventually. It sounds like it really would make it possible to only track the theme in git, much better. > 2) You shouldn't put contributed modules into the "modules/" directory > directly underneath the Drupal root, but instead into the > "sites/all/modules/" directory. > (To cite the Drupal documentation[5]: "The modules folder at the top > level of your Drupal installation is reserved for Drupal core modules > (the ones that come with the original download of Drupal). So, you > should generally create a sites/all/modules/ directory and put > uploaded modules there.") Oh boy, some years of Drupal usage and I didn't know this ;-) Thanks. > > Furthermore we have server space provided by the nice guys at Kollide.net > > (which also host Konversation, Amarok, ...). > > Do you have ssh access to that server space? > If so, you can use the aforementioned "Drush" tool also for > installing/updating modules on the live site (as well as performing > various other administrative tasks). It will make your life easier... Yes, I have full SSH access and will try out drush make soon. Thanks, -- Milian Wolff [email protected] http://milianw.de _______________________________________________ Quanta mailing list [email protected] https://mail.kde.org/mailman/listinfo/quanta
signature.asc
(application/pgp-signature, 198 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk0cmOgACgkQDA6yEs0dE5O4NQCgjk8oPUeUbLKuNOWVl88pvAA+ 9toAnRccNYOYYFrPqzbzsir3cD+IfcxL =asyt -----END PGP SIGNATURE-----