een bestaande implementatie omzetten naar een multisite oplossing (Drupal 5.7)

Beste forumgenoten,

Ik ben al anderhalve maand bezig om een multisite oplossing neer te zetten, en het wil maar niet vlotten.

We hebben een Drupal 5.7 implementatie draaien op www.provenpartners.nl. We proberen om 3 domeinen toe te voegen aan deze implementatie:

Deze domeinen hebben ieder unieke, maar ook gedeelde content. Verder krijgen ze een eigen template, die qua grid veel overeenkomsten hebben. De blokken kennen dezelfde opbouw.

Taxonomy
De opzet is om één database te gebruiken, en de content via taxonomy (categorie) te verdelen over de sites. Per site is er dus één categorie. In de blokken wordt vervolgens een php-statement opgenomen waarin staat dat alleen content getoond mag worden als de juiste categorie is gekozen. Content die op meerdere sites getoond moet worden, heeft dus meerdere categoriën meegekregen. In de settings.php heb ik geen prefixes meegegeven aan de verschillende sites.

Theme/Blocks
Per site willen we een eigen theme met eigen blokken gebruiken. De blokken zijn qua php inhoud ongeveer gelijk, het verschil zit hem in het bepalen van de juiste taxonomy. De blocks krijgen per site in het tpl-bestand dan ook een prefix mee.

Directorystructuur
Zoals dat werkt met multisites in Drupal, heb ik in de map " /sites" de andere domeinnamen aangemaakt. /sites/default heb ik voorlopig aangehouden voor provenpartners.nl.

Oorspronkelijk stond het provenpartners template onder " /themes", inmiddels heb ik die verplaatst naar /sites/all/themes. De andere templates heb ik ook geplaatst onder /sites/all/themes. Als ik ze onder sites/domeinnaam.nl plaats (zoals de regels voorschrijven), zie ik de blokken in de admin niet terug en kan het template niet kiezen.

Echter, ook als ik nu het template wil kiezen, dan pakt die het template voor alledrie de sites. Ondanks dat ik het vanuit de admin van een specifieke site heb gekozen.

Kortom, de directorystructuur van sites en themes ziet er als volgt uit:
/sites
/sites/all
/sites/all/modules
/sites/all/modules/alle eigen geïnstalleerde modules:
- admin_menu
- akismet
- auto_nodetitle
- emfield
- feedburner
- flickr
- flickrstickr
- flickrup
- globalredirect
- google_analytics
- job_queue
- mollom
- pathauto
- poormanscron
- search404
- simplefeed
- token
- update_status
/sites/all/themes
/sites/all/themes/proven
/sites/all/themes/proven/block.tpl.php
/sites/all/themes/proven/node.tpl.php
/sites/all/themes/proven/page.tpl.php
/sites/all/themes/proven/style.css
/sites/all/themes/proven/template.php
/sites/all/themes/provenpartners (zelfde structuur als proven.nl)
/sites/all/themes/provenworks (zelfde structuur als proven.nl)
/sites/default
/sites/default/settings.php
/sites/proven.nl (zelfde structuur als default)
/sites/provenworks.nl (zelfde structuur als default)
/themes
/themes/provenpartners

Wat werkt er nu niet (goed)?
De belangrijkste is dat ik op de een of andere manier geen afzonderlijke template per site kan instellen. Daarnaast lukt het me niet goed om o.b.v. de taxonomy de juiste content te tonen; oftewel het maken van de juiste php code in de blokken.

Wat heb ik nodig?
Wel, de oplossing zou mooi zijn :) Echter, hoe uitgebreid deze uitleg ook misschien is, ik begrijp dat er vast nog meer vragen zijn die kunnen leiden naar de oplossing. Ik ben nu al anderhalve maand bezig om het voor elkaar te krijgen, en loop inmiddels achter op schema. Mocht er iemand zijn die dit betaald voor mij kan en wil realiseren dan hoor ik dat ook graag. Voorwaarde is dat de oplossing ook weer met de community gedeeld wordt. Mocht je dus zelf iemand kennen die het kan oppakken (als je het zelf niet kan/wil), dan hoor ik het ook graag!

Alvast hartelijk bedankt voor het bekijken van mijn 'probleem'!
met een hartelijke groet,
Tom Verhoeve

 

Dag TomV,

Dit is dan misschien wel "you're lucky day"...

Wij hebben iets dergelijks gerealiseerd met de Multiple Domains module.. Surf maar eens naar http://www.locomotief.be/

Moest ik dat project opnieuw moeten/mogen doen, dan zou ik Domain Access overwegen.

Have fun!

Groeten,
Pieter
Jeugdwerknet.be medewerker

