Core Conversations

This session is going to be a discussion more than a demo of proposed code. We'll take a look at what solutions other systems (namely WordPress) have included to deal with rich text editing, and we'll identify the central problems with building similar functionality into Drupal.

Ultimately, the solution currently being pursued will be an overhaul of the "Filter" module (which currently is only designed for filtering on output), and replacing it with a new module that controls not only filtering on output but also on input, making it possible to provided a true WYSIWYG (or at least a lot closer than anything we have today).

Drupal should focus on the audience it serves best. IMO, thats mid range and high end web sites. With that focus, we can design cleaner software and avoid some prolonged fights in the issue queue. Perhaps we can even stop the defections from core development (e.g. Development Seed).

Here are some possible increases in our software requirements:

- Shell access to your server is required.
- Drush is required
- APC or other opcode cache is assumed present

Unified Entity API as Part of the Configuration Management Initiative
As a sub-effort of the Configuration management initiative, we need to standardize the core Entity API.

catch and I discussed this possibility in Chicago. This conversation will be an update on progress and plans going forward.

An Entity Property API for Drupal 8
The entity API module achieves already something similar in Drupal 7. It comes with an Entity property information system, which kind of wraps Drupal's divergent data structures behind unified data wrappers.

However for Drupal 8 we want to avoid the need for unnecessary wrappers. So we need to come up with an API that fulfills developer's needs without anything extra. So should be everything a field then?

I'd like to present and debate a slightly different approach: The entity property API, which cares about an unified and easy way for accessing and updating property values, validation, access information as well as other property metadata.
With such an entity property API in place, fields could very much build upon this generally useful API and complement it wherever necessary. Related, we might want to look into streamlining field storage and entity storage, and provide a storage system that can handle translatable properties out of the box.

For example, this is how the API could work:
<?php
// Get a node author.
$account = $node->author->get('author');
// Still, you can access $node->uid directly.

// Get the english version of the node title.
$node->get('title', array('lang' => 'en'));

// Throws exception if mail address is formatted invalid.
$account->set('mail', $value);

// Chain things as you wish.
// -> Get the node author's fourth hobby stored in his main profile.
print $node->get('author')->get('profile_main')->get('hobbies', array('delta' => 3));
?>

During Google Summer of Code we are working on this topic. Let’s imagine that modules describe trees instead of simple lists when they determine their permissions. Leaves of these trees can be very specific about what rights and functionalities the users get if we grant that certain permission for them. Without a tree, this would mean an unmanagable number of permissions but with the hierarchy, users can be as specific or generic as necessary when granting permissions. There is no more situation like enable the ‘administer something’ permission where we have no idea what power we give our users, unless we have experience of that certain topic and module. Well-structured permission trees with a brand new user interface could be a huge step forward to a better UX.

In this presentation we would explain this whole philosophy, and show the new fancy UI (or at least some plans for one) for the permissions management page. Then we could discuss the possibilities to integrate this work (with more or less modifications) into Drupal 8 core.

Data. We mine the Drupal.org database and report our findings. What's the average wait time of people in the approval queue? Is the review team actually finding and stopping security holes before they get introduced? What's our attrition rate like, after someone goes through the application process? Is webchick just overreacting?

From here, we discuss next steps. We'll propose some of our own, but are really interested in a discussion from the folks in the room about what can be done to balance the legitimate needs of the security team and our community, without bludgeoning new contributors in the face.

 
How do we make Drupal content responsive?

This question is tricky, but its essential that we agree on the direction Drupal needs to go.

Possible solutions:
- Let the theme system convert semantic content into rendered markup
- HTML5, mircrodata, microformats, RDFa, whatever, describing the semantics internally?
- JSON as loose semantic structure?
- Please god, not XSLT
- element info API version 2?
- RDFa, JSON and Aloha editor like: http://www.slideshare.net/bergie/vie-using-rdfa-to-make-content-editable
- Drag and drop design patterns into a WYSIWYG that stores both markup and semantic understanding of content?

In this presentation we'll explain how we could turn Drupal documentation into modular, reusable units on which we can collaborate. We'll explain what single sourcing is and how we could from a single set of topics make documentation for different purposes and topics. From a shared topic repository we would be able to create manuals, online help, built in help, training materials, training curricula and FAQ's for RFP's.

We'll give an introduction to DITA (Darwin Information Type Architecture), an Oasis XML standard started at IBM and how it's used in industries with modular products to publish documentation in a range of formats in minutes in stead of days while saving up to 60% of translation costs.

We'll than explore how we could implement a documentation tool chain for Drupal that would take advantage of a DITA like architecture. We'll talk about:

• The conditional text GSoC
• The core initiative for an improved built-in help system
• the DITA Drupal module and explain how we want to make Drupal a platform for community authored DITA documentation that does not require knowledge about DITA from it's contributors.

Search in Drupal 8
It has been largely agreed that core search in D8 should therefore be split into a generic framework providing backend- and data-independent tools for providing indexing and search capabilities, and a default implementation of that framework that small users can instantly use to add search capabilities to their sites.
Advanced search solutions like other backends (Solr, Xapian, Sphinx, …), facetted searches, searching of external content, etc., should easily be able to build on the core search framework to provide a unified API to all kinds of searches, and to avoid re-inventing the wheel over and over for all backends and purposes.

There are already several discussions and other resources detailing all aspects of that new search framework:

• Core Drupal Search Architecture for D8
• Search in Drupal 8
• Drupal 8 Search Feature Ideas

As a base solution I'd suggest the Search API module, which already supports most of the required features and could be adapted well enough to provide the others as well for D8 core.
I'd be willing to take a shot at that and would present a rough plan for it in this core conversation. Then, the discussion could work with a concrete proposal for which possible flaws, short-comings and open points could be debated.

Also it could be discussed how this will fit in with large other changes in D8, like i18n, configuration management, plugin system, entities, etc. It will especially be important if there will be something like the Entity API (or at least its property information system) in D8 core.

Search toolkit for Drupal 8
The current Search module suffers from a lack of maintainer-ship. We need to simplify the functionality provided by the core back-end so it becomes easier to maintain (and test) going forward.

In addition, new effort should focus on providing in Core a Search Toolkit that provides a framework and basic implementation for the UI, but moves away from any attempt to interface generically with the indexing process or other pieces that are back-end specific. A key portion of such a toolkit would be adapted from the Facet API module

In addition, we should remove the advanced search form from core, remove most of the complex query parsing from core, and provide implementations of a couple facets for core via the SQL back-end.

The net advantage is that new search UI elements could be used across back-ends, and theming would be more consistent regards of how the search results are generated.

Many possible solutions:

- Expand or remove the access operation whitelist.
- Move to entity-based grant storage.
- Remove complex access from core.

Be awesome!

Disclaimer: session template borrowed from Greg Dunlap, thanks :)