Drupal 4.5.0 battle plans

will hopefully be in 4.5, also the changes to queue.module (if you don't put them into 4.4., that is).

I would like to contribute to enchance taxonomy.
I wrote and extended taxonomy module I would like to share with you.
Major things are:
- Vocabulary and term I18n (terms and vocabularies are translated in locale)
- Node type filtering (more than one node type can be specified as a filter)
I upgraded taxonomy_html to 4.4 and would like to maintain that module.

I'm also currently writing a module based on taxonomy_html that can help you filter on multiple terms.

I'm also working on a problem like this.
I have nodes categorized on several vocabularies (geography, genre, organization_type)
I would like to be able to filter with such filter:

select all nodes where
geography is one of these (x,y,z)
AND
genre is one of these (a,b,c)
AND
organization_tpye is one of these (d,e,f)

Actually, taxonomy 'or' does not work this way.
Is a feature like mine under evaluation on 4.4 or should I think to a way to do it with a specific module ??
My idea would be to filter with 'or' on geography and collect an array of nids, then do the same with genre

and organization_type. By interescting the three arrays I should get the final results.

I would like to share this work with someone else.

Matteo
mailto:webmaster@cantincoro.org

I'd really like to see locking go into core for Drupal 4.5.

As the average Drupal site grows, we're going to run into more cases of two people editing a node at the same time -- one person's changes being unintentionally lost. (As has happened on Drupal.org, and will in all likelihood start happening more as the community grows)

The include file lock.inc will also solve for race conditions, an annoying and persistent issue that numerous Drupal developers face.

I've submitted fully functional patches to solve for this. I'd love to either see it go into core, or hear what's wrong with the implementation so it can be fixed.

Once merged, then I intend to implement file-based locking within the provided lockapi, using the fileapi.

I have been especially busy during the last development period, and after the 4.4.0 release, I have quite a bit of code that i need/want to get into core over the next few months.

• Make drupal more fault tolerant, for example allowing it to start up completely without needing a database connection.
• Wizard system , for creating multi page submissions .. to be primarily used in the ..
• Install System. Which will hopefully be used to install the base system, contrib modules and possibly even themes by the next version
• Multisite configuration patch .. atleast pushing for it to be made through, as this opens up a lot of interesting possibilities for the install system
• Theme system improvements. apart from my phptemplate based theme for 4.4.0 , i want to enable drupal to use generic templating engines (ex: smarty, xtemplate, php templates and phptal) without any problem, as well as syndication of themes/templates using the install subsystem.
• several other contrib modules i have in the pipeline

This is the working list , but there are some other interesting ideas like a bittorrent tracker, and some css things.

  Sanity is a sandbox in the playground of my mind.
     I'm going to go play on the swings now.

I am planning to:

• Help on improving translate_node.module
• help on merging or splitting or whatever is apprpriate of locales and i18n
• Try to push them into the core.:)
• ... All this to improve possibilites for internationalisation

• Try getting a unified navigation method into drupal.
• I will try to do this based on Jeremys navigation.module
• Try to get some other navigation methods deprecated by this one

Ber

Mediarevolution.org :: het platform voor online muziek


spam related: bots may mail me here

There are a few Drupal projects on my plate right now.

1) The Doxygen documentation is coming along nicely, but much more work is needed. In particular, I plan to provide a modern replacement for the howto.module and place it in contrib/docs/examples/ for Doxygen to index. This will be a set of small toy modules that each instruct how to perform a particular task, such as defining a node type. The modules should be in the public domain, so developers can build on them freely regardless of their personal licensing preferences.

2) The menu system needs to be more all-encompassing, needs to be able to be presented in different ways by the theme, and should be configurable by the administrator. I plan on working on this. This is related to, but not necessarily the same as, a general content navigation scheme.

3) Drupal really needs a permissions system that can restrict access to specific pieces of content. I don't feel too qualified to lead the charge here, but I look forward to testing proposed ACL systems to ensure that they meet requirements.

4) Now that the "multiple node types per module" patch is in core, I plan on extending and promoting flexinode.module. I believe that with a little work, this could be an indispensable tool for administrators who do not know PHP.

These are my plans. How much progress I will make will depend on how much time I have available to work on these projects.

