Improvements to core

Drupal 7 core forum module - plan of attack

catch — Fri, 01 Feb 2008 19:22:49 +0000

Drupal's core forum module is much maligned. Some of this is unjustified - people expecting it to replace standalone solutions by itself and ignoring the nature of Drupal's modular framework. However, it also has some limitations which are a result of its age and require many workarounds for large community sites.

Many of the forum module's limitations are down to its dependency on the taxonomy module (making it hard to integrate with organic groups etc.) and on comment.module, which is itself in need of a rewrite.

So we're proposing a ground up rewrite of forum.module using nodes.

Nodes? Surely that would require the pipe dream of comments as nodes? We hear you say.

Well, no it wouldn't. In the new forum module, posts are nodes, and some posts are also forum topics. Forum topics become simply the first post in a thread, and are nothing special by themselves.

We think even forums themselves might become nodes, with the hierarchical structure handled by the menu system - allowing for multiple separate forums, forums within organic groups and the rest.

But if all posts are nodes, won't that be a performance hit?

Well, maybe not. By decoupling forums from the comment system, we no longer have to support comment threading and the rest. Also, most forums have around 10-30 replies per page rather than the 50-100 comments on many blogging sites. The D7 forum module will also depend on views - which will allow us to get all posts in a couple of queries and bypass node_load.

