February 2006 - Development - lists.drupal.org

Re: [feature] click on thumbnail to expand to the original image size without reload (lightbox.js)
by Ken Collins 25 Feb '06

25 Feb '06

I've seen it said before that image.module would best be kept simple and lean. I've used the lightbox.js in my theme and I think this is a better place for it, at the theme/user level. If you are interested you can download the theme and see the code that I used to make it work with lightbox.js. http://www.metaskills.net/meta-theme-for-drupal/image On Feb 25, 2006, at 8:52 AM, ica wrote: > Issue status update for http://drupal.org/node/51299 > Post a follow up: http://drupal.org/project/comments/add/51299 > > Project: Image > Version: 4.6.0 > Component: image.module > Category: feature requests > Priority: normal > Assigned to: Anonymous > Reported by: ica > Updated by: ica > Status: active > > Would be nice feature improvement if lightbox.js implemented as > optional > feature (click on thumbnail to expand to the original image size > without > reload) > > > ~example, scripts and and tutorial > http://www.huddletogether.com/projects/lightbox/ > > > the javascript is tiny > http://www.huddletogether.com/projects/lightbox/lightbox.js > > > > > ica >

1 0

Managing node revisions with a backend like subversion?
by Derek Wright 25 Feb '06

25 Feb '06

I posted this topic as a development forum on drupal.org: http://drupal.org/node/50682 Someone suggested I send it to this list for additional input and feedback. Summary: Why do we reinvent the wheel of doing revision control when we could (possibly) just use another revision control system to manage the change history of node bodies? We're currently storing the entire body for each revision, which is wasteful, especially if the size of the node is large, or it's changing frequently. For example, if I was going to import the entire manual for the software project I develop on my day job into a drupal site, a) I'd definitely need to save revision history and b) that history would grow enormous if the full text of each page was saved on every change. One (complicated) option would be to store diffs in the node_revision table, just like most revision control systems do. A (maybe) better option would be to just store the name of a subversion tag (or equivalent). We could still cache the full text of the currently active revision in the drupal DB (for performance and minimizing changes to other parts of the drupal code base), but we could split off the work of maintaining the whole revision ourselves and use a much more powerful tool for the job. Then, it'd be trivial to add much better revision support within drupal, for example a "blame annotated" view of a node, powerful diff viewing across revisions, and perhaps even something crazy like branching and merging node text (possibly integrated with taxonomy?). For more info, check out the forum node I mentioned above. I'd be willing to help make this a reality, but I wanted to know: a) Is there some obvious reason this hasn't been done (other than lack of developer time)? b) What's the right way to go about this? I'm fairly new to drupal, especially the core code. There seem to be numerous layers of abstraction for everything, so part of me (wishfully?) thinks there's some obvious layer to make this change and very little else would need to be modified. Am I being crazy? ;) c) Does anyone else think this would be a good idea, worth doing, etc? Thanks! -Derek p.s. It seems like the forum topic would be a better place for this discussion, but I'm new to this list so I don't know if people prefer talking about this via email, instead....

4 4

Is contributions/modules/ mirrored for bazaar-ng?
by Rob Thorne 25 Feb '06

25 Feb '06

