Reviewers

Guess what the File API functions do!

drewish — Thu, 24 Jul 2008 18:40:23 +0000

As part of the Media/Files Code Sprint we're trying to re-evaluate the mess of badly named functions in file.inc. When we were discussing it on IRC, clouseau pointed out that it's been a popular drinking game at DrupalCon for a few years.

Take a look at each item in the list and make a guess about what you think each function does based solely on the name--to make this a fair fight I'm even giving you the parameter names--then look at the documentation and see how you did.

Please leave comments telling us which were the easiest to guess and which functions totally puzzled you. This is a big list so feel free to comment even if you don't make it all the way through.

What's that? Okay you got me... It's true, I stacked the deck so all the worst offenders made their way to the top of the list. So if you got them all right and you're name isn't chx then I'll buy you a cheap beer at DrupalConSzeged.

Reviewers

First patch for FCKeditor support hit Wysiwyg's queue

sun — Tue, 15 Jul 2008 04:06:44 +0000

I have spent the last hours to get a first draft of FCKeditor support in Wysiwyg Editor module.
http://drupal.org/node/282717

It's still very rough and dirty, but it outlines what can be done and what needs to be done for multiple editor support in Drupal via one API module.

Now I badly need some feedback from folks that are interested in centralized Wysiwyg editor support, who know jQuery + JavaScript, and who might have ideas and suggestions on how to solve the outlined design challenges. Of course, all editor module maintainers are implicitly more than welcome.

Wysiwyg

sun's vision for handling embedded/inline content and Wysiwyg in Drupal

sun — Wed, 06 Feb 2008 20:59:46 +0000

As some of you know, I've recently taken over maintenance of Inline and Image Assist, and initiated the Wysiwyg project. That was not only caused by personal interest, but also to take the necessary steps to realize the long awaited Inline API. You might ask yourself, what those three modules have in common or to do with each other at all: They deal with user input, allow to embed complex contents into a content, and provide an interactive GUI for that. If you already had the chance to work with them, you already know that there is a rather hidden, non-obvious hard-dependency between them.

Although I'd really like to discuss both topics (Inline and Wysiwyg support) separately, the gained experience on these topics enforces us to discuss them concurrently. The following mockup hopefully explains why: (see attachment to view in full size)

This draft already incorporates Gabor's battle plan for Wysiwyg support in Drupal.

1. Inline API macro management

configurable per input format
automatically forces/ensures that required HTML tags for macro rendering are in the set of allowed HTML tags.

2. Inline API macro processing

available/required arguments supplied through hook_inline()
support for default values and multiple values
parameter validation
CCK support
stores references of inlined contents in the database to track where else a content (f.e. an image) is in use
very easy to implement for any contrib module
centralizes required code for macro processing into one module
goal: standardized way for macro processing in Drupal

3. Inline API macro rendering

allows to display any contents inline
cached output via Drupal's filter system
provides previews for Wysiwyg editors

4. Inline/Wysiwyg API plugin framework

