August 2006 - Development - lists.drupal.org

Re: [development] Wiki module
by Sumit Datta 24 Aug '06

24 Aug '06

Hello people, yes i will look into the available wiki modules. i have looked into liquid wiki. flickr is also interesting to me but i want to start off with wiki, since that is also the project that was on my applications list for Drupal for SoC applications. but i didnt apply for that. So now i can do it. I will install Dokuwiki and Mediawiki and do a study myself and submit a documentation and plan since i dont think such a plan exits. I intend to make the plan available before Brussels. And for Brussels this is what i found : http://drupalcon.org/node/24 So i think we will need a plan anyways, unless someone has already made one. Once i am done with plan of wiki module i will need to wait for Brussels to wait so that I know what all discussions went in there .... for that time being i will look into Flickr : just study it, nothing much serious. -- Thanks =Code is Poetry= Sumit Datta

7 9

Bugfix hour
by Karoly Negyesi 24 Aug '06

24 Aug '06

Hi, Beginning with September 4, Monday I will spend one hour with bugfixing between 10pm-11pm CET every workday until release minus DrupalCon days. That's 1pm-2pm for SF-Vancouver folks and 4pm-5pm for Montreal-Boston-New York. You are more than welcome to join on #drupal and help in this marathon. Even if you never patched Drupal core before, you are welcome. You could learn it or review issue or even write documentation as several new hooks and APIs are either not or not adequately documented. If we make the effort, there surely will be a great beta by DrupalCon and an awesome release mid-October. So, are you in? Regards NK Ps. I am announcing early so that you can schedule well before. If you work at a Drupal shop, you surely can convince your boss to donate one hour into core bugfixing. It's a wise investment...

2 1

node types should not be changeable, operations need hooks
by Peter Wolanin 24 Aug '06

24 Aug '06

While I really appreciate the hard work that went into moving user-defined node types into core, I think there is a problem that needs to be addressed: the ability of users to change the machine-readable name of the node type. First- a question. What is the use case for this? If I don't like the name of a node type (e.g. 'story'), I can just create an alternative. Trying to account for the possibility that the name of the type has changed (to me) makes the code look rather more convoluted than necessary and seems to introduce the potential for more bugs. Allowing users to change the node type will potentially create problems- for example with organic groups, where the names of "group" types are saved in a variable and there is no hook to let the module know they have been changed. Also, the current code fails to update user permissions (which are construced from the node type), if the name of the type is changed. So, I propose that this be removed and alslo that a hook be created to allow modules to act when a node type is deleted. issue posting: http://drupal.org/node/77990

6 9

RE: [development] Wiki module
by Metzler, David 23 Aug '06

23 Aug '06

Yep, that's my recipe too,except for icw, which might seem like preference. The book module provides the important "log" function that contains the meta discussion associated with updating content. I might argue that the "log" could ideally be configurable on a per content type basis, so you could do it for a page, story, or something else. You could really get wiki-like if you considered a "multi-node" display module that showed all the node content associated with a particular book page "parent", with edit links for each of them on the pages. Dave -----Original Message----- From: development-bounces(a)drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Bèr Kessels Sent: Wednesday, August 23, 2006 12:18 PM To: development(a)drupal.org Subject: Re: [development] Wiki module Op woensdag 23 augustus 2006 19:24, schreef Neil Drumm: > I recently helped set up a wiki for one of our client sites. We used: > - CCK (4.7) > - TinyMCE > - freelinking > - input_format_restrictions - a formapi hack module that lets you > define the default and available input formats for each node type [1]. > I plan on making a patch for core for this, but haven't had time. The > first step, in case anyone wants it, is being able to set the default > and available input formats when calling the function which generates > that form widget. Here is my recipe: book module (It's great to be able to actually structure a wiki!) node_privacy_by_role (we needed three groups that could not edit or see eachothers content. If you need more OG configured for books will be a good option) freelinking markdown icw with a properly configured input format. (My client found markdown far more "natural" then HTML or WikiSyntax) inline module upload module (icw inline provides a simple way to include images) Bèr

1 0

register the install profile in system table?
by Nedjo Rogers 23 Aug '06

23 Aug '06

We have the ability to include _install functions in install profiles. What about updates? We're currently registering the install profile through variable_set('install_profile'). Should we instead be setting it as a row in the system table? That way we could track its schema version like we do for modules and so invoke e.g. default_update_0() when update.php is run.

6 7

Re: Wiki module
by Sumit Datta 23 Aug '06

23 Aug '06

I installed WikiMedia and the usual things that came up are: *(1) Nice installer : Option to choose License of the content ( includes the License Chooser from http://creativecommons.org/license/) *(2) Caching options and integration with Turck MMCache, APC, eAccelerator, or Memcached *(3) Email message to other users : that we already have in Drupal *(4) Most config options are as usual common to any CMS, so it isnt needed to redo them The rest is just the wiki that we see almost everyday :) with usual features as history (versioning), talks on a page (this is another *node* which discusses the content of a wiki page) : this is called discussions too and ofcourse the ability to edit :P I think thats all there is to it. The wiki module has to be *VERY* clean UI : my suggestion. Tonight I will install and start tweaking with the existing wiki modules :) -- Thanks =Code is Poetry= Sumit Datta

2 1

Wiki module
by Sumit Datta 23 Aug '06

23 Aug '06

Hello folks, Google SoC 2006 is over. Now i am thinking of what more i can do : my main intention is to do somthing that can be used widely by the general users. Wiki module stands out in this respect. Also there is need for token-based authentication and Flickr API, but it seems to me that wiki module has more general need. Check out the links to the initial proposed projects for this SoC and also the ones that were chosen : http://drupal.org/node/59958 => Proposed projects http://drupal.org/node/65244 => 2006 Summer of Code Projects (14) For the wiki module: is anyone actively working on it? or are there any plans for it? chx told me that there could be some work on that module in the Brussels meet. -- Thanks =Code is Poetry= Sumit Datta brainless

4 4

Fixing themes and regions
by Nedjo Rogers 23 Aug '06

23 Aug '06

The region handling we introduced for 4.7 (and that I mostly wrote) is a step forward but produced confusion and instability in multi-theme sites. It's cumbersome to have to configure things like enabled status separately for each theme. As a 4.7 workaround I wrote a helper module, http://drupal.org/project/issues/blockregion. I know that there's work ongoing to improve theme handling of regions. But I'm behind on the status of this work. Is any of it for 4.8/5.0? If not, I'd like to consider the following approach: 1. Drop the ability for each theme to define more than the region of a block. 2. Pull the theme-block configuration into a separate table, e.g., block_theme, with fields module, delta, theme, region 3. Limit the UI configuration to region only for non-default themes. Is this needed/a good idea?

13 22

PHP input format -> syntax checking
by Tadej Baša 22 Aug '06

22 Aug '06

Hi, as you know, there is no way to recover from syntax errors in PHP code a user submits (either as nodes or for example in custom block visibility settings). I'm trying to figure out, if it would be possible to send the code to drupal_eval with javascript and prevent form submission if an error is returned. What do you think? -Tadej

6 10

Looking for Drupal Service Provider
by Partha Sarker 22 Aug '06

22 Aug '06

Hey all, We're looking for established organization/company that can work extensively on Drupal solutions in multiple languages (English, French, Spanish, Portuguese and/or South Asian languages etc.) and can develop Drupal based websites for local partners in any or many of these languages. Interested organizations/company please contact us at my email address with full details of your work and the organization. Best wishes, Partha Sarker

1 0