As a developer who spends a lot of time hacking on other people's modules, I'm starting to get why bazaar-ng's development model can be a good thing: it can take a long time for people to merge/handle patches, and the need to test my work makes it necessary that anyone I'm working with "know" what the latest versions are of the stuff I'm working on. I can do that if I check my changes into a branch using bazaar-ng, something that is very hard to do otherwise. For one thing, I need my stuff in source control way before the module maintainers I'm working with can/will check in interim versions. core is now in bazaar-ng (at http://drupal.revisioncontrol.net/core/head/) which seems to do what I need. Is contributions/modules up on drupal.revisioncontrol.net as well? Thanks, Rob Thorne Torenware Networks

2 1

Re: [consulting] A defense for new users
by Bèr Kessels 25 Feb '06

25 Feb '06

Op zaterdag 25 februari 2006 00:40, schreef Bill Fitzgerald: > RE the tension between developers/consultants/end users, it definitely > exists, but I see these categories as pretty fluid. Whether people want > to admit it or not, we stand to gain more from working together. While > it won't be possible to include all perspectives in an eventual > solution, excluding viewpoints from the outset is not a good way to start. Oh I am sure thee are: * Lots of places where improvements are so trivial that I am rather concerned we only talked about stuff and not made that 15 line patch (admin/XXX/settings vs own admin pages). * Some places where we need a bit of thought and then get a Good Default merged in (inline files, user-permissions etc) * a few places where, with small effort we can gain a lot of improvement. But I am sure there are a lot of places too where: * A good default will make loads of developers (users) feel like they are "enforced" some thing they never liked. IMO we should respect the feelding of the devels, over those of the "users" (user == the one using drupal, yet not contributing anything else then weight-of-usage) * changes in the interface always end in a big BANG of debates; and are thus unchanged, eventhough we all know it sucks. Yet we all envision completely different solutions. It has been mentioned *cough* before. But empowering distros in this, is the route to take. And that is luckily not IMO but IGO. I think therefore, that a solution lies in: * fixing those areas that are very obvious. * not starting those endeless debates on "who drupal is for in the first place" (sorry, I am guilty here too). but instead recognise that Those Who Do It are the same as Those Who Need It (scrathcing and itching). Sorry, I know I am officially banned from saying it, but I have no time now to spend on: * ?q=admin/comment/configure * ?q=admin/themes/settings and more. But I am sure there are more of those places where ni debate and hardly any effort is needed to et real improvements going. Bèr -- [ End user Drupal services and hosting | Sympal.nl ]

1 0

google just pwned the brochureware site industry
by Adrian Rossouw 25 Feb '06

25 Feb '06

http://pages.google.com Go play with the site editor, that's how our themes should work damnit. layouts / skins -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

17 25

4.8/5.0: Modules, the install system, and directories
by Morbus Iff 24 Feb '06

24 Feb '06

This is what I'd like to see in 4.8/5.0 which would tie up some "loose ends" as it were with some of the direction that Drupal is moving in. These are bullet points because I'm heading off to work, but I'll be more than happy to wax further. * Modules get their own directory. (modules/system/system.module). * All modules get own .install (modules/comments/comment.install). This way, all the relevant tables of a module are "closest" to the source, and won't actually get thrown into the db until someone enables them (I hate the fact that I've got about 15 tables I'm not using in my Drupal database. Just drives me nuts.) This also helps update.php in that it will only need to go through ENABLED modules, instead of performing updates for unused tables. We can also pre-create/publish nid 1 in modules/node/node.install without having that dummy hardcoded text, a long standing issue. * databases/ directory is removed entirely. By giving each module their own .install, we don't really need databases/ anymore - we'd just need to, at first run, check if table system exists. If not, find all required modules and run their .install. This way, we remove the entire schema creation step of the INSTALL. All the existing updates.inc would move into system.install. This is nice, IMO, because it'll make a purdy friendly installer a lot easier to create (as it'd just have to send to the frontpage after DB config/QA instead of sucking in databases.mysql). * Modules get an activate, deactivate, and uninstall hook. I think Merlin was working on this to some degree. Activate enables the module, deactivate disables it, but keeps the created data, prefs, and tables in place, and uninstall removes everything. This mimicks the operation of Gallery 2 modules - the uninstall part is awesome! If I use search.module for a week on my 5000+ node site, then find out it's just not good enough, I don't want those gigantic tables hanging around forever, taking up backup space. If I uninstall search.module, those tables and data should be removed. * .install files get aggregator_schema_version() function which tells the installer which version number to set in the system table on FIRST INSTALL. This way, it's not calling or seeing a number of updates that are already applied to the initial starting table. (I think this is a problem in our current install system, right?) * By putting modules into their own directory, we're making it easier for some of those comments.help related ideas to kick in - to stick the help text in an external file and call it only when needed. I also think that chx's splitmode is a lot nicer if we could constrain the split functions to their source directory instead of having a primary directory full of 1000+ mini-files. I coulda swore I had more in the shower, but I've to go to work now. -- Morbus Iff ( accept no prostitutes ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

17 60

find the absolute order of hooks and modules?
by Anders Hamilton 24 Feb '06

24 Feb '06

Hello, Does anyone know if: Is it possible to find out the order of hooks calls when a page is called? Is there a rule or function that determines this? Is it immutable and dependable information that can used in the creation of a module? Is it possible to find out the order of modules being loaded when a page is called. Is there a rule or function that determines this? Is it immutable and dependable information ? I seem to remember seeing that modules are loaded in alphabetical order. Is this true? Would it be safe to say when a forum node is called then Comment Forum Node is the order? or would it be something different everytime? TIA (sorry if this is a duplicate but my mail does not seem to go through to the list is there a delay of some sort ?)

6 8

4-5 week absence
by Dries Buytaert 24 Feb '06

24 Feb '06

Hello world, with my marriage around the corner (March 25) and our honeymoon directly after that, it is almost time for me to unwind and disconnect for a while. As of March 15, I'm going to take a 4-5 week (one month) break from everything Drupal. I don't want to announce this on drupal.org yet, but I soon will. I talked to Steven about this on more than one occasion and we'll be talking about this some more during the weekend. In short, he'll take over the day-to-day maintenance during my absence. Depending on the state of Drupal CVS HEAD / 4.7.0, I might also add one or two (interim) core committers. More about that later. For now, I just want to let you know about my scheduled absence. -- Dries Buytaert :: http://www.buytaert.net/

8 7

Re: [infrastructure] packaging script problems
by Ken Collins 24 Feb '06

24 Feb '06

Matt, My theme contribution was packaged just recently, first time in almost a week, but there are still some problems. If you take a look at my commit logs these commit numbers dating back to the 18th are not being packaged, even though they are in the correct branch. #26490, #26466, #26447, #26378, #26153, #26148 http://drupal.org/project/cvs/43376 Odd thing however, there were new file additions on the 22nd that were packaged correctly, #26465 and #26464. Any body else seeing this? - Ken On Feb 24, 2006, at 2:44 AM, Dries Buytaert wrote: > > On 24 Feb 2006, at 02:30, Matt Rae wrote: >> Hi, the packaging script wasn't being run by cron for some reason. >> Moved >> it to be on the root crontab which may work better and be a better >> place >> for it. If any problems arise let me know. > > The crontab was running on drupal1. Maybe it got disrupted after > drupal.org got switched back to drupal2? > > -- > Dries Buytaert :: http://www.buytaert.net/ > > -- > [ infrastructure | http://lists.drupal.org/listinfo/infrastructure ]

1 0

Bugfixing
by Karoly Negyesi 23 Feb '06

23 Feb '06

According to Dries, http://drupal.org/project/issues? projects=3060&versions=9902,9842,9753,9728,6487&categories=bug&priorities=1&states=1,8,13,14 has 49 entries. There are 749 members on this list. Let's assume that only 1 percent of them are core quality (that's nonsense). Even then, one bugfix a day will close all of them by early next week. Before you turn in, check whether you have fixed your critical 4.7 bug today. It takes usually half an hour at most. To heed my own advice, I just closed two. There are 47 now. Keep me posted in this thread. This week Dries is occupied with upgrading drupal.org. Next Monday I want to point him to an empty list and ask for a release candidate. We can do it. Just one patch every evening and a short note here that you did it. Go!

14 21