This will make common features in standalone forum solutions readily available: the ability to browse all recent posts by a user (rather than posts they've commented on, not very useful when the thread is 4,000 posts long), splitting and joining topics, rss feeds, subscriptions, uploads, theming - everything can take advantage of the node system without requiring that Joe's single person blog site get the overhead of comments as nodes.

One of the main issues with moving away completely from comments will be the upgrade path, for example some Drupal forums use threading (notably Drupal.org). However, threading on drupal.org has many issues, not least being unable to use #new links when threads get long enough to use a pager.

In terms of an upgrade path for threaded forum discussions, one possible solution would be to mirror the visual structure of threads as they are now, incrementing a reply ID sequentially based on their position, for example:

Current forum thread:
1
  2
    4
      6
    8
3
  5
7

After upgrade:
1
2
4
6
8
3
5
7

We will be attacking the implementation from a few different directions:

Michelle's advforum module is currently providing the glue code and theming that has been much demanded to lower the barrier to a full featured forum solution in Drupal. We'll be working hard on this for D6 as a precursor to more fundamental changes in D7.
data structure. At the moment, it's likely that forums will be nodes, posts will be nodes, and that some posts will also be forum topics. Identifying a topic may be as simply as forum.nid = forum.topic_id - this "everything is a post" model mirrors other forum solutions and gets us away from the comment paradigm.

We know others are interested in working on this, so it'd be great to co-ordinate efforts. Please subscribe to this group and/or get hold of one of us on IRC

For feature lists (some of which will be, or already are handled in contrib) see the advanced forum module wiki.

There's also plenty more background reading in the DruBB group.

For discussion on how to actually get this done, please see the planning wiki

catch, merlinofchaos, Michelle.

Improvements to core

Core taxonomy patches

catch — Tue, 11 Nov 2008 00:12:06 +0000

Taxonomy module is undergoing an overhaul at the moment. This is happening in multiple small to medium-sized patches which will be tracked here as far as possible, otherwise check the taxonomy issue queue

taxonomy_get_tree() should be indexed by tid
Load multiple nodes and terms at once
taxonomy.test is sad

Taxonomy

Database spotlight

Crell@drupal.org — Fri, 24 Oct 2008 06:10:51 +0000

If you're looking to help out with the database API, start here! Actually, first start with The Extensive Docs, and the full issue queue.

Small patches that just need to happen:

Tag-specific alter hooks. Just like FAPI, and with the registry probably faster than always using the main hook.

Patches blocking other work:

Refactor transactions to expose an API. We can't implement transactions in core until this goes in.
Dynamic subqueries in FROM. I still think this could simplify node_access.
Replace db_rewrite_sql() with hook_query_alter()

PostgreSQL-related patches:

It has been suggested to remove PostgreSQL support from Drupal 7 Core. If you don't want that to happen, help us in the surge for PostgreSQL:

And keep in mind other PostgreSQL-specific issues:

Empty BLOB fields fail. This is a bug in PDO that we need to work around. External reference from PHP.
Reserved word-safe schema operations
Optimize merge queries.

"Needs committer feedback":

"Extenders" for SELECT statements. This should allow pager and tablesort queries to be properly dynamic, but I'm not 100% on the API yet.

Core conversion patches:

Note: Please do not add patches here unless you are the DB Maintainer or branch maintainer. We do not want this page to turn into a duplicate of the issue queue, and it's long enough already.

Improvements to core

D7 file system wish list

drewish — Fri, 17 Oct 2008 17:22:51 +0000

Now that the hook_file patch has been committed I'm trying to keep the files in core movement moving. Some of these have issues on d.o and others are still in the brainstorming phase. Feel free to add your own ideas or add comments to discuss the ones already here.

UI/Admin

#322287 Add file.module to provide UI for managing files Add a module to provide a UI for managing files.
User photos in user.module should be managed files. This would let the D7 version of imagecache know that a user's profile picture has changed and flush the old thumbnail. I've done a little work on this and it's been a good exercise because it illustrates some problems with the reference counting blocking deletions and the question of overwriting managed files in #334303.

API Changes

#334303 Handling overwriting of managed files While trying to move the user.module's user picture into the managed file framework I came across an oversight in the Files API. When you use FILE_EXISTS_REPLACE to overwrite an existing, managed, file using file_copy(), file_move() or file_save_data() the target file's database record isn't affected. file_copy and file_save_data() are simple to fix, you just try to load the destination path. Moving is tricker because you start with two files and need to end with one so one has to be passed to file_delete().
#227232 Support PHP stream wrappers PHP allows users to implement their own stream wrappers. This makes it possible to access virtual or remote filesystems as if they were on the local disk using fopen(), unlink(), file_get_contents() etc. The files may be stored e.g. as real files on a central server, as virtual files in a database, on remote a storage service like Amazon S3.
#329311 hook_file_references() should have flag to return links to usages. Refactor hook_file_references() to take a parameter that directs modules to either return a boolean usage answer or an array of links where the file is used. Add a file_usage() function that calls hook_file_references() and returns the data. Currently the module is responsible for keying it's references with the module name which is a little annoying. If there's a function for checking usage then it can replicate some of the module_invoke_all code and key the results by module leaving the modules to just return their usage as either a number or array of links. This would be really helpful for the #322287 because then you'd be able to show a list of nodes where the file is in use.
Rework the file_validator_* functions to provide help messages. It'd be cool if, given no file but the parameters that will be used on the file, the validator functions would return a nicely formatted message suitable for telling the user what restrictions are placed on the file and any transformations that may occur.
Remove drupal_set_message() and form_set_error() calls from file.inc. It's really annoying that file_copy() reports errors via drupal_set_message(). Now that we're PHP5+ we've got exceptions that could be used to report errors back to the caller and the caller can either act on them or report them to the user.
file_scan_directory() should return objects that have the same properties as the $file object returned by file_load(). Right now the file path is $file->path instead of $file->filepath, base name is $file->basename instead of $file->filename. The main complication of this patch is that there are quite a few core functions that directly return the results of this function so the change cascades out.

{files} Schema Changes

#33482 add 'module' column to files table If only so you know who to blame for crap in the files table.
#329301 Add a unique key to the {files}.filepath column Having duplicate entries for a single file makes them much less useful. The problem will be figuring out how to let modules know that fids they'd referenced have changed. Perhaps we'd just set a variable with a mapping between new to old.
Store file paths relative to Drupal's files directory. Currently we store file paths from Drupal's root and the default files directory is sites/default/files meaning that if you upload files and try to move the files directory you'll have to manually update the filepaths in the {files} table.
Allow full stream references to be stored in the filepath. ex) drupal://path/to/file.txt, drupal-private://path/to/file.txt, youtube://sDly0jnXghY, s3://user:pass@mybucket/key/to/file.txt, ftp://user:pass@host/path/file.txt. depends on: http://drupal.org/node/227232

