IIRS Solution Design

Please refer to the IIRS/ArchitectureOptions and principles therein.

Features overview

The IIRS will be an add-on service with its own Drupal 7 install. This install will provide the means to:

1. Initiatives: A slimline Initiative content type, related views and maps etc that are synced with TN.org D6.
2. Users: Allow users to log in (to their accounts on the current D6 site), or register (with the new account synced back from D7 to D6).
3. Widget: Add, Edit (with correct perms), list/map initiatives and view single initiatives via a widget.
4. Sync: post-moderated (pre-accepted) D7 initiatives back to TN.org D6 via a web service, AND from D6 to D7 as edits happen there.
5. Hub: Store 'National Hub profiles' that facilitate the translation and syncing of the UI and data.

Drupal 6 site changes

1. New content type: "Transition Hub" - represents the key information about the hub and widgets that will provide content in that language. Has language, country, translated intro text, points of contact, and remote (D7) path for services.
2. New Panels layout for "Transition Hub" content type: Shows key (translated) text in panels layout, below which is a full-page widget showing lists and maps of Initiatives, with the option to view them IN A POPUP in the Hub language. This panel should ideally pre-display the widget using variables from the Hub profile.
3. Services for syncing user accounts, Transition Hub and Initiative profiles nodes automatically on edit, delete (unpublish) and 'provision' to get the D7 site the content it needs.

Drupal 7 site features

Distribution, Profile, Frameworks

1. Based on ​Panopoly for an excellent editorial experience out of the box. There is a lot of momentum around Panopoly in the Drupal world.
2. Theme based on Twitter's ​Bootstrap (v2.3.2) framework for a cross-browser, responsive, clean and deeply sexy starting point. There's loads of good resources and tools on the web for Bootstrap.
3. Lots of Drupal themes integrate with Bootstrap, but ​Radix is also gaining a lot of traction with distributions and works great with Panopoly, Open Atrium, Open Outreach and others.
4. [​Debut will provide as much base features as possible, to minimise custom code and get a fast start on key features. For now these are not needed for content types, but standardising around other features will make future development and integration with other Drupal sites easier. Recommended for consideration: ​Membership, ​Location, ​Social, ​WYSIWYG
5. Will create a 'Transition National Hub' Drupal install profile to allow this site to be built easily on the Transition Network server, and indeed on other interested parties systems.

Transition-specific custom Features & modules

@todo convert to table and list if each is able to be re-used for D6, D7 IIRS or D7 TN.org @todo create a diagram to show what features sit where, and what depends on what...

1. Transition Network Core - D7 - variables in feature wrapping all shared dependencies and extras needed to make the site(s) tick.
2. Transition Initiatives - D7 - a feature wrapping up a content type, some simple list-style views (user-facing and admin) and panels panes.
3. Transition Initiatives Widget - D7 - a module providing the widget (converted from the ​D6 PSE project).
4. Transition Hub - D6 & D7 - anything specific to national hubs goes here. Each 'Hub' content represents a national hub and has language(s), name, country, website and other data. D6 version provides content type, plus 'country homepage' with translated text and widget embedded panels view. D7 provides content type (and others feature TBC).
5. Transition Users - D7 - a feature wrapping up a basic user account, plus some views (users-facing and admin). Need to decide if this is core D7 accounts, or needs Profile2 etc. Ideally would handle social login/register too.
6. Transition * Services - D6 & D7 - (where * is 'intuitive', 'user' etc.) - a feature for each core piece of data that contains relevant services including CRUD, views/lists and probably authentication.
7. Transition Network Sync - D6 & D7 - a module that uses pluggable services (in the above point; for initiatives, users, projects, hubs etc etc) to sync data back to the 'hub' D6 TN.org site.

Widget-related custom modules

The widget is to be a more flexible evolution of the work started in Sharing_Engine/Technical_Proposal Project Sharing Engine?. The plan is to build on this base but turn the it into a clear, clean model based on a set of components that can be added, extended and re-used. Since Drupal 7 is not MVC, and neither is Drupal 8, the proposal is to use the CTools Plugin architecture (​example here) to allow new Widget components to be added/enabled over time.

Widget components

1. Core --- a module that holds all the shared variables, admin, functions, permissions and other logic that will drive all widgets and facilitate the rest of the components.
2. Builder -- this is the UI module that will allow a user (with permission) to chose the type of widget, Context (see below) Purpose and style of a Widget and build an instance. The module will take these options and create a 'Widget Instance' (see below) before generating the themed, styled Widget Chrome (below) for a user to paste into their website.
3. Chrome (output, concept) -- the 'Widget Chrome' is this is the actual HTML and related CSS/JS, built by the Widget Builder (above), that a user cut/pastes into their site in order to display the widget. It's held on the client site and runs via whatever tech drives it (iFrames to start, web services & backbone maybe one day). The chrome used depends the user's choice of Type (Full screen, sidebar, button options etc), Style (css, colours etc - not planned to be editable initially), and Framework (iFrame for now, later other options might become available).
4. Recipe -- When user builds a widget, the relevant context, workflow and purpose of the widget will be stored in a Drupal entity called Widget Recipe. This then allows a user to re-generate the widget at any with different styles/types using this recipe. It also allows a central store of both users and administrators to manage widgets and avoid misuse, and provides a means of recreating any widget in use to provide support and debugging. A Widget Recipe consists of:
   1. Target -- the entity target(s) for the widget... For now the only 'target' data will be an 'Initiative' node, but this can be anything once the appropriate widget displays and services plugins are built (see below).
   2. Purpose -- what the widget is for, e.g. National Directory (this is all we're building for the IIRS), Projects near Initiative, Single Node (e.g. for embedding a single page for an event, initiative or other content), Newsletter signup etc etc. The purpose wraps up a set of Displays (Views onto Services) inside Workflows (see below).
   3. Context -- the language, country, user (owner) and other background information the widget is to be used for. This data will be auto-selected from the user's account, or from another target depending on purpose.
5. Display -- An actual single pane of UI within the widget, either stand-alone or as part of a Workflow. Each 'Display' (effectively a 'View' in MVC) uses the theme layer to render the data provided by a Service that is set by the Recipie's context, target and purpose. However, in Drupal 7 and for the purposes of the IIRS, the Display (UI) and the Service (data/logic) are often provided together by various modules -- e.g. Drupal core's login form... For example, the 'View list of Initiatives' display will provide show the output of a Drupal view that lists the recent initiatives added
6. Service -- are little chunks of functionality that deliver data to a View (see below). They are similar to the 'Controller' plus part of the 'Model' in MVC. Ideally the services map directly to real web services, though for now this is not likely to be needed/possible. Drupal 8/Symfony makes Services much more powerful however. Examples would be 'List nodes', 'Search nodes', 'View Node', 'Log in', 'Register', 'Add node', 'Edit node', 'Newsletter Signup' etc. In Drupal 7 these are effectively menu callbacks.

Hence most (all?) of the initial view

Complete widget example

1. User (from France, in French) has permission to create themselves a

1. Workflow -- A pu

Web services

@todo see what the ​Services module does out the box. Note also D6 Services module is hamstrung by ​https://drupal.org/node/2014573.

Services include:

1. Entity sync for: Users, plus each content type we want to send to/from D6/7.
2. A login/authentication service.
3. Ideally make these resilient with a Queue.