June 2007 - Development - lists.drupal.org

Current head seems to have been broken for a while...
by Arancaytar Ilyaran 12 Jun '07

12 Jun '07

I know that right now the CVS head is completely unstable as the code freeze for 6.x hasn't happened yet. But I do occasionally check out the latest version to play around with it a bit, and I'm confused that a fatal error has been in there for quite some time. Namely, common.inc calls "file_directory_path()" on line 1769 before this function has actually been defined - I think because bootstrap hasn't been called yet. I'm quite sure I have an unmodified version from CVS. So if I wanted to have a peek at how Drupal 6 is going to look (if that's even possible at this point) what should I download? I can't wait... ;)

2 3

Naming the CVS abstraction module
by Jakob Petsovits 12 Jun '07

12 Jun '07

Derek (in his mentor role) and I are in search of a good name for the module that I'll develop during this Google Summer of Code. (...once again, as the directory in CVS will be recreated due to other reasons.) We need your input on this issue, as none of the options seems to be the ideal one. Objective of the module: To abstract the existing CVS integration into a separate API and an accompanying set of projects, so that we can more easily plug in other backends for different version control systems like Subversion, git, etc. Now, naming this thing is a bit hard, as there's no widely standardized term for these things which handle repositories and stuff. We can currently think of the following names for the module: - rcs.module / "Revision Control System API" Slightly suboptimal since there already is a revision control system that goes by the name of "RCS". As the predecessor of CVS, it's not very common these days, but people still use it. So when calling the module "RCS API" it might be mistaken for the original RCS. - vcs.module / "Version Control System API" Better, but the name is quite verbose. I'd personally prefer "Version Control API" because it's snappy and easy to grasp from the beginning. However, there are other drawbacks on this. - vc.module / "Version Control API" Fixes the previous issue, but occupies a top-level acronym ("VC") that is used for a common term like Venture Capitalists, selected indiviuals also think of Visual C when reading this acronym. So this screams for namespace clashes. Also, it doesn't immediately prompt associations for version control with most people, which is certainly the case for "VCS" or "RCS". - versioncontrol.module, and other long names Annoying as function prefixes in the code, I'd rather prefer short ones. - scm.module "Source Control Management API" Sounds reasonably good, looks reasonably good, but has the unfortunate drawback that it specializes on source control. There may be people though who use revision control for other stuff like client documents or config files, so this doesn't quite fit as well. - Other proposals? If you've got a good idea that we hadn't yet thought of, do tell us. Please chime in on this issue. The development list might not be the most fitting place for this discussion, but given that the feedback in the SoC group on the same issue wasn't all too extensive (say, none until I specifically promted my other mentor Andy) we thought it appropriate to bring this issue to the mailing list. What do you think would be the best name for this module? -- Jakob, SoC student

17 33

OT: bzr users, Launchpad bzr mirror up to date again
by Karoly Negyesi 11 Jun '07

11 Jun '07

Hi, There was a hiccup on Launchpad which caused the import scripts to stop. This has been resolved and --among others-- the Drupal HEAD mirror is functioning again. Regards, NK

1 0

Requiring node revisions
by David Strauss 11 Jun '07

11 Jun '07

Currently, there are two revision-control options when saving a node: 1. Overwrite the latest revision. 2. Create a new revision. I think #1 has very little value. Argument for allowing #1: * Slightly smaller database size Arguments for only allowing #2: * Fewer site administration options * Cleaner node-editing pages for node administrators * Less confusion over what checking the box does: "Aren't I creating a new revision of the node even if I don't check it?" * Less node-saving code. Currently, many modules have to redirect new revisions to the node creation code. We can dump hook_update if every node save is a new revision. A module can still check if it's really a new node if the module needs to do anything special. * Better-tested node-saving code. I sometimes find modules that don't work properly with revisions. * Site administrators will have more options to recover from mistakes without having to remember to check a box or configure every content type to create new revisions by default. * Using modules that automatically clean up old revisions can cap the increase in database size. * Files are shared across revisions, so there's little increase in disk space. * There's no performance impact to keeping old revisions around. A JOIN on {node_revisions} happens regardless of whether multiple revisions are in use. * Lots of users are accustomed to editing Wikipedia, so seeing a revisions tab shouldn't be scary to new users of Drupal. * Even if they don't know how to use the revisions tab, the site will function exactly as if they didn't use revisions. Even cheap shared hosts allow ridiculous amounts of space, so database size isn't that important anymore. Unless there's a really compelling argument for leaving #1 around, I'd like to create an issue to eliminate the ability to save a node without creating a new revision in Drupal 6.

25 62

Use revisions to replace previews
by David Strauss 11 Jun '07

11 Jun '07

With clever use of revisions, we could eliminate the preview system entirely from the codebase. Here's how it would work. If a user clicks Preview, it creates a new revision but does not mark it as the current revision. The preview seen is the new revision rendered. If a user clicks Save, it creates a new revision *and* marks it as the live one. Optionally, we could then delete the interim preview revisions. Another advantage to this is that a user can work on a node, preview it, and have their work saved. If a user comes back and edits the node with unsaved previews, they can choose to work from the latest preview or the latest public revision. I know Drupal 6 goes a long way to fixing previews, but this would eliminate all inconsistency.