Developer Experience

Create a core fileupload form element modeled on Dave Cohen's UpAPI module that handles all the AHAH/AJAX so you get the progress bar for free and don't have to mess with adding in your own validation function to call file_save_upload().
Add a file_save_from_url() function that starts an asynchronous download to fetch a remote file and add it to the files table. Run some validators and then call a callback function so the caller can process it... or perhaps they'd just see the hook_file_insert() call and we'd put something into the $file object so they'd know it was theirs.
#331171 Give developers access to the mime_extension_mapping default value Module developers may want to alter the mime_extension_mapping and this would be much easier if it was available via its own function rather than buried in the code. A further feature request might be allowing it to be altered via drupal_alter().

Video

Next generation Wysiwyg API: Edit like a rock star!

sun — Thu, 09 Oct 2008 04:41:48 +0000

smk-ka and me worked on the next generation of Wysiwyg API today. Stunning results! Which are still compatible with D6 and D5.

Known issues of the past:

Client-side editors attach to textareas, which do not support input formats at all. As a result, either all your formattings are not rendered, or you are faced with editors in places where no editor was ever considered, destroying your configuration or PHP code.
When working with a client-side editor, you need to ensure that you have set the proper input format, so the entered markup is not removed from the output. Failing to do so means to edit a content again, just to change the input format.
Disabling a client-side editor on a textarea the editor attached to, leads to missing default behaviors of Drupal, such as the grippie to resize the textarea. A tiny editing window and ugly scrollbars instead.

The solution:

With the patch in Attach client-side editors to input format enabled textareas only, which is about to be committed:

Client-side editors are no longer dumb scripts.
Editors are associated with input formats, making it possible to associate "BBedit" editor with a "BBcode" input format. A lightweight TinyMCE profile with "Filtered HTML". A full blown FCKeditor with "Full HTML".
Not every input format needs an editor. PHP code for example. If such an input format is selected when the page loads, no editor is attached to the particular textarea.
Editors are able to be switched if the input format is changed.
Regular behaviors in Drupal core are restored when no editor is attached. Resizable textareas are back again.

Remaining todos:

Introduce a GUI to associate an editor or editors to input formats. Not sure whether more than one makes sense. If not, we can remove the whole access permission system from Wysiwyg API's profiles.
Refactor JavaScript settings, so we can store the configuration for different editors simultaneously and support different editors (input formats) on the same page.

Wysiwyg

Announcing Wysiwyg API - major milestone

sun — Tue, 07 Oct 2008 01:01:36 +0000

I took the time to rewrite the Wysiwyg (Editor) module into a generic API over the weekend. So the primary concerns about TinyMCE-specific code all over the module are eliminated now. Also, you might have noticed, that I have added an example integration for FCKeditor already - which of course is rather a proof of concept than a fully-fledged integration (and it works cleanly 8).

So Wysiwyg has become a real API finally.

Since Wysiwyg API contains only minor changes between 5.x, 6.x, and upcoming 7.x, I want to encourage all developers and maintainers of so called "editor integration modules" in contrib to write a similar migration function like the one that exists for users of the obsolete TinyMCE module in wysiwyg_editor.install.

Please bear in mind that with each active developer joining the project, and each new end-user of Wysiwyg API, the probability of having proper support for client-side editors in core for Drupal 7 increases. So instead of working on dead-end projects, join forces, please!

The next major steps are:

Allow to configure advanced editor settings
http://drupal.org/node/313497

Attach client-side editors to input format enabled textareas only
http://drupal.org/node/253600

...and I'm already working on a new plugin architecture, so modules like Image Assist can integrate into TinyMCE and FCKeditor (and others) concurrently, without having to implement editor-specific functions.

That said, another task for Wysiwyg API 1.x will definitely be to move and rename all functions into wysiwyg.module instead of wysiwyg_editor.module. I originally started with wysiwyg_editor, because I did not know whether support for "rich-text editors" would just be one component of a larger API, but just re-phrasing this into "support for client-side editors" along with an appropriate architecture turned out to be key.

EDIT:
A list of editor modules, which can be replaced by Wysiwyg API:

Wysiwyg