exposes an Inline API plugin widget to textarea buttons and Wysiwyg editor buttons
invokes a widget in a popup, modal dialog (you name it...)
returns user supplied data from the widget as a macro into the content (textarea/editor)
allows to edit existent tags in contents (tags shouldn't be written manually)

5. Inline API widget

each hook_inline() implementation automatically provides a default/basic widget
supports extended widgets (f.e. Image Assist)
returns user supplied data (macro parameters) to the framework

6. Inline API plugin button

controlled by Inline API macro management
displayed below a textarea
only displayed if no Wysiwyg editor is enabled for a field

7. Inline API instant plugin button

inserts an Inline tag based on an already displayed widget (f.e. node attachments)

8. Wysiwyg API (editor) controller

configurable per input format (in D5/6 also per content-type, page url, and field name).
automatically forces/ensures that required HTML tags for all editor plugins are in the set of allowed HTML tags.
allows editor and editor plugin configuration per editor
may allow to assign an editor or editor profiles to user roles
supports loading of different editors on the same page

9. Wysiwyg API plugin button

controlled by Inline API macro management
displayed in an editor's toolbar
invokes a widget via the Inline/Wysiwyg API plugin framework

10. Wysiwyg API editor plugin hook

allows to add external editor plugins via hook_wysiwyg_plugin() (f.e. Link to node)

As a result of having both APIs working, a module like Image Assist would not have to deal with macro processing at all. Image Assist would only provide a extended widget (for selecting images), some rendering-related settings, and a button for Inline/Wysiwyg API. The framework takes care of user access, user input validation, generating and parsing of macros, aso.
As an (almost working) example, the former Inline v1 module (which allowed to embed uploaded attachments into a content) has been ported to implement hook_inline(). Many feature requests of Inline's issue queue are actually resolved due to that.

While Inline API is already under heavy development and plenty of above features are already implemented, Wysiwyg API only gained interested developers so far. From my personal experience, I can understand that not many Drupal developers have studied and dealt with the code and issue queues of available macro-based, Wysiwyg editor and editor plugin modules for Drupal - which is badly required to bring both APIs into shape. However, if you would like to contribute to these efforts, please let me know.

Wysiwyg

Sessions on Community: Code Review Wanted For Drupalcon 2008

mpare — Sat, 19 Jan 2008 00:57:59 +0000

My name is Matthew Pare and I'm a Co-Chair for the "Community and Core" track for Drupalcon Boston 2008. Over the last couple of weeks we have been planning and brainstorming to make Drupalcon Boston 2008 the best Drupalcon to date! One of our recommended track session topics is "Code Review" and since your viewing this post on the Reviewers group I thought you would be excellent candidates for submitting sessions on the topic.

How To Submit Your Session

We have several recommended topics for Community and Core sessions but now its your turn to submit your session.

Visit boston2008.drupalcon.org to learn more about Drupalcon Boston 2008, register to attend, view already submitted sessions, and even submit your own session.

Save the Date

Drupalcon Boston 2008 takes place from March 3, 2008 to March 6, 2008 in Boston Convention and Expo Center. In addition, there will also be a Drupal Code Sprint on March 7.

Useful Links

Please submit your session proposals as soon as possible and I hope to see you all in Boston real soon.

Cheers,

-mpare

DON'T MISS EARTH'S LARGEST GATHERING OF DRUPAL PROFESSIONALS!
Drupalcon Boston 2008 - March 3-6, 2008
Learn more at http://boston2008.drupalcon.org

Reviewers

Core / Contrib Issues That Require a Postgres Review

greggles — Wed, 07 Nov 2007 13:08:02 +0000

If you know of an issue that is being postponed while waiting for a Postgres review or that adds PostgreSQL compliance to a module and therefore needs testing on PostgreSQL - add it to the top list with a brief description and an estimate of the time to review. Once reviewed, move the issues to the bottom "reviewed" list, perhaps with your name attached.

Need Reviews

http://drupal.org/node/225450 - New database layer
http://drupal.org/node/285074 - Simpletest broken on postgres
http://drupal.org/node/107051 - Same user listed multiple times in who's online block
http://drupal.org/node/223820 - Book module tests for postgres error
http://drupal.org/node/181689 - Modify db_distinct_field() so it doesn't fail with count() queries. 15 minutes. needs a review on the regex and perhaps an install to verify the fix. install OG, enable access control for OG, then go to path: /q=og. should be error-free with the patch. (mmilano)
http://drupal.org/node/189810 - Recipe Modules fails to insert ingredients.
http://drupal.org/node/212264 - SQL Query failed on PostgreSQL 7.4 (syntax errors on admin pages with a fresh install).
http://drupal.org/node/128846 - Rewritten PostgreSQL queries fail / Nodes are sorted in the wrong order on pgsql when using a node access module.
http://drupal.org/node/229038 - "Query failed" error in Chart API.
http://drupal.org/node/222389 - Add PostgreSQL support to "Job queue" module.
[Comment notify query for people to send mails to missing column aliases and uses = '' instead of is null in where] (http://drupal.org/node/308585)
Add your issue here

Reviewed

Critical Core Comment Index - To test: install drupal5 with comment module, upgrade to Drupal6.
http://drupal.org/node/247526 - PostgreSQL support in FeedAPI update functions.
Improve bulk update speed using a cast - Especially needs postgres testers - reviewed by aufumy.

Committed without thorough review

http://drupal.org/node/242048 - Replace 'Blue Smurf' in search results message - and it apparently fails on postgresql: http://drupal.org/node/264836
http://drupal.org/node/190128 - _block_rehash fails on pgsql.
http://drupal.org/node/146466 - Search improvements.
http://drupal.org/node/189837 - Remove temporary table from comment.install | Drupal6 Core | 5 minutes (setup new installation of Core, make sure it doesn't blow up.
Pathauto new install fails on Postgresql - Code needs review. Just have a clean drupal5 installation on postgres, install Pathauto for the first time (after patching pathauto). Make sure the variable table's column width gets resized.
http://drupal.org/node/232564 - Comment notify refactored data storage and postgresql compliance

Reviewers

State of the issue queue

catch — Mon, 29 Oct 2007 10:55:16 +0000

The past two-three weeks I've spent a lot of time in the Drupal 6 issue queue. This involved a mixture of reviewing patches I really wanted to see get into Drupal 6, writing or re-rolling some small patches for small bugs and typos, and trying to clear the issue queue as much as I could down to a manageable size. I commented on something like 160 issues in seven days, and read through many more.

Looking at so many issues in a small space of time gave me a pretty good overview of the situation in the patch queue as a whole, and an IRC conversation with webchick, senpai and chx prompted me to write this up.

Although I didn't keep notes as I went along, these are my rough impressions of how things are in general. It's hopefully a bit better than this now of course.

The vast majority of patches in the review queue needed work, of these, most needed a re-roll because they weren't reviewed for months after being posted. Probably 5-10% of patches are duplicates of other patches needing review or work, and another 5% have already been fixed somewhere along the line.

There are several factors contributing to this, many feeding of each other.

More people are writing patches than reviewing them.
The issue queue is so big that it's hard to know if you're creating a duplicate issue without extensive searching (especially bug and performance fixes).
This results in duplication of issues and patches, often by people who may be one of a small number who could adequately review each other's patches.

Berating people to do more reviews won't work most of the time, so here's a few suggestions as to how this could be dealt with:

Developers (and regular reviewers) should be encouraged to write up 'how to review this patch" instructions especially for simple bug fixes and functionality reviews. There are instructions on how to report bugs in the issue form, but not how to present patches. Chx's e-mail to the development list meant that the temporary tables in search module patch got a review where it otherwise wouldn't have. Wim Leer's encouragement on the drupal_lookup_path whitelist issue got me properly interested in working on the issue queue seriously.
"Duplicate" and "won't fix" issues shouldn't be hidden from "My issues" when marked as duplicate - reviewers often link to the active issue when marking as duplicate, but between my issues and the other contributor links, you'll not find them again easily. Ideally they should be treated the same as fixed - left in 'my issues', then eventually marked closed via a cron job to keep things tidy later on. Some of these issues have dozens of posts on, and decent code, so it's worth having them stick around for a few extra days.
When looking at the issue queues itself, there's no way to know what's required in a review usually - is it code/code style, functionality, removing notices, ui, benchmarking, concept, architecture? Rather than more fixed categories, webchick suggested a free-tagging vocabulary. This would be useful for say marking patches for particular types of review, and when going to needs work, things like "re-roll" or "code style" or "doxygen". This would require the issue followup form to allow for setting the taxonomy terms though, but I reckon it could make quite a big difference and break to main queue into more manageable chunks.

Will open feature requests against drupal.org for those last two now.

I also think the fact that core modules (forum/taxonomy) etc. don't have their own dedicated issue queues (or branches for testing) as available to modules in contrib is negatively impacting the attention they get, but have already said the same here so won't repeat those arguments.

Reviewers

Active URL alias, and a revamped alias editing interface!

Gurpartap Singh — Sun, 08 Jul 2007 10:08:29 +0000

http://drupal.org/node/147143 demands your review. Code freeze has happened, but i'm still tempted to get this in, and hopefully it will. The patch is nothing that's stuck anywhere. That is, we should be ready for the RTBC state, as soon as there are a few more detailed reviews. Even usability reviews are welcomed!

Details about changes

Active/Preferred(Redirect to) alias per system path. So that all your aliases can redirect to the preferred one.
Search Engine Optimization! Google hates multiple urls with same content, this one of course is a ++ to SEO in Drupal.
A whole new intuitive path alias editing interface. Easy to grasp at first glance!
Total multi-language support for aliases. Language tabs appears, whenever you are editing an alias. A screen shot says it all: http://drupal.org/files/issues/URL aliases | Drupal_1181082809921.png
Fixes several glitches in path module/system.

Screen shot

Search Engine Optimization

Help review the 'Custom content types as forum topics' patch

Gurpartap Singh — Thu, 07 Jun 2007 07:20:20 +0000

The issue is at: http://drupal.org/node/20295

It's the most awaited one after flat forums(coming soon!), and posting this one so that we can move on to flat forum one asap! Now, for this one, imagine you want polls to appear in your forums, this patch gets any content type in there, and likewise the possibilities to push any content into forums by choosing related category. Hopefully this much makes enough sense what the patch does. Will also post a port for Drupal 5.x, as requested by Michelle.

Issue link again: http://drupal.org/node/20295

Reviewers

Help Drupal 6 rock in the multilanguage world!

Gábor Hojtsy — Tue, 15 May 2007 23:36:27 +0000

For Drupal 6 to be able to come out with some fundamental multilanguage support changes, reviews of some modifications and improvements are needed. There is not much time left until the code freeze, but we have a list of important issues and some possibly nice additions for you to look at. Lot of the groundwork material we developed is already in Drupal 6, which makes it possible to provide some cool user facing functionality. Now it is a good time to review the suggested changes, propose corrections and help Drupal 6 to rock in the multilanguage world.

What's already in Drupal 6? A new language subsystem which supports multiple text groups to store translations in (additionaly to the built in interface translation text group available before). There is built in support for language dependent paths and domains, right-to-left written text, with some of the themes already capable of displaying RTL pages out of the box (more to come). Interface translations are automatically imported from the file system when you install Drupal or you enable modules and themes. Posts on the site can have language associated with them, and there is a simple content translation module built into Drupal.

What is left to do? Well, the following:

Translating site settings
http://drupal.org/node/155381 - The absolute minimum to support site settings translations with a contributed module

Translating content types, user profile fields, etc.
http://drupal.org/node/155047 - Minimal object translation wrapper for content type, profile, aggregator, etc. translation

Themes still missing right-to-left display support
http://drupal.org/node/148084 - Pushbutton RTL styles
... - Garland and Minnelli RTL styles

More visible language support
http://drupal.org/node/154151 - Language-aware search

Usability improvements
http://drupal.org/node/52990 - Redoing the locale module translation web interface (see http://groups.drupal.org/node/3916)
... - Define and implement Drupal 6 translation packaging format, redesign interface translation workflow (this is done as part of Google SoC 2007)

Would be nice for multilanguage features, but probably not going to happen in Drupal 6
http://drupal.org/node/147041 or http://drupal.org/node/146033 - Two different approaches for built-in site settings translation
http://drupal.org/node/141461 - Translating any objects in Drupal (it has a good UI, but the performance is not acceptable yet)
http://drupal.org/node/141419 - Rework profile categories (has many advantages, for one being able to translate categories)
http://drupal.org/node/145164#comment-250759 - Refactor variable defaults
... - Eliminate t() from $link parameter of watchdog() calls

Translations

Performance review of object translation required

Gábor Hojtsy — Tue, 08 May 2007 11:25:16 +0000

We have posted a patch to support object translation of certain Drupal objects (content types, user profile fields and categories, site settings, and so on) to multiple human languages. While we have clear concepts and very good ideas for the user interface (which we though before that would not be easy), performance-wise we are at crossroads. We would welcome beginner as well as expert reviewers to come and share their performance ideas about Drupal object translation, so Drupal 6 can include a mature translation infrastructure, advancing ahead of the competition. ;) We need your input!

"Introduce dynamic object translation API (optimize this!)" http://drupal.org/node/141461

Translations

Patch Spotlight!

add1sun — Mon, 02 Apr 2007 10:56:48 +0000

Check out the current Patch Spotlight here

This is a great project for everyone to get involved in - you will be a part of the team working on core drupal, you'll learn about the goodies coming in the next version of drupal and gain instant karma - without needing to know any code! We are highlighting specific core patches that need to be tested before they can be accepted into core. This is a crucial step for actually moving the development of Drupal forward since much code has been written but it isn't going anywhere if it hasn't been tested.

There are a number of links to resources available on the Patch Spotlight page. Feel free to ask questions either in the Drupal Dojo or Reviewers group pages or in the #drupal-dojo IRC channel.

Reviewers

Proposal for restructuring patch docs

dww — Mon, 02 Apr 2007 06:01:24 +0000

add1sun started this at http://drupal.org/node/109114 with an excellent proposal for organizing the patch docs in the d.o handbooks (see below). now that the patch spotlight is underway, i'd like to propose a more thorough restructuring of the patch-related docs, building on what add1sun laid out. i know we normally don't use "top-level" path aliases, and prefer to prefix with "/handbook", but in this case http://drupal.org/patch is already pointing to a node buried deep in the patch-related docs. so, we should take advantage of that, and build a path (and book) structure on top of that which makes sense. in some cases (e.g. http://drupal.org/patch/review) we're already doing that. let's finish the job.

add1sun's original proposal

Background: basic concept Diff & Patch
Applying and Reviewing Patches

HOWTO: Apply patches

Common problems
Apply Patches on MacOS X
Apply patches in Windows

HOWTO: Set up test env to review
Tips for reviewing patches

HOWTO: Submit patches

HOWTO: Create Patches

Create patches in MacOS X
Create patches on Windows

Extra changes on top of add1sun's proposal

http://drupal.org/node/325
- current:
  - path: /patch
  - handbook: deeply nested under: Developing for Drupal » Contributing to Development » Patches
  - title: HOWTO: Submit patches for Drupal
- proposed:
  - path: /patch
  + title: Patches
  + handbook: moves up to the root of "Developing for Drupal"
  this would become the root, and we should lift a lot of content and all the children pages from #22568...
http://drupal.org/node/22568
- current:
  - path: [none]
  - title: Patches
  - handbook: Developing for Drupal » Contributing to Development
- proposed:
  - path: /patch/submit
  + title: Submitting patches
  + handbook: Developing for Drupal » Patches
  - would be the root of submit-related child pages, an would take content from #325, plus whatever other re-org, re-shuffling we want.
http://drupal.org/node/323
- current:
  - path: /diffandpatch
  - handbook: deeply nested under: Developing for Drupal » Contributing to Development » Patches
  - title: HOWTO: Create patches
- proposed:
  - path: /patch/create
  + title: Creating patches
  + handbook: Developing for Drupal » Patches
  + add a php page that does a redirect from /diffandpatch to /patch/create (since i guess 2 paths for the same page is bad for search ranking).
Add the "Patch spotlight" page

full proposal

http://drupal.org/patch (http://drupal.org/node/325)
"Patches"

http://drupal.org/patch/background (http://drupal.org/node/70745)
"Background: the basic concept of Diff and Patch"
http://drupal.org/patch/apply (http://drupal.org/node/60108)
"Applying patches"
- Common problems
- Apply Patches on MacOS X
- Apply patches in Windows
http://drupal.org/patch/review (http://drupal.org/node/772)
"Reviewing patches"
- HOWTO: Set up test env to review
- Other resources for reviewing
http://drupal.org/patch/create (http://drupal.org/node/323)
"Creating patches"
- Create patches in MacOS X
- Create patches on Windows
http://drupal.org/patch/submit (http://drupal.org/node/22568)
"Submitting patches"
http://drupal.org/patch/spotlight (http://drupal.org/node/132970)
"Patch spotlight"
[Maybe this should be moved up right after "Reviewing"]

Reviewers

New Video - Applying Patches to Drupal Core

add1sun — Sat, 31 Mar 2007 16:23:03 +0000

Hey folks, I've got another video out, Applying Patches to Drupal Core - there is .mp4 and .mov and a torrent for the .mp4. This one is just as quick and dirty as the last one - it is 12 minutes. It shows you how to use the command line to apply, test and reverse patches for Drupal core. This is a great way to be part of core development even if you know nothing about code. The developers are writing the patches but they need many eyes to test them and see if they really work in a wide variety of use cases. Improving Drupal code involves both steps - creating and testing. So basically all you need to do to help is apply a patch and then use your site to see if stuff works. We are also asking devs to add specific items they would like tried out in their issues so it's easy for you to go through the motions they need.

This is seriously a very important job to help move Drupal 6 forward. There are literally hundreds of core patches that are sitting around that need to be tested before they can even be considered to get committed. If you want to help out, the video is a great start and the Patches section of the handbook has tons of info, but if you still have questions or run into problems make sure you search the d.o forums first to see if others have already answered your question. If that fails to give you help, feel free to ask for assistance on IRC in the #drupal-dojo channel or post to the Reviewers group.

Also, if anyone feels inspired to create a video on applying patches using a GUI (like TortoiseCVS) - please don't hesitate! My videos are rough around the edges so don't feel like it has to be perfect, something is better than nothing. Ask for help on how to create the video and we're more than willing to help.

Drupal Dojo

A few issues needing review

ChrisKennedy — Sun, 04 Mar 2007 18:22:54 +0000

Hey guys,

I could really use a few reviews on some issues that are lagging. I have seven issues set to CNR at http://drupal.org/project/issues?states=8&assigned=chriskennedy right now.

In particular I'm interested to hear if there are any suggestions for these two UI-related patches:
1. Custom date-time formats
2. Links to jump to previous/next new comment

Thanks,
Chris

Reviewers

Hashing in pgsql

forngren@drupal.org — Sun, 28 Jan 2007 14:54:30 +0000

Hi,

Could someone please look at http://drupal.org/node/29706 and see if it's pgsql compliant? How do the CONCAT, MD5 and SUBSTRING functions behave on PostgreSQL?

Thanks,
Johan Forngren

Reviewers

Attention reviewers!

forngren@drupal.org — Fri, 05 Jan 2007 15:52:01 +0000

Drupal 5.x is so close that we can almost smell it!

Here is a list with all patches against Drupal core marked "code needs review" and tagged with any 5.x version (beta, rc, dev). Currently it is three sides long, which IMO is far to long. Can we try to bring it down to two pages? That is a realistic goal and will increase the stability of 5.x and release some pressure of developers. Thank you.

http://drupal.org/project/issues?projects=3060&versions=96923,103420,100...

Reviewers

Two important issues to trade reviews (IMO)

robroy@drupal.org — Thu, 28 Dec 2006 18:36:45 +0000

http://drupal.org/node/92630 - THIS one is the biggest usability issue I've come across and we have a great simple fix, just needs some momentum behind it and needs it fast! It's got Steven's stamp of approval but needs some more voices.

http://drupal.org/node/104763 - Define page and story in default.profile. This patch also changes page's workflow to not promote to front page and have comments disabled.

Reviewers

Real simple patch for RC1

drewish — Thu, 28 Dec 2006 00:02:47 +0000

Filters aren't being applied to RSS feeds: http://drupal.org/node/103371

Reviewers

Trading issues to review

ChrisKennedy — Thu, 07 Dec 2006 06:56:12 +0000

I have participated or commented on a few issues that need a review, most of which are very minor changes. I'll trade reviews one-for-one with anyone who's interested. Here is the list of issues.

Here are my top ones:

Reviewers

Request for the review the ChipIn module

robroy@drupal.org — Mon, 28 Aug 2006 22:24:12 +0000

Not sure of the correct/preferred layout of a review request, so I'll just cross post from the dev mailing list.

I've just committed a beta version of the ChipIn (see http://www.chipin.com) module to contrib/modules/chipin (http://drupal.org/project/chipin). I was looking for some peer review of the module. I'll gladly return the favor, it's just nice to have another set of eyes look things over for usability, security, etc. So if you have a module/patch you'd like me to go over in return, let me know. I think it's pretty cool to have the donation thermometer to see how much we still need for each fundraising drive and ChipIn.com is pretty well done.

Thanks!

Rob

Reviewers