- Development - lists.drupal.org

Inventory Management module
by "Schultz Consult - [René Madsen]" 03 Nov '06

03 Nov '06

Hi, I'm searching for developers, who might would like to help with making the inventory management modul ready for druapl 5.0 The module is not completly finished for drupal 4.7, but it will soon be ready, but I would like to have it tested and would like some feedback. http://drupal.org/project/inventorymangement is the address. It would also be greate if someone else would contribute to the module, since I'm the only developer at the moment. -- Best Regards René Madsen

4 7

Re: [development] Upload pictures directly from node (not from EDITpage)
by Metzler, David 02 Nov '06

02 Nov '06

For the future: This type of question is best answered on the support list. I'm on both lists, so I'd be happy to coninue this discussion on the support list if you don't mind. If you're clear (from the support list) that drupal doesn't do what you're looking for you might consider adding a feature request on drupal an appropriate contrib module? In regards to your question: Img_assist (image assist) module is provides the functionality, but its still from the edit page. Can't really answer your question without knowing: 1. What would you want drupal to do with the images attached to a node? In what way are they attached? If you don't have an editing context, how would drupal know where to put the image on the page? 2. What is the problem with doing this on the edit page? 3. Have you thought of this problem on other ways? Are you trying to create a gallery (there are modules for that), or are you trying to publish a page, or upload an image for use within a page? 4. Are you familiar with the wysiwig editors used in drupal such as tincymce? These may offer features that you're looking for. ________________________________ From: development-bounces(a)drupal.org [mailto:development-bounces@drupal.org] On Behalf Of marcob Sent: Thursday, November 02, 2006 7:17 AM To: development(a)drupal.org Subject: [development] Upload pictures directly from node (not from EDITpage) Howdy, i followed the support list for some time, but this is my first post, so first of all my big up to all the people who use their for making Drupal a better place :) My support question: Upload pictures directly from node (not from EDIT page) can anyone tell if there actually is a way to let users upload/attach images to posts (nodes) directly from the node page? Now all (?) the image modules require users to go through the EDIT form. What i mean instead is the very classic/basic "upload an image" field *directly* on node page. The closest thing i found is the Image_tab.module: it adds an "add images" tab to the desired nodes. Still i reckon the easiest thing for users is the upload form on node page. Also the module is still cvs and not finalized for 4.7 yet and quite buggy... Please, any hint greatly apreciated! Cheers, Marco

1 0

Multiple drop-down boxes for 1 category
by Ámon Tamás 02 Nov '06

02 Nov '06

Hello, I have a vocabulary with multiple (or single) hierarchy. For example this: animals -cows -dogs -rats colors -red -purple -white etc. If I add a node with this vocabulary, I like two drop-down boxes: First with animals, colors, and when it is change, I like to change the second drop-down box with the firsts sub-categories with ajax. With which hook can I change it? Or there is a similar module? (This is similar this: http://pear.php.net/manual/en/package.html.html-quickform.html-quickform-hi…) -- Ámon Tamás http://amon.hu

4 3

Re: [development] Drupal 5.0 beta 1
by Reynier Perez Mira 02 Nov '06

02 Nov '06

Hi to every: >From where I can download this Beta? Cheers -- ReynierPM | 5to Ing. Informática Aprendiz de mucho, maestro de poco. > -----Mensaje original----- > De: development-bounces(a)drupal.org [mailto:development- > bounces(a)drupal.org] En nombre de Dries Buytaert > Enviado el: 31 October, 2006 9:53 AM > Para: development(a)drupal.org > Asunto: [development] Drupal 5.0 beta 1 > > Hello world, > > we just released beta 1 of Drupal 5.0. We'll roll a release > candidate when all critical bugs have been fixed. When it takes too > long to fix those, we'll roll a beta 2 in a couple of weeks. > > This is quite exciting so great work, folks! Rock on. :-) > > -- > Dries Buytaert :: http://www.buytaert.net/

5 4

RFC: debate on branches and versions in the new release system
by Derek Wright 02 Nov '06

02 Nov '06

a healthy debate has sprung up between kjartan and myself on what the "main" branches compatible with a given version of core (e.g. the "DRUPAL-5" branches) should mean in the new release system. after a few email exchanges and a few debates on IRC, it seems like dries, webchick, and a few others are fairly happy with the current implementation. however, dries suggested i write up the debate and send it to the devel list for input... request for comments: http://drupal.org/node/92452 thanks, -derek (dww) p.s. this is one of the *last* things standing in the way of deploying the new system. all the major reviews are now done, and i've only got a few hours of touch-up work to do. once this debate is resolved and i finish off these minor updates, documentation is the only thing standing between us and the happy new world of versioned releases. ;) therefore, please speak-up soon if you care about this debate, since the window for discussion will be relatively short. thanks.

1 0

Drupal 5 release schedule: update
by Dries Buytaert 01 Nov '06

01 Nov '06

Hello world, it has been exactly two months since the start of the Drupal code freeze: http://drupal.org/drupal-5.0.0-code-freeze As the development cycle was only 3 months, a 2 month code freeze should have given you plenty of time to upgrade some of your themes and modules. If you haven't upgraded your modules/themes yet, I wouldn't wait too long. While I want at least 2-4 weeks of public beta testing, there are only 3 critical bugs at this point in time. http://drupal.org/project/issues? projects=3060&versions=10195,9902,9842,9753,9728,6487&categories=bug&pri orities=1&states=1,8,13,14 Chances are that we'll need fewer betas/RCs than we had for Drupal 4.7. Also, now we're in beta mode, we're going to be a lot more strict with regard to usability patches. Small usability patches and documentation improvements can still go in, but larger usability patches are likely to be postponed until Drupal 6.0. -- Dries Buytaert :: http://www.buytaert.net/

1 0

Re: [development] Counting .info files [Was: Documenting contribs]
by Michelle Cox 01 Nov '06

01 Nov '06

On 10/25/2006 7:52:03 PM, Chris Kennedy (chrisken(a)mail.utexas.edu) wrote: > Back to the original topic, I recommend that any project description > revisions be conducted as informal "reviews" that are posted to the > module's > issue queue and can then be accepted, rejected, or modified by > the maintainer. This preserves the > contributors' autonomy while > encouraging quality improvements. I do agree that the module > descriptions are often of poor quality. I gotta be honest here.. If I need to file and monitor an issue for every little change, I'm unvolunteering. That's entirely too much work. I went ahead and started this about an hour ago, starting at Z and working my way up. I made sure revisions was checked and notified the author of the one I made fairly substantial formatting changes to. If someone doesn't like what I've done, they can always revert it. Mostly all I'm doing is adding a break tag and maybe moving things around just a bit so the new teaser makes sense. I'm not completely rewriting their descriptions unless I find one that's just horrible and then I'll talk to the maintainer first. Michelle

15 21

Click-click! "Agree." "Next." "Next." "Next." "Finish."
by Max Bell 31 Oct '06

31 Oct '06

/delurk Hello, Everybody! I wanted to chime in on the subject of Drupal distribution profiles, ask a couple of questions, pimp my Drupal group relating to same (http://groups.drupal.org/drupal-distributions-strategic-cooperative) and solicit feedback on the lot. But first... YAY 5.0! YAY 5.0! YAY 5.0! I am SO ready for this beta! (and with THAT out of my system)... I really DON'T want to subject anyone to "lets just create a new web site and put all our information there" -- what I am hoping to do is be able to hand aggregate what information is available and put it in a central location (the group I created) myself. While I think it may be a worthwhile thing for those considering or actively developing a distribution profile to devote some part of that development time into focusing on the subject and collaborating with developers working on unrelated distributions, I am cognizant of how little it would take for such an effort to become extra work, rather than a means of saving work, so hopefully I can condense and consolidate the process a bit. My interest in this subject specifically stems from the time I spent posing as DeanSpace support and a couple of brief exchanges I had with Drumm on the subject at the time. In essence, having spent a short period installing DeanSpace for folks while chatting with them on AOL instant messenger, I discovered that the period of time consumed by the installation was an important and valuable opportunity to shape the user's experience with the product. Besides explaining how the installation worked as I put it together, I was also able to tell the user what other users were doing with the software and ask questions about what they hoped to do with it themselves, then show them (roughly) where to find the relevant administration functions and help them begin roughing out the vision they saw in their mind's eye. I don't really want to belabor the idea of installation as teaching experience, though, so much as explain that I'll be evangelizing the idea a little. Imagine, if you will, a series of Drupal distributions so comprehensive and coordinated that a novice web designer/site administrator could, having completed one installation, turn around and create a completely unrelated site based on a different distribution profile, using the skills and understanding developed during the first installation. An army of mini-Drupal distributions, branded and coordinated with the core distribution, marching across the face of the earth in a united front with the common goal of Drupal world domination, illuminating and facilitating the creation of unique and feature rich web sites tailored to specific markets while fostering user confidence and a general skill set that increases the pool of Drupal gurus available to assist new users and reducing the level of overall support required... (Shutting up, now) Back in the real-world, though, Dries really nailed it with his "we need to pre-herd the cats this will attract" post. Just a quick tour of the Drupal sphere will show that people are already talking about the "distribution profile" as labor-saving utility idea at least to a modest degree, and I can understand why they would. Consider the site designer who'd like a set of custom profiles to facilitate prototyping and deployment for new clients, or the hosting provider who'd like to automate client set up and offer a set of basic installation types, or the developer who just wants to knock-out a headless sandbox installation to save typing, prepopulate the database and set up utility modules. Clearly, none of these examples involve creating distributions developed for consumption by the general public and probably won't be intended to stand up over the long haul. But I would like to suggest that this utility be acknowledged and embraced with the caveat that it be clearly distinguished from distributions that will be made available for people to download and, potentially, generate support requests. That said, focus rightly belongs on distributions that potentially may occupy a directory next to "default" at some point. To that end, I wonder if it doesn't make sense to view the task of maintaining such distributions through the filter of "my distribution is still Drupal" -- in other words, to view developing distributions kind of like people view creating themes -- separate the presentation from the code. Core and contrib modules already have their own documentation, support and upgrade mechanisms in place and it makes sense to make use of them as much as possible. Keeping this distinction in mind also provides the added bonus of keeping focus where it belongs, with Drupal. While this will always be secondary to focusing on the requirements and functionality necessary to the market the distribution is developed for, "what's good for Drupal and, by implication, the collective sum of other distributions" should still trail a close second in a perfect world. Which brings me to note that thus far, installation profile development is still in it's infancy, the documentation written thus far is sparse and seemingly dated, and there isn't much in the API docs about the hooks involved. Thus I hope someone can take a moment and answer a couple of questions: 1) I number this mailing list, the support forums on drupal.org and it's sister site, groups, as potential sources where I might find folks talking about developing distribution profiles; I stay off of IRC because I can see myself doing nothing but keeping tabs on Drupal development full time, and I have to play with the software occasionally. Besides general RSS aggregation of syndicated nodes that might address the subject, though, is there anywhere else I should be looking that anyone can think of? 2) How closely are module installations and distributions related? I may answer this question in part, myself, since as soon as I finish this mail I am going to knock out a sandbox and create one using the documentation in the handbook. I just can't help but notice that the documentation references hooks I am not seeing in the API docs and so on. 3) Can anyone recommend any general-purpose reading for this subject (links?)? Again, I will do some digging on my own, but from experience (I generally create custom Windows installations before I reinstall and am learning how to accomplish this same end with Ubuntu, but I don't really see anything like a "best practices" list coming to mind between them). Finally, +1 to feeds/mailing lists enabled by default with the core distribution (and any other). I tend to suspect that prominently displaying a list of help resources at the end of the installation and then reinforcing this by making the same list readily accessible as part of the initial configuration may be a good idea. Having a feed or mailing list option enabled by default to channel support and the like to the correct destination would be even better, IMHO. So long as I'm rambling, one of my fondest wishes has always been for something like a meta-taxonomy for core feed categories (support, development, etc.) -- thus creating a kind of networked discussion area that would be automatically available/optional for newly created sites. I'll shut up, now, and close by pimping my "group for talking about Drupal distribution profile development groups" again (http://groups.drupal.org/drupal-distributions-strategic-cooperative)

1 0

Drupal 5.0 beta 1
by Dries Buytaert 31 Oct '06

31 Oct '06

Hello world, we just released beta 1 of Drupal 5.0. We'll roll a release candidate when all critical bugs have been fixed. When it takes too long to fix those, we'll roll a beta 2 in a couple of weeks. This is quite exciting so great work, folks! Rock on. :-) -- Dries Buytaert :: http://www.buytaert.net/

1 0

node_access arbitrator in Drupal 5
by Earl Miles 31 Oct '06

31 Oct '06

This actually happened a couple of months ago, but I delayed announcing it because it needed a bug fix before it could be used, and that took awhile to get through the patching system. The upshot is that since it's been in awhile, those in the know (uh, I guess that's me and Moshe) have managed to create/update some modules to take advantage of this system. First, the updating modules link: http://drupal.org/node/64279#node_access Second, what you need to know: If your module doesn't touch the node_access table, good for you. You probably don't need to do anything. If your module does touch the node_access module, at least to write to it, you're going to be hideously broken. You need to very carefully read through the new system. Basically, the new system calls a function called node_access_acquire_grants() whenever a node is saved; your module can also call this function (For example, when you change a setting that causes access changes for many nodes). This function does calls hook_node_access_records with the node, and modules that have an interest return a list of access rules, including a 'priority'. Only rules with the highest priority are considered, the rest are thrown away. If no records are returned for the node at all, a simple 'all' grant is written for the node. For a couple of other examples, see the Forum Access and ACL modules. Forum Access does roughly what it sounds like it'll do; ACL provides an API to attach access control lists to nodes and maintain them. Forum Access uses ACL to provide a 'forum moderators' list that the current taxonomy access system can't do. The biggest benefit to these is that access control modules can co-exist, though they still need to be a little bit careful.

1 0