14 28

Can I move the sites and profiles directories?
by Dave Cohen 11 Jun '07

11 Jun '07

I'd like to separate my work from core Drupal. As of 5.x, Drupal supports the sites/all directory, where I can put my modules and themes. And that's a great step in the right direction. However, to make my source code more manageable, I'd like my sites and profiles to be outside the Drupal directory. Without going into too much detail, this will allow me to manage my code with svn's externals property. So today my directory structure looks something like this: www/drupal-5.1/index.php www/drupal-5.1/sites/ www/drupal-5.1/profiles/ www/drupal-5.1/[lots of other things] And what I'd like is something like: www/drupal-5.1/index.php www/sites/ www/profiles/ www/drupal-5.1/[lots of other things] The trick then would be to get Drupal to find my sites and profiles directories. Is my only option to hack core? Any other suggestions? Note that I don't want to set up symbolic links from www/drupal-5.1/sites to my sites directories. I have my code (including the drupal core I am using) in subversion, and I'd like to checkout out an entire site in a single step. Having to replace Drupal's sites and profiles directories with symbolic links is an extra step I'd like to avoid. Thanks in advance for any help, -Dave

5 6

"Go PHP 5" for MediaWiki
by David Strauss 10 Jun '07

10 Jun '07

Brion: Some of my friends in the open-source CMS community have created a movement called "GoPHP5" which will eventually reside at GoPHP5.org. We're trying to encourage projects to -- as of February 2008 -- drop support for versions of PHP prior to 5.2. This would not mean older versions that support PHP 4 would be abandoned, just that new releases would only officially support PHP >= 5.2. This is an effort to have web hosts support modern PHP versions. Right now, there is little incentive for web hosts to upgrade because so many web applications support PHP 4 and old versions of PHP 5. We'd like to get MediaWiki on-board. Because the current version of MediaWiki already requires PHP 5 and runs on PHP 5.2 without problems, this would not be as jarring to MediaWiki as it would be to projects that still release new PHP 4-compatible versions. Currently, we're in talks with Drupal, Joomla, CakePHP, Symfony (already in), Symfony's partner projects, Gallery, and WordPress. Thanks, David

2 1

Re: [development] Book to Book-Pages... Many to many
by Ken Rickard 09 Jun '07

09 Jun '07

Two simple answers. 1) Kevin, I read in digest mode and missed a character when changing the subject line. I am hoping to integrate with D6 after I finish first cut of the module to solve my immediate need. If I'm right and this feature doesn't exist, it seems a natural extension of the new Outline approach to books. 2) Dan asked: > Here's the magic question: Are the nodes in each "instance" really clones, > as you described, or are they actually just a single node? I'm hoping for > the latter: I need to be able to edit the node once, and have it changed in > every book or outline it lives in. Something like symbolic links, in > filesystem terms. Dan, you and I have a slightly different use-case. I want the base node to be the same, but then diverge after the new book is created. For example, we're tracking client projects, so we create a new "skeleton outline" for a "Client" which contains the following page nodes: Title (node type) - Overview (book) - Project Schedule (CCK) - Billing Schedule (CCK) - Client Contacts (page or CCK) - Our Contacts (page or CCK) - and so on... I'm also integrating with NodeAccess to provide preset node grants, so that each book instance can be locked per-page by role. That would let the Client see pages some pages, the developers other pages, and the project manager even more. I'm rolling this out for an Intranet site designed to track contractual relationships, so that the legal staff sees one set of pages, the developers another, and so on. That said, with what I'm building, you could theoretically make your template node simply call node_render($nid) [yes, this isn't the right code] for the "parent" node as the node body for each "instance" node. Then edit the "parent" node instead of the "instance" nodes to make changes. Again in theory, the parent could have status "unpublished" and simply deliver its contents to the instance nodes. All that said, if there are already ways to do this, someone send me a note off-list, as I hate to waste time. (And that said, this project really gets me into CCK, node_access and hook_form_alter(), all of which I don't use much... so that's a good thing.) - Ken Rickard agentrickard

1 0

Re: [development] Naming the CVS abstraction module
by Michelle Cox 09 Jun '07

09 Jun '07

Ok, I admit I have no clue about CVS or this module but when I saw this email, what came to mind is VCAPI.module. Long enough to not be quite so confusing but not as long as writing it all out. Michelle On 6/8/2007 9:04:18 PM, Rob Barreca (rob(a)electronicinsight.com) wrote: > I like Version Control API, and think a module named > versioncontrol.module is fine. Sure it's a bit more code, but IMO it's > better to err on the side of being too explicit, than having people > scratch their heads seeing vc.module.

6 5

Re: [development] Naming the CVS abstraction module
by andy＠spiders-lair.com 09 Jun '07

09 Jun '07

> Yes, I think that one is sensible. I'm currently drawn between > versioncontrol.module (longer code, but better name) and vcs.module > (short code, not so perfect name). The longer name is nice but, as said, since it'll integrate in a few places vcs.module gets my vote. Given the fact that projects have both a long name (for normal display purposes) and a short name (for files and function) I don't see the short name being much of an issue? --Andy

1 0