Om dit probleem aan te pakken werd beslist over te schakelen op een nieuwe logica voor versies, met Major en Minor versies ingebakken.

Transcriptie

1 Openfed 2.x Voornaamste veranderingen tussen Openfed 1.x en Openfed 2.x 1.1 Waarom een nieuwe hoofdversie Tot nu toe werkten we steeds met kleinere versiesprongen (1.1, 1.2, 1.3, ), waarbij geen onderscheid werd gemaakt tussen veiligheidsupdates, bugfixes, kleine veranderingen en grote veranderingen. We hadden ook niet de mogelijkheid om een versie met grotere wijzigingen uit te brengen en dan nadien nog snel een veiligheidsupdate op de vorige versie, wat het moeilijk maakte om een geplande uitrol van grotere wijzigingen te combineren met de regelmatig noodzakelijke veiligheidsupdates. Om dit probleem aan te pakken werd beslist over te schakelen op een nieuwe logica voor versies, met Major en Minor versies ingebakken. Een overschakeling van 1.x naar 2.x, 3.x, ezv. is een Major update, waarin we fundamentele wijzigingen aanbrengen aan Openfed. Een overschakeling van 2.x naar 2.y (bvb. Van 2.1 naar 2.2) is een Minor update, dit zal meestal gaan om veiligheids- of bugfix updates, met eventueel kleinere wijzigingen met weinig risico op compatibiliteitsproblemen (bvb. Verwijderen van een ongebruikte module of kleine wijzigingen in de gebruikersrechten) In versie 1.x gebeurde dit allemaal door elkaar, maar vanaf nu zou dit gescheiden moeten gebeuren, we verwachten dan ook dat we sneller naar van 2.x naar 3.x naar 4.x zullen gaan (wellicht +- iedere 6 maanden) in de toekomst dan de sprong tussen 1.x en 2.x (al meer dan 2 jaar). 2 Wat zijn de grote veranderingen tussen 1.x en 2.x? 2.1 Algemene opfrissing van alle modules Voor vrijwel alle modules gebruikt in Openfed (en dat zijn er meer dan honderd) hebben we ervoor gekozen om in één klap te upgraden naar de allerrecentste versie dat betekent in sommige gevallen een sprong van anderhalf jaar aan bugfixes en functionaliteitsverbeteringen de impact hiervan voor de gebruikers is vrij beperkt, in de meeste gevallen waar bepaalde bugs of gebreken een probleem stelden hadden we reeds één of andere oplossing of workaround gerealiseerd, ook zijn niet alle gekende problemen vanzelf opgelost door naar de nieuwste versie te stappen. Door zo n grote sprong is het risico op kleinere en grotere compatibiliteitsproblemen bij upgrade uiteraard groter dan normaal onze tests tot nu toe wijzen echter uit dat de problemen die zo opduiken in de meeste gevallen vlot kunnen afgehandeld worden in onze upgrade-voorbereiding. 2.2 Verwijderen van een ongebruikte of onveilige module backup_migrate De module backup & migrate werd verwijderd in de Fedict omgevingen is deze functionaliteit reeds voorzien via andere oplossingen en het is een complexe en grote module met door haar aard een grote kans op veiligheidsproblemen. Leveranciers die tijdens er de ontwikkeling gebruik van willen maken kunnen dit nog steeds doen, zonder deze mee te leveren bij oplevering.

2 2.3 Toevoegen van enkele veelgevraagde extra modules bean combined_termref context drafty entityreference_view_widget field_default_token file_entity google_tag inline_entity_form menu_link_weight menu_node menu_to_taxonomy module_filter node_edit_redirect views_tree Het merendeel van deze modules zijn op één of ander moment gevraagd geweest voor gebruik in één of meerdere Fast2Web-websites en leken ons daarom zinvol om standaard ter beschikking te stellen. Een uitleg over de precieze functionaliteit van deze modules zou ons te ver brengen, de geïnteresseerden kunnen meer informatie terugvinden op Upgrade van de module Webforms van 3.x naar 4.x Dit was noodzakelijk geworden omdat de versie 3.x van deze module weliswaar nog beveiligingsupdates ontvang, maar weinig bugfixes en zeker geen nieuwe of verbeterde functionaliteit. Dit is een vrij grote update vanuit technisch oogpunt, er zijn grote onderliggende verschillen tussen 3.x en 4.x, maar uit al onze tests blijkt dat de automatische upgrade-scripts om webformulieren over te zetten naar de nieuwe versie meer dan behoorlijk werken eventuele problemen zullen door ons onderzocht en aangepakt worden. De twee voornaamste front-end verschillen tussen 3.x en 4.x zijn: De manier waarop automatische mails van webforms opgebouwd worden is omgevormd naar het standaard Drupal 7 Token systeem in plaats van een eigen custom systeem dit maakt onderhoud door Drupal-experts makkelijker. Er wordt een onderscheid gemaakt tussen het from adres en het reply-to adres bij het verzenden van mails, dit is belangrijk omdat een from adres gekoppeld is aan een toegestane mailserver (niet zomaar iedereen kan mail sturen from obama@whitehouse.gov) maar een reply-to adres mag wel anders zijn. Dit kan enorm helpen in onze situatie waarbij we meer dan honderd verschillende websites op één server draaien hebben en niet noodzakelijk steeds de toestemming hebben om mails from de naam van de site te sturen.