• Usability improvements:
  • Change all browser-visiable references to "node" to something that might make sense to someone who is not a computer geek.
  • Create a node zero feature. This would allow admins to create a custom node to be displayed to someone who visits and has no other access at all. It might work with Adrian's proposed database-less operation if node zero were stored in a text file, but I'm not sure on that part. Initial plan is to just have it be a normal database node. I've done some work on this already, but getting around the menu limitations is tough.
  • Make it possible to rename things like nodes and blogs without incurring the high overhead that locale.module incurs to do so. Most non-computer sophisticates are not going to understand the terms "node" and "blog" and thus, admin selectable terms like "article" and "journal" might be desirable.
• A contributed CSS-only, ultra lightweight theme. This is mostly complete.
• I want to come up with some features/code that will make version compatibiility issues easier to deal with. Most files have a CVS $Id$ tag in them now. All of them which do not, need to have it added. Even nicer would be to have that value available via a PHP query or get function of some sort. This could work with the proposed module testing functionality proposed by others. Ideally, we could capture the CVS Tag for a release somehow and make that available. Unfortunately, this is one of CVS's biggest flaws -- there is no keyword like $Tag$ that is expanded with the current tag. Getting this value into the files would require some coding and procedureal changes on the part of the folks who Tag CVS and package up releases. The goal would be to tell admins when they've attempted to plug in a module that is not compatible with the core they have, etc. and to allow someone to query the current level of their Drupal install for debugging purposes, or just to know what it is, because they want to go browse Drupal.org for compatible contributed modules or themes, for example.
• A node-level access control list feature. I've got some firm ideas as to what it should look like, and a rough idea what the database fields would look like. Haven't written any code yet, though.
• Someday, but probably not for 4.5, a geographic location module contribution. I've started on this, but the code is 4.3 and there's a lot of work to do yet.

I would like to spearhead the new permissions system effort, if the people who want it will allow me. I also plan to finish up my bibliography.module and make drastic changes to importpage.module. Also in the works are further modifications to htmltidy.module (more configuration options and finer-grain controls) and to pdfview.module (more of the same).

Some ways involve helping all future drupal financially.

What I would like to have is:

• Image Handling and Management;
• More meaningfull urls like;
• $node->type/(view|edit|delete)/$nid instead of node/(view|edit|delete)/$nid
• And so on..

This would be a great addition when combined with the conf_url_rewrite() inside conf.php.

I was on my way to adding multiple roles per user when my disk failed and I lost most of my work on that. D'oh! I'm going to try to recover that work in mid-April after my projects are finished.

Next release requirements:

- Adrian's installation wizard

- Multiple roles per user
- User-defined custom groups
- Simple per-node privacy control

I think these will be able to expand to include taxonomy permissions and more advanced permissions control.

-- Irwin

Once Pushbutton is bug free, and xTemplate documentation is done...

Extend xTemplate to make it possible to customised sections of a site through multiple CSS style-sheets.

For instance, a template can create a default look, and the Forum and Blog pages could each have a variation of that look. This could also be linked to taxonomy, so each term/vocabulary/book could have it's own look, making it possible to customise the look of each section of a Drupal site.

-- Pushbutton Test Experience -->>

- help re-architecting Drupal.org site (track the project "Drupal.org maintenance")
- improving core themes and adding additional CSS files for Chameleon theme
- improve visual presentation, usability and accessibility on everything Drupal
- start to post Drupal-promoting posts on my blog, to promote it on Estonian scene

I've got a filestore module about half finished that I've been working on for organizing some time lapse movies I want to post on my personal site. I'm not a big fan of the current filestore module. Last time I used it, all files were stored in the actual database, which I figured was a really really bad idea. I also couldn't get it to work right after a few hours of tinkering, so I figured I'd work on my own version.

Anyways, the one I'm working on is organized like a blog. Each file has its own entry in a user's personal filestore. The site admin can limit file size, number of files in users' filestores, and number of downloads per file per time period.

I've also developed a thumb module similar to node image, but it doesn't use javascript, and doesn't deal with images in any other way. All it does is allow a user to attach a thumbnail image to any node. (It's got the same downsides as the node image module - node.module has to be patched to allow file uploads for any node type, and some code has to be inserted into themes to actually grab the thumb and display it.)