removing $op from hooks api

justinrandell — Sat, 27 Sep 2008 09:18:19 +0000

motivation comes from lots of places, good discussion on the dev list here.

i've started a patch to remove $op from hook_user (Code Needs Review).

any comments on whether this is likely to make D7?

Improvements to core

Quality Assurance-related core patches

webchick — Sat, 27 Sep 2008 04:34:18 +0000

These patches affect things like the coding standards compliance, testing framework, the tests themselves, and tools that enable QA people to nitpick.

Add "expected fail" functionality to SimpleTest
Re-work SimpleTest web interface (needs splitting up into smaller patches)

Fixed

~~Catch notices, warnings, errors and fatal errors from the tested side~~

Testing and Quality Assurance

Killer feature-enablers

webchick — Sat, 27 Sep 2008 00:53:16 +0000

These patches enable some of our "killer" Drupal 7 features. Great patches for a Drupal hero(ine) out there to review. This section is reserved for patches that enable Dries's the Drupal 7 hit list.

Input format widget (critical UX improvement for input formats)
Integrate Diff into core
Add token functionality to core

See also the dedicated page about status, progress, and summary of Wysiwyg support in Drupal core.

Fixed

~~Allow behaviors to detach from AHAH/AJAX contents (required for better Wysiwyg support)~~
~~Textarea with input format attached (enables WYSIWYG in core)~~
~~hook_file_X() (enables image/media handling in core)~~

Improvements to core

Languages & translation related

webchick — Sat, 27 Sep 2008 00:49:30 +0000

¿Hablas español? Parlez-vous français? You can help with these patches that are translation-related.

Improve translation string search and editing interface
locale_inc_callback() is a thing of the past
Re-split locale module (depends on the locale_inc_callback() patch)

Fixed

~~Fix broken localization for permission names (enables localization of composite permission names, lays ground for more (non-language related) permission improvements)~~
~~Introduce Daylight Saving Time for Drupal~~

Improvements to core

Improved DX (Developer Experience)

webchick — Sat, 27 Sep 2008 00:46:11 +0000

These patches clean up really annoying API things or otherwise make Drupal development more of a joy. If you spend lots of time staring at code, check out some of these patches.

Performance-related core patches

webchick — Sat, 27 Sep 2008 00:37:17 +0000

Patches that impact Drupal's performance. Have a need for speed and some mad benchmarking skills? Help out here!

Load multiple nodes at once
Load multiple items from cache
Adaptive path caching
Remove LOWER() queries in user module
Caching (per user) for authenticated users
temporary tables in taxonomy module queries - eliminate queries that write temp tables to disk with MYSQL
Support disabling anonymous sessions - makes it easier to use Drupal with HTTP accelerators like Varnish
Allow JS/CSS aggregation with private files - let users of private files get these performance improvements too
Separate Revisioning from Node module - improves performance for sites that don't rely on node revisioning

Fixed

~~Hook caching~~
~~Cache registry misses~~

Won't fixed

cut the fat out of _drupal_bootstrap_full

High performance

Documentation-related core patches

webchick — Sat, 27 Sep 2008 00:29:16 +0000

These patches affect Drupal's documentation, or affect Drupal's documentation team. Looking for reviews and help from people with this itch to scratch. Feel free to add your own!

Documentation Team

JavaScript improvements

webchick — Sat, 27 Sep 2008 00:26:26 +0000

These are core patches that provide improvements that are JavaScript-related. jQuery ninjas, we need you!

Theme system improvements

webchick — Sat, 27 Sep 2008 00:22:04 +0000

Here are theme system improvements or CSS/XHTML items in the queue that could use the eyes of designer/themer-types.

OMG WTF BBQ

webchick — Sat, 27 Sep 2008 00:16:16 +0000

This is a list of core issues that are seriously, seriously broken. Looking to become the next Drupal hero(ine)? Help fix these.

No ability to debug simpletests

Quick UX review please:

yoroy — Thu, 18 Sep 2008 11:02:39 +0000

Please review active core usability issues, specifically:

Make the content type admin screen prettier
Better theming of Input format fieldset
Make phpinfo()/MySQL info links more obvious
Integrate diff into core: minor questions around settings for "Preview changes" button.
Warn before losing changes (e.g.: blocks and menu admin pages)
Replace collapsible-fieldsets with Summaries
Rework the SimpleTest web user interface
Administration theme in core
Easier date-time format setting
Allow administrator to decide if blocks should be displayed for site_404 pages: Adds an option to the error reporting screen about whether to show blocks on 404 pages. Needs review for UI clutterage, and wording of option.
Put the tabs on the right.

All usability issues in the queue

(this is the page where catch and other masters of the issue queue post links to ux/ui related issues regarding Drupal core)

Don't worry! You are not expected to actually solve the issue. Sometimes it's giving feedback from a user-centered perspective or some advise on design, layout or styling.
Below are some more issues that need your input, but consider responding to the one mentioned above first.

thanks!

Usability

Comment module: the display order settings removed

marenz — Thu, 24 Jul 2008 20:35:27 +0000

Today I read the changelog of Drupal 7 and it says:

"Removed display order settings for comment module. Comment display
order can now be customised using the Views module."

As the forum for core development questions is also removed, I post my concern here in this group.

I think the display order of comments is a basic feature of comments for that I don't want to install an excessive module like Views. Is there any reason to remove this small but basic feature in core?

Marenz

Improvements to core

Taxonomy improvements for Drupal 7

catch — Tue, 22 Jul 2008 11:03:17 +0000

I think it's time taxonomy module got some more love in core. Drag and drop etc. was nice to get in D6, but there's much more we could do. Also I keep seeing various taxonomy administration helper modules cropping up - which is good, but there's no core patches cropping up alongside them, which is a shame, so I'm starting this in the hope of generating some discussion about things we could do this release cycle.

There's three obvious areas where Taxonomy could use some help.

Administration:

Merging terms.
Moving terms between vocabularies.
Mass operations (delete, edit).
Editing individual terms quickly
Administration of large vocabularies
Mass addition of terms (the quickest way to add them at the moment is free tagging at node/add)
Cleaning up old crappy terms and preventing creation of new ones.

There are modules which deal with some or all of these, but some of them have serious UI issues (i.e. taxonomy_switch) and it's often necessary to install 4-5 different modules on one site if you need people without db access to manage large numbers of terms.

User interface:

Apart from administration, the biggest problem IMO is mile long select lists:

http://drupal.org/project/hierarchical_select
http://szeged2008.drupalcon.org/program/sessions/usability-enhancements-...

API:
Atttaching taxonomy terms to stuff other than nodes (fields in core)
Maybe try to get term_parents reworked to use the menu system, and move multiple parents to contrib (if this is even possible).

I reckon the quick wins would be:

term_edit and hierarchical select into core for D7.

Maybe adding a 'vocabulary' field to the term edit screen.

For mass administration I'm sure loads could be done with Views 2 but I've not looked into the possibilities in any depth.

Taxonomy

Add context for check_markup()

sun — Sun, 08 Jun 2008 03:18:09 +0000

There's one big problem with the current development of Inline API: Filters do not know what "type of text" they are acting on. For example, the "old" Inline module allowed to embed images/files in a node's content, which are attached to the same node. Because filters don't know what they are doing, Inline needed to run via hook_nodeapi() in the past.

In Inline API, I coded around this limitation, but it's still ugly. So I went ahead and checked, how many times check_markup() is actually invoked in Drupal core. Here's the stunning result:

<?php
/modules/block/block.module(219):      $data['content'] = check_markup($block->body, $block->format, FALSE);
/modules/comment/comment.module(619):  $text .= '<h2>'. check_plain($comment->subject) .'</h2>'. check_markup($comment->comment, $comment->format, FALSE);
/modules/comment/comment.module(1524): $comment_values['subject'] = trim(truncate_utf8(decode_entities(strip_tags(check_markup($comment_values['comment'], $comment_values['format']))), 29, TRUE));
/modules/comment/comment.module(1575): $comment->comment = check_markup($comment->comment, $comment->format, FALSE);
/modules/node/node.module(1038):       $node->body = check_markup($node->body, $node->format, FALSE);
/modules/node/node.module(1041):       $node->teaser = check_markup($node->teaser, $node->format, FALSE);
/modules/profile/profile.module(261):  return check_markup($value);
/modules/user/user.module(2019):       $comment->signature = check_markup($comment->signature, $comment->format);
?>

A total of 8 instances. So, what we would need for intelligent filtering would be an optionally enhanced function signature:

<?php
function check_markup($text, $format = FILTER_FORMAT_DEFAULT, $check = TRUE, $type = NULL, $object = NULL) {
}
?>

...whereas $type and $object would for example be 'node' and a prepopulated $node object that is passed to all implementations of hook_filter().

This would finally allow us to filter contents with regard to their actual context. Thus, a very simple and silly use-case would be the previously mentioned Inline filter: By typing

[inline:1]

...the filter is able to look up if there are files attached to the current node (context), which one is the first allowed to embed, and transform the tag into a image or file download link.

Benefit for this silly filter alone: The output can be cached.

Wysiwyg

Generalizing node context

joachim — Tue, 27 May 2008 17:30:13 +0000

Been sitting on this idea for a while: curious to see what people think.
In a nutshell, the idea is to combine and generalize the various flags for a node that are available in node.tpl.php, and open them up to modules.

For example, instead of the $is_front, $page, $sticky, and $teaser booleans, you'd have an array with entries present if the flag is true. Something like this, for example:

  $context = array(
    'teaser' => array(),
    'sticky' => array(),
    'page' => array(),
    );

Core would take care of shoving those keys in; other modules would given a chance to add their own to a node.

That's the plan. Here's why I think it's cool:

Blogs
Has anyone else noticed that it's a bit weird to have the user picture repeated over and over again on the /blog/xx page, when we already know it's Joe Bloggs' blog? Wouldn't it be more logical to have it show a) on every post on the /blog page, which is a mixture of people, b) on the individual blog nodes, and c) if we're being really cool, just the once at the top of a personal blog roll?
The $page/$teaser distinction doesn't give us this level of subtlety.
With a context list, the blog module could shove in its own flag to the $context array, such as 'blog_user' or something, and then skip the $picture in that case.
To get the picture on the first one in the list, you could shove in a 'first'... and that would have a LOAD of cool applications with theming.
Views
There's a huge number of things this would be good for views.
I often find I do a load of view theming, when all I really want to do is say 'don't show the node links on teaser nodes in this view' (and I want a teaser list; really don't want to reinvent the wheel styling a list view).
If the views module dropped both a 'views_view' and a 'views_{viewname}' item into $context, a simple switch in the node template would do the job.
Headings
A simple input format to handle headings is something I'd really like to see. Something wiki-like, with "== heading ==" turning into an H2 would be great for a lot of purposes.
However, you're almost sure to get badly-nested HTML, because while in the standalone case ($page), H2 is probably the next heading level down from the node title, it's probably not in a teaser list. And when you get the views, the plot thickens.
I've not entirely considered the ramifications of this, as it would have to be done at the theme level, because different themes use different hierarchies of headings... but you'd definitely need some indication of node context.

Comments and ideas?
Ought this to be done to the flags in the $node object too? There's currently a redundancy between $node->sticky and the $sticky available to node.tpl.php, for example. Is that something that can do with tidying up while we're at it?

Improvements to core

More defaults in the default install profile

catch — Fri, 23 May 2008 10:42:20 +0000

I just opened up two issues:

Default tags vocabulary
*'Advanced' install profile

The idea is to get more dummy content into the default profile, whilst at the same time provide a stripped down profile for people who don't need it. The question is, what else could we put in the default profile if we're able to bloat it a little?

Enable more modules? Which ones?
Dummy content in page nodes and dummy primary links pointing to them?
Dummy article posted to the front page?
Dummy 'categories' vocabulary with a select list?

I'll admit to knowing very little about the install profile system, and it might get overhauled itself during D7. But it'd be good to get a list of things that might be helpful to have examples of when you first install Drupal, and see which of those we can squeeze in to the default profile without making it too annoying.

Usability

RFC: Installation profiles as modules

dmitrig01 — Sun, 18 May 2008 17:51:14 +0000

In Drupal 7, Installation profiles should become modules.

Most of the work done now will be done in hook_enable.

The benefits:

Profiles get to implement hooks
To build a profile, you don't need to learn a whole new API
Multiple profiles can be enabled at once. (Imagine a site for a project - you could enable the wiki profile, blog profile, and project profile)
Profiles can be disabled
Profiles can have updates
Profiles can be monitored w/ update.module

Profiles will have a special category in their .info file: Distributions.

Then, they will be shown during the installation process, and on a separate page, admin/build/distributions, and hidden from the system modules page.

(Assuming we'll re-name to distributions).

Improvements to core

Add Display Name field(s) to core in addition to Username

dahacouk — Tue, 29 Apr 2008 16:59:39 +0000

Add Display Name field(s) to core in addition to Username is a D7 feature request. This document assists advocators to bring clarity and structure to the proposal and formulate design requirements to pass to core developers. So, add to this page.

Please see How To Comment below. Comments are additive...

Overview:

There are many reasons for having Display Name functionality in core: security, ease of setup, consistancy for theme and module developers.

Name Fields:

These definitions are intended to describe these fields/names so that module and theme developers know where and how to use them in their themes and modules. It seems that a bit of standardisation of "names" terminology could help a lot in bringing "slick" to Drupal:

Display Name:
- Also Known As: Real Name
- Function: Attribution, Authorship
- Usage: Is intended to appear in web text and not in web links or URLs.
- Uniqueness: Default setting is not unique (as real names are not unique). Webmaster has option to set this field to unique.
- Constraints: Webmaster has options to set constraints for: length, numerics, alphas, case, capitalisation, punctuation.
- Clone: Webmaster has option to set this field to be a clone of the Username field - in which case the Display Name field would equal the Username field.
- Changeability: Webmaster has option to set whether the user can change this field or not after creation.
- Defaults: Initially, Display Name field would be set to equal the Username field so as to mimic D6 behaviour.
Username:
- Also Known As: Login Name
- Function: Authentication
- Usage: Is for login purposes only and never to appear on public parts of a drupal website. Only to appear in settings page for each user. Never used to refer to users in web text or web links.
- Uniqueness: Always unique. No webmaster options on uniqueness.
- Constraints: Webmaster has options to set constraints for: length, numerics, alphas, case, capitalisation, punctuation.
- Clone: Webmaster has option to set this field to be a clone of the Email Address field - in which case the Username field would equal the Email Address field. The Username cannot slave off Display Name or URL Name fields.
- Changeability: Webmaster has option to set whether the user can change this field or not after creation.
- Defaults: Initially, Username field would be set to be user generated so as to mimic D6 behaviour.

Backwards Compatibility:

The webmaster could set: Display Name and URL Name to be a clone of Username. This should be the default which will give us the current D6 behaviour as it stands (ie just one user name field), removing upgrade confusion, and meaning that unless a webmaster activates either option, they can't change it and wonder what went wrong, and why it doesn't work like D6 used to.

Discussion:

For discussion/questions/disagreements use the issue thread.

Use Cases:

In all cases the webmaster should set name policy as they wish.
Optional Display Name. A user could be known as 'George Marshall' on the site if this was set, or 'gm423' if it was not.
There is a compelling need for separate URL Name and Username. As there could be some situations where having them different could be advantageous. One scenario is where a webmaster decided to make the Username the user's email address - then the URL Name would not work as an email address. [macgirvin - Yes, but we would already have the necessary fields (username, email, and displayname). See my note on implementation below].

Implementation:

A possibly useful implementation could be with the named entities as pointers to arbitrary DB fields. URL Name in the case above (separate URL Name and Username) could be a pointer to the DB Username field, while the Username could be a pointer to the DB email field; allowing login by email. Some flexibility in what to point to could go a long way and open additional implementation posssibilities. If both URL Name and Username pointed to the DB username field, it would solve at least one implementation case. One could also easily implement a login by UID by pointing Username at the DB uid field or alternatively use Display Name from an already existing module.

How To Comment:

For questions/disagreements use the issue thread - so not this document.
Comments are additive. Add in your own ideas - so no deleting other peoples' ideas.
This document is written in the third person - so no "I" or "My".
Bring clarity and structure - alter terminology if it brings better understanding.
No need to sign comments - this document reads like an article.
Reference supporting material from the issue thread and elsewhere. Also, refer back to this document from the issue thread .

To Be Refactored:

catch what does this do that pathauto doesn't? We have user/uid for URLs which isn't going anywhere, and it would be easy to set up pathauto rules to alias this to an arbitrary value based on some other field from contrib.
- (destined) The difference I see between what pathauto does now and a seperate URL Name is that Pathauto has to get it's data from somewhere yes it can (can it?) be set to a contrib field, however one of the points made in the discussion in the issue queue was that many feel this kind of field should be in core and not relying on a contrib module to provide the field. I still imagine that using URL Name would come from pathauto, however this leads to the question of if we have a URL Name field in core, then why do we need to use a 3rd party module to do use it as intended. Maybe UID could be depreciated in favour of URL Name, as by nature URL Alias should be unique, or maybe the path system is made aware of URL Name and transparently handles requests for user/url_name as it does user/uid currently?

Everything below this line is archived for future use and not considered part of the issue

URL Name: - there seems to be quite a lot of opposition to this URL Name so if you are for or against it make sure you speak up on the issue thread and we'll get a consensus.
- Also Known As: Link Name, Screen Name, Nickname, URL Alias
- Function: URL
- Usage: Is intended to appear in link text and URLs and not in web text.
- Uniqueness: Always unique. No webmaster options on uniqueness.
- Constraints: Webmaster has options to set constraints for: length, numerics, alphas, case, capitalisation, punctuation.
- Clone: Webmaster has option to set this field to be a clone of the Username field - in which case the URL Name field would equal the Username field.
- Changeability: Webmaster has option to set whether the user can change this field or not after creation. Thinking in terms of permalink setups, where a webmaster might always want the content accessable via the same URL, even if the user changes their Display Name.
- Defaults: Initially, URL Name field would be set to equal the Username field so as to mimic D6 behaviour.

Trying to figure out why some links work and some don't. Seems that duplicate links don't get parsed correctly.

the issue thread
[[http://drupal.org/node/102679|the issue thread]]
the issue thread
the issue thread
the issue thread
[[http://drupal.org/node/102679 |the issue thread ]]

Usability

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

Input formats. A different point of view

claudiu.cristea — Sun, 27 Jan 2008 21:50:27 +0000

Drupal is formatting the user input by applying a set of customized filters before the content is send to visitor’s browser. In other words the user input is stored untouched in the database (except the SQL injection filtering) and then the filter module is performing code cleanup and formatting at the HTML output. In fact the input formats are... output formats :)

There are web administrators (and so am I) that preferring to filter the content at input. They want clean code stored in the database backend. They want to strip all potential dangerous code and also fix XHTML issues before the content is stored. Why? There are many reasons. Maybe they use the Drupal database with other client applications that have no output filtering system and they want be sure that the content retrieved from database is "clean". Maybe is possible that in the future they will need to migrate to other systems and they want to have a well formed content in their database.

Drupal output formatting/filtering is valuable too. I’m thinking specially to URL filter, Line break converter, PHP evaluator. These are kind of tools that are dealing more with formatting than with filtering. They alter the content in a manner that is not necessarily needed to be stored in the database. They need to be applied at output rather than input.

My proposal: For each input format the administrators should configure each filter if it is an input or an output filter. Each filter checkbox will turn into a combo box with 3 values: "none", "input filter", "output filter". For example the Filtered HTML input format can have the HTML filter configured as input filter while Line break converter and URL filter are configured as output filters.

Of course this requires rewriting the filter module. Before creating patches I thought that a discussion is welcomed. Any comments, ideas?

Improvements to core

Sessions on "Community: Getting Involved in Core" Wanted For Drupalcon 2008

mpare — Sat, 19 Jan 2008 01:07:08 +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 "Community: Role of the Contributor" and since your viewing this post on the Improvements to core 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

Improvements to core

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