3 2.5 Standaard-activering van Workbench_moderation Deze module was reeds beschikbaar in Openfed 1.x maar stond standaard uit. Ze biedt technisch de mogelijkheid om workflows te gaan definiëren, waarbij bepaalde gebruikers bvb. wel inhoud mogen aanmaken of in klad wijzigen, maar niet zomaar deze inhoud mogen publiceren. Een andere persoon of personen kan dan gevraagd worden de wijziging/toevoeging goed te keuren voor publicatie. Technisch hebben we er in de standaard-configuratie voor gekozen om een beperktere vorm van workflow te hebben iedereen met de rol Content Manager kan nieuwe inhoud aanmaken/inhoud wijzigen/inhoud publiceren. In die zin verandert er niet zo veel want dit was reeds het geval in Openfed- 1.x Echter, de Workflow die we opgezet hebben maakt het mogelijk om klad-versies van inhoud te gaan aanmaken, ook van reeds bestaande inhoud dat wil zeggen dat men wijzigingen kan maken op reeds gepubliceerde pagina s, maar kan kiezen deze wijzigingen nog niet te publiceren (in Openfed-1.x was iedere wijziging op een publiek zichtbare pagina altijd onmiddellijk ook publiek zichtbaar). Men kan zo bvb. een hele groep pagina s inhoudelijk gaan aanpassen en deze dan als groep publiceren. Of bij voorbeeld een aanpassing die meer tijd vergt om te schrijven kan men half afgewerkt bewaren en op een ander moment voortwerken, of laten nalezen door een collega vooraleer ze publiek te plaatsen. Ook zeer interessant hierbij is dat er een makkelijk bruikbare manier is om terug te keren naar vorige versies van de inhoud, of de vorige versie te bekijken zonder ze terug publiek te zetten. Om het gedrag consistent te houden over al onze sites hebben we ervoor gekozen deze manier van werken algemeen te activeren in de volgende vorm: 1) Een nieuwe inhoud wordt standaard als niet gepubliceerd aangemaakt en moet dus expliciet publiek gezet worden dit kan tijdens de aanmaak, of vlot naderhand via een nieuw menu bovenaan (in EN: My Drafts, in FR Mes brouillons, in NL Mijn concepten ) 2) Indien men een bestaande inhoud wijzigt drukt men niet meer op een link Wijzigen/Modifier/Modify maar op een knop New Draft/Nouveau Brouillon/Nieuw Concept deze nieuwe kladversie zal eveneens standaard niet gepubliceerd staan, de vorige versie blijft online tot men deze expliciet vervangt door de nieuwe. Dit is qua werking voor velen een vrij grote verandering, afhankelijk van de situatie kan dan ook een aanpassing gevraagd worden aan dit gedrag (bvb. toch standaard gepubliceerd, of heel de workbench_moderation module gedesactiveerd) Ingewikkeldere workflows met goedkeuring zijn eveneens mogelijk, alleen zal dit afhankelijk van de complexiteit van de vraag mogelijk door een leverancier op factuur moeten gebeuren.

4 2.6 Enkele schermafdrukken van Workbench_moderation Overzicht kladversies waarop men werkt: Merk dat men rechtstreeks in dit overzicht een kladversie gepubliceerd kan zien. Bewerkingsgeschiedenis van één bepaalde contentpagina: Hier kan men alle vorige versies oplijsten, zien we de wijzigingen gedaan heeft, een kladversie publiceren, een inhoudspagina op unpublished zetten (dan is ze niet langer zichtbaar voor bezoekers, in welke versie ook) maar ook bij voorbeeld via de Revert functie terugkeren naar een oudere revisie.

5 Vergelijking maken tussen verschillende revisies Men kan vlot vragen (via de Compare knop) om een vergelijking te zien van de verschillen tussen verschillende versies van éénzelfde contentpagina om te zien wat er veranderd is:

6 2.7 Nieuw uitzicht voor het inhoudsbeheer We maken hierbij gebruik van een nieuw zogenaamd Drupal Theme in plaats van een geheel zelfontwikkelde look&feel is deze zwaar gebaseerd op een populair alternatief op de standaard Drupalinhoudsinterface dit alternatief heet Adminimal en heeft enkele grote voordelen: 1. Een heldere weergave die iets groter en duidelijker is dan de standaardinterface, met duidelijker onderscheid tussen inhoudselementen 2. Véél betere ondersteuning voor mobiele toestellen bij zoals tablets of zelfs mobiele telefoons voor content-management 3. Een grotere visuele compatibiliteit met de in de toekomst geplande Drupal8 versie van Openfed, zodat mensen die sites in de verschillende versies gaan moeten onderhouden vlot hun weg kunnen terugvinden in beide. 3 Voorbeelden van de visuele verschillen tussen Openfed-1.x en Openfed-2.x

7 Openfed 1.0 Nieuwe Pagina

8 Openfed 2.0 Nieuwe Pagina

9 Openfed-1.0 Nieuwe Pagina op een Smartphone Dit beeld is niet verkleind heel de gebruikersinterface is op mobiel zéér klein en onleesbaar.

10 Openfed-2.0 Nieuwe Pagina op een Smartphone (Merk op dat dit niet één breed beeld is, maar de twee bovenste stukken van een scrollbaar beeld dat nog een tijdje doorscrollt en alle functionaliteiten bevat) alle mogelijkheden zijn (eventueel met enige moeite) aanklikbaar vanop een mobiele telefoon.