Beste Pieter,

Dank voor je reactie. Multiple Domains vereist een aanpassing in de core, iets dat ik liever niet doe. Domain Access heb ik geprobeerd, maar kwam ik niet snel uit. Ik zal er eens een nadere blik op werpen.

Aan de andere kant vraag ik me af waarom ik hiervoor een module nodig heb. Multisite is toch iets dat Drupal standaard ondersteund? Nog sterker, het is één van de krachtige punten van Drupal. Waarom werkt het dan niet?

mvg,
Tom

Hoi Tom,

Multisite werkt zeker, en het is inderdaad een mooie en krachtige functie van Drupal.

Je eenvoudige vraag 'waarom werkt het niet' is echter moeilijk te beantwoorden... Multisite hangt namelijk af van de configuratie van je webserver. Werk je met echte vhosts in de Apache configuratie? Heb je dit getest?

De eerste test die ik zou doen is kijken of PHP de 'binnenkomende url' van de HTTP request juist doorkrijgt...

En een ander vraagje... Na het plaatsen van template files per multisite... Heb je toen de template cache leeg gemaakt? Dat kan namelijk ook een mogelijke verklaring zijn :-)

Wat betreft je vraag 'waarom een module gebruiken?'...

Multisite is bedoeld om via 1 Drupal installatie verschillende sites op te zetten. Ofwel met verschillende databanken, ofwel met dezelfde.

Als je content wilt delen tussen die verschillende sites, maar niet alles, dan moet je trucjes toepassen (zoals jij dus reeds doet). En de mooiste, best te onderhouden manier om trucjes toe te passen heet... een module :-)

Beste,

Voor zover ik weet is het met de ingebouwde multisite functionaliteit van Drupal niet mogelijk om bijvoorbeeld bepaalde pagina's te delen en bepaalde pagina's niet.

Ik heb de ingebouwde multisite functionaliteit van Drupal altijd gezien als de mogelijkheid om verschillende sites te runnen op dezelfde (fysieke) broncode, wat het up-to-date houden van de Drupal code van die sites zou moeten vereenvoudigen.

Ik heb er echter zelf nog geen ervaring mee omdat onze webhost zo'n configuraties niet toelaat.

Ps: ik doe ook liever geen core-hacks.. want dat zijn gevaarlijke "dingen" bij upgrades, maar als het moet dan moet het :p

Groeten,
Pieter
Jeugdwerknet.be medewerker

afbeelding van demeesterroel

Gemakkelijkste zou zijn als we konden zeggen: "NEVER patch CORE", maar soms kan het bijna niet anders.

Ik zie slechts 2 'aanvaardbare' mogelijkheden om CORE te patchen.

1/ Als je een patch (ofwel die van jezelf, ofwel van iemand anders) toepast die in de issuelijst staat en waarvan je bijna zeker bent dat ie in de volgende release wel zal zitten. Plaats dan ook je *.patch bestand in een aparte folder zodanig dat je na een upgrade tenminste nog een overzicht hebt van de patch(es) die je hebt uitgevoerd

2/ Je schrijft een custom module vb. core_patch_123.module waarin je de bestaande functionaliteit volledig overschrijft (soms moet je daarvoor verschillende functies copy-pasten), en dan in jouw eigen module de patch uitvoeren. Dit heeft als voordeel dat je later bij een upgrade, zeker de patch niet ongedaan maakt en makkelijk kan checken of je dan patch nog nodig is.

Dit wordt belangrijk als je veel sites te onderhouden hebt, na enkele maanden weet je echt niet meer wat er allemaal gebeurd is met de code, en dan kan je alleen terugvallen op je eigen consequente routines.

Allemaal hartelijk bedankt voor jullie reacties. Via de mail kwam Gaele Strootman nog met de tip voor de taxonomy_theme module.

We hebben inmiddels professionele hulp ingeschakeld om onze implementatie goed tegen het licht te houden. Mogelijke oplossingen kunnen zijn dat:

  • met kleine aanpassingen de gewenste functionaliteit alsnog beschikbaar is;
  • we opnieuw de site moeten opzetten (aangezien de site nog geen jaar oud is, is dat geen enorm struikelblok), maar dan met de kennis en ervaring die we nu hebben;
  • we over moeten stappen naar een andere techniek.

Alle opties zijn mogelijk, maar we gaan uiteraard het liefste uit van het eerste. Ik zal jullie op de hoogte houden van de ontwikkelingen!

Ik onthoud dat je voor zulke 'afwijkende' noden dus best eerst op voorhand nakijkt of het mogelijk is, en dan pas de rest van de site opzet :-)

Veel succes nog!