Anyways, the thumb module is tied in to the filestore module such that you can associate thumbnail images with MIME types, and the filestore module has a filter (with the usual syntax) that allows the files to be included in other nodes (like a blog entry) and appear as a clickable thumbnail images. The images associated with the MIME types are fully configurable by the site admin, but I've got a set of default images for the standard MIME types that look OK.

I'm wondering if my filestore and thumb modules are worth contributing or whether people are happy with the existing versions. If I get any positive feedback, I'll contribute the thumb module and work on the filestore for 4.5.

Oh, I've also got a photo journal module that I've been using for my personal site. I just took the blog module from 4.4 RC and hacked the hell out of it. So in other words, it's just a straight photo journal, just like a blog. No galleries, no bulk upload or any of that image.module stuff. It uses the thumb module mentioned above. Wondering if this is worth contributing too. I refuse to install IIS on my PC, so I doubt it works on Windows.

While I was building the thumb and photo journal modules (I was sick for a couple of weeks and couldn't do anything else, so...), I worked out a design for an album module that would use the thumb and photo modules, but I don't really have a need to organize my photos into albums, so that's on the far, far back burner.

Well, there are several things that I've been working on, but here are a few that I plan to contribute:

1. A meta-theme (I call it "Dtheme") that can display a different "skin" to various parts of the site. This can be configured using taxonomies, user preferences, URL regexp's or hard coded for specific sections. Each "skin" is a single properly structured PHP file with proprietary section tags (html comment tags). This way, HTML developers can develop skins in their HTML development environment of choice. Current unfinished documentation is at my malnourished website.
   
2. Get the mailhandler module to handle attachments in a more elegant way. Perhaps there should be a MIME-type/file extention/node type mapping or registry somewhere that says what to do with content. I know Mailhandler could use this, but I'm sure content generated by other sources would find this useful as well. Along with the mapping there would have to be a hook that takes uid, content-type, filename, title and/or other arbitrary data and forms it into a well structured node. This would, for example, let the admin choose which module to use for handling images.
   
3. Have user_access() take an additional optional parameter of which uid to compare against the given access type. Generally, allow one user (cron, for example) to post on behalf of another user.
   
4. I have an object-relational mapper (yet another db abstraction layer) that is in use on a client site at this time. It was targeted at 4.3.0, but modifications to my Drupal implementation and Drupal itself since then have rendered much of it dysfunctional for regular users. Performance was suspect the last time this module was mentioned, so I intend to benchmark this module's performance and publish it along with an updated version for 4.5.0. I foresee this module's existence to be a battle in and of itself. Perhaps I should include a cost-benefit analysis so that no illusions are harbored up front. A non-current, somewhat older version can be found here. The current version is on a site that's way too modded to be useful to you.
   
5. I'll be submitting patches for feature requests/bugs as I see fit (greedy programming).

Though much of this is in progress, I hope to get it all done before 4.6 starts :P

I'd like to contribute to getting image handling and display into the core for 4.5, a priority mentioned by others. To that end, I've created a forum post for discussion and planning:

http://drupal.org/node/view/6667

Items I plan on doing in my copious free time:

• Make importing from other blog software easier by...
  • Finishing Movable Type import script
  • Possibly creating a Blogger import script
  • Cleaning up comment validation and saving in comment.module
• Help with documentation updates

I would love to utilize drupal internally at my company and have user accounts already be created in LDAP. So users wouldn't need to create an account, they could login using their existing unix username and password, it would query LDAP (iPlanet) to authenticate them, rather than the local database.

As Drupal is getting bigger and specially when you are using a lot of modules I am concerned about overall performance. I think too much iddle code is included every time a page is generated.

The bootstrap system, which takes care of the init hook, is a big step ahead, and I think is the way to go for the rest of the modules' hooks.

We need a hook system, that stores and manages all the hooks in the database and takes care of which files to include.
The hooks should be linked with a specific file, better than with a module, thus allowing big modules to be split in several files.

Also, some kind of 'install/uninstall/enable/disable' hook should be created allowing modules to take care of hook registration and maybe some more istallation tasks. Notice that a module needs to register the hooks itself because specific hooks can be implemented in a separate file, other than main .module file.

I'd like to see the syndication capabilities modularized and improved. Specifically:
- The built-in RSS syndication (import) works pretty well, but it doesn't create nodes for received articles.
- The add-on RSS syndication (import) supports Drupal workflow, but I haven't been able to get it to accept any RSS feeds. Perhaps all RSS feeds are technically invalid (pretty likely, actually), but it needs to be made more tolerant. I'd love to see the "import article = node" workflow added to the built in import, or the add-on import updated to work with 4.4/4.5 and made more tolerant of real-world RSS.
- I'd like to implement another syndication protocol (ICE2, see http://www.icestandard.org) since it has many advantages over RSS, such as push delivery, incremental updates, delivery confirmation, support for rich media, etc. It would be great if the import module had a pluggable syndication protocol so that I could implement ICE2 witout having to reinvent the syndication infrastructure or make a modified copy of that import module (i.e. a hack).

It would make it a bit easier to install Drupal modules if the database modifidcations were implemented by the modules, rather than by the user executing commands directly into MySQL (etc.). What would be ideal would be that the module would have a web interface that would ask for database permissions to make the changes (since it couldn't do so using the database access drupal normally has), and then execute the SQL to do its job. For an example, look at PPHLogger, a wonderful web usage tracking tool, that manages its own installation and configuration via a web interface, and is thus much easier to implement on a remote server where the user may not have command line access, or know how to use PHPMyAdmin, etc.

If one Drupal module implemented this as a model, I'm sure that others could pick the idea up quickly...

After reading a lot of the posts concerning the drupal permissions et.al. and being in need of a more sophisticated one, I decided to have a go at reworking the current drupal permission system. At the moment I have a (dirty) authorisation API, which allows to plug in your own authorisation/acl module. The approach tries to be minimally intrusive, yet provide for different permission schemes to coexist. Something similar to the Drupal authentication system for permissions.

Ok, that's too much talk. I will try and post the module and, maybe an example taxonomy based authorisation module within the next couple of days.

spreading confusion for the sake of humanity :)

Here's the customizations I've done on Civilities for the "civ" customizations intended for civic dialogue. I plan to make the modules a bit cleaner so that they can be distributed.

• ViewPoints - This is my proposed solution to simplify comment moderation/ratings and transform it from something onerous to something fun. I defined a set of rhetorical "ViewPoint" icons which a poster can use along with, or instead, of comments. Makes for handy ad-hoc consensus building as well.
• Flat-Threading - I thought I'd try to go beyond the flat vs. threaded conundrum once and for all, and combine the best of both. This also uses Dynamic HTML & javascript (no document yet).
• Story Types -Very simple concept: I overloaded the node.type column with a diverse selection of types along the lines of magazine departments. When you view the main page, it resembles the table of contents in a magazine.

Jon

I think that one of the most important thing Drupal needs is an ACL a la PostNuke, i.e. based (drupal speaking) on user+node+action.

I want to contribute on this strategic feature as I really need it on a project of mine that I'm working on, but I'd really prefer it to be an official develop of Drupal and not a patch that I need to apply several time.

To minimize the impact on the other modules I think it should act "transparently" and fall down on the current user+action scheme.

I'll wait for a response from who's in command... :)

Well, what I would like to see in a new release 4.5 is this:

• Better image handling. At the moment I'm using the image module, which for me seems to be the best around here, I know, there is also a patch for the Htmlarea to use it, but it's not working for me as I would like it. For example, the image handling in Serendipity looks nice for me. Something like that would be fine.
• A "printer friendly version" button on all nodes.
• An "email to a friend" button on all nodes
• A newsaggregator, which is not so picky about RSS-Feeds as it is at the moment.
• More configuration options about the RSS-feeds of a side.
• Trackbacks integrated to a node, not as comment, but in a separate field "Trackbacks" or something like that.
• A little bit more elaborate Atom-feed.
• This nifty images other software uses e.g. when creating a new account (you know, there is an image of a number, you must type it in to prove that you are a human being) would be nice, too, to get rid of bots.
• Filtering options in the statistics and log module, not only "Order by date" and so on.

Well, that's all folks.

Edit: A way to delete your comments maybe... heh

I've got another suggestion:

it would be nice, to log the FQDN of hosts in the statistics module instead of the IP number. Of course, this option should be able to be turned off in the module.