[Ervaringen] Het grote Drupal-topic

[MsG]

Wat gebruiken jullie vooral als editor voor de eindgebruikers? Ik zoek namelijk iets waarmee mijn klant die bij wijze van enkel Word-kennis heeft met een knopje in de editor een afbeelding kan uploaden. Standaard kan je alleen een pad opgeven, dat is niet ideaal.

[Michali]

Je kunt kijken naar de WYSIWYG of CKEditor module icm. IMCE.

[afraca]

Interessant nieuws dat ik tegenkwam, whitehouse.gov gebruikt zoals de meesten wellicht gehoord hadden sinds oktober ons prachtige CMS Drupal Ondertussen hebben ze er lekker mee lopen bouwen en om aan hun behoeftes te voldoen hebben ze zelf 4 modules ontwikkeld:

Een van de modules heet 'Akamai'. Deze maakt de integratie met het gelijknamige content delivery netwerk mogelijk. De module 'Context HTTP Headers' vereenvoudigt het toevoegen van metadata en cache-instellingen. De module 'GovDelivery' stelt gebruikers van de website in staat de emails die de website hen stuurt aan te passen aan persoonlijke voorkeuren. 'Node Embed', tenslotte, is bedoeld voor het eenvoudiger beheer van foto- en videomateriaal. Deze module was noodzakelijk om de Whitehouse.gov te laten voldoen aan een voorschrift voor toegankelijkheid van overheidswebsites.

Bron: klik

[Reveller]

Ook ik heb maar eens een blik geworpen op Drupal en vind het een prachtig opgezet product. Vooral de code vind ik erg overzichtelijk; veel beter dan de mengelmoes van bv. Wordpress of Joomla.

Tegelijkertijd vind ik de mogelijkheden wel wat overweldigend. Ik probeer uit te zoeken hoe je een standaard site-structuur kunt opzetten in Drupal, maar raak meer in de war naarmate ik langer de handboeken lees. Vandaar een vraag hier, in de hoop dat jullie mij op weg kunnen helpen.

Stel, ik wil een standaard site opzetten met URL's als

• site.com/producten
• site.com/producten/fruit/appels
• site.com/over-ons/team
• site.com/pricewatch (wat dan weer geen pagina node, maar een module is)
• site.com/blog/een-prachtige-post (ook "blog" verwijst naar een callback ipv node)

Nu zijn er - naar ik begrijp - vele manieren om deze stuctuur op te zetten:

• Maak node/1, node/2 etc. aan en geef ze url aliases. Dit is het snelst, maar lijkt me erg onhandig naarmate ze site groeit. Wat als ik tien subpagina's onder "producten" heb (met elk een eigen alias) en ik besluit dit te veranderen naar "produkten"? Dan moet ik 11 aliases handmatig gaan aanpassen!
• Maak een book "producten" en "over-ons" aan en hang daar de subpagina's onder
• Gebruik taxonomy om "producten" en "over-ons" vocabulaires" aan te maken
• Als 1, maar maak de URL's nu mbv de views module
• Etc...

Ik raak er echt van in de war. Wat is nu een "best practice" indeze? Of is het allemaal afhankelijk van je voorkeur?

[Ook al Bezet]

Reveller schreef op woensdag 28 april 2010 @ 16:06:

• Maak node/1, node/2 etc. aan en geef ze url aliases. Dit is het snelst, maar lijkt me erg onhandig naarmate ze site groeit. Wat als ik tien subpagina's onder "producten" heb (met elk een eigen alias) en ik besluit dit te veranderen naar "produkten"? Dan moet ik 11 aliases handmatig gaan aanpassen!

Met de pathauto module kun je dat automatiseren. Een kwestie van de oude aliasses weg laten gooien en nieuwe aanmaken.

[kwaakvaak_v2]

Of beter nog, de eventuele oude aliasen laten staan als je site al live is, en netjes met een 301 door sturen naar de huidige

[Bozozo]

Een vrij specifieke vraag: heeft iemand wel eens een CKEditor plugin gemaakt voor Drupal?

Ik heb een eigen knopje gemaakt, en toegevoegd aan de CKEditor toolbar middels een paar regels javascript in sites/all/modules/ckeditor/config.ckeditor.js. Als ik nu een module maak (met de optie om te integreren met CKEditor), moet ik dan met PHP het config.ckeditor.js bestand aanpassen of is er een nettere methode?

[Tjeemp]

Wij willen binnenkort gaan beginnen met het leveren van een 'eigen' cms bij onze diensten. Momenteel zijn wij aan het oriënteren of we dit van scratch moeten gaan doen of op de core van een bestaand pakket.
We hebben in ieder geval het advies gekregen om niet 'het wiel nog een keer uit te vinden' en daarom gebruik te maken van een basis van een ander systeem en daar verder op uit te bouwen.

Mijn vraag is voornamelijk of Drupal geschikt is om op voort te bouwen of dat ik uiteindelijk makkelijker uit ben met een ander pakket of van scratch.

Wij leveren maatwerk aan onze klanten, daarom is het van belang dat we makkelijk modules kunnen bouwen, een adminpanel waarbij usability centraal staat en eventueel willen we ook de themingtechniek op de schop nemen om sneller onze ontwerpen om te kunnen zetten naar het CMS en dus misschien uiteindelijk wel goedkoper uit zijn en eventueel inline-editing in de website zelf, vergelijkbaar als hoe het er al in zit, maar dan wat uitgebreid.

We hebben vooral een gedegen fundering nodig waar we onze eigen wensen op kunnen plaatsen. Het handige aan Drupal als basis is natuurlijk dat het al aardig doorontwikkeld is, nog verder ontwikkeld wordt en er veel documentatie voor is.

[Mei]

Wat wil je voor een antwoord horen? Drupal is één van de meest uitbreidbare en customisable systemen in de markt, maar zonder specifieke issues kan niemand je verder helpen. Ik raar je wel af Drupal (of welk ander systeem dan ook) niet te gaan hacken. Snijd je jezelf uiteindelijk alleen maar mee in de vingers in verband met compatibiliteit en upgraden.

[Tjeemp]

Technisch gezien heb ik me er nog niet voldoende in verdiept, maar de bedoeling is eigenlijk dat we een basis/core hebben waar we verder op kunnen bouwen. Dan heb ik het over:
- user management
- login
- database connecties
- simpele standaard content types
- plugin-mogelijkheden

Het is dan de bedoeling dat we per project, wat vaak erg specifiek kan zijn, modules/plugins kunnen maken die bepaalde functionaliteit mogelijk maken die klant wil. Het voornaamste is dat we een degelijk adminpanel kunnen bouwen en eventueel een nieuwe module kunnen maken voor de theming.

Optimaal zou zijn als de core dan gewoon geupgrade wordt bij een nieuwe release en dat wij (indien nodig) onze eigen modules oppoetsen zodat het allemaal soepel blijft draaien. Maar dit is dus eigenlijk ook gelijk een belangrijk punt, het upgraden van het systeem.

En het is inderdaad extreem uitbreidbaar en customisable, maar dat kan de implementatie ook vaak tijdrovend en kostbaar maken. We willen proberen die implementatie flow meer aan te passen naar de wensen die wij in de meeste gevallen tegenkomen.

Eigenlijk is de kernvraag juist of wij Drupal zo kunnen verbouwen totdat het bijna een eigen cms is met Drupal als basis of we ons dan meer op de hals halen dan dat we met een andere basis of van scratch beginnen. En als we Drupal zouden gebruiken of wij het zo kunnen verbouwen zonder het te hacken zoals je al aangeeft.

[WernerL]

Je kunt voor drupal perfect modules schrijven. En voor het meeste bestaan al standaard modules die je zo kunt gebruiken of evt. aanpassen naar eigen wens.

Maar een 'eigen' cms met Drupal maken weet ik niet of dat gaat lukken. In principe is Drupal al een CMS. Je zou je eigen beheer module kunnen schrijven gezien het standaard beheer gedeelte nogal uitgebreid is en waarschijnlijk verwarrend voor je klanten. :-)

[Mei]

Tjeemp schreef op vrijdag 21 mei 2010 @ 23:44:
Technisch gezien heb ik me er nog niet voldoende in verdiept, maar de bedoeling is eigenlijk dat we een basis/core hebben waar we verder op kunnen bouwen. Dan heb ik het over:
- user management
- login
- database connecties
- simpele standaard content types
- plugin-mogelijkheden

Het is dan de bedoeling dat we per project, wat vaak erg specifiek kan zijn, modules/plugins kunnen maken die bepaalde functionaliteit mogelijk maken die klant wil. Het voornaamste is dat we een degelijk adminpanel kunnen bouwen en eventueel een nieuwe module kunnen maken voor de theming.

Optimaal zou zijn als de core dan gewoon geupgrade wordt bij een nieuwe release en dat wij (indien nodig) onze eigen modules oppoetsen zodat het allemaal soepel blijft draaien. Maar dit is dus eigenlijk ook gelijk een belangrijk punt, het upgraden van het systeem.

En het is inderdaad extreem uitbreidbaar en customisable, maar dat kan de implementatie ook vaak tijdrovend en kostbaar maken. We willen proberen die implementatie flow meer aan te passen naar de wensen die wij in de meeste gevallen tegenkomen.

Eigenlijk is de kernvraag juist of wij Drupal zo kunnen verbouwen totdat het bijna een eigen cms is met Drupal als basis of we ons dan meer op de hals halen dan dat we met een andere basis of van scratch beginnen. En als we Drupal zouden gebruiken of wij het zo kunnen verbouwen zonder het te hacken zoals je al aangeeft.

Ik vraag me af hoe professioneel jullie zijn/hoeveel ervaring jullie hebben. Dat is niet negatief bedoeld, maar weten jullie zelf wel alle ins en outs van het ontwikkelen en beheren van een eigen systeem en het gebruiken van een OS CMS? Als jullie je brood ermee zouden moeten gaan verdienen, dan had ik iets meer research verwacht alvorens het op een plek als GoT te posten. Lijkt me handig dat jullie voornamelijk eens moeten kijken wat jullie nou in hemelsnaam precies willen. Je kan wel je eigen templatingsysteem willen schrijven, maar als je geen HELE goede reden heb, dan verklaar ik je nu al voor gek. Verder is Drupal qua functionaliteit volgens mij genoeg uitbreidbaar, aangaande op wat ik uit jouw posts kan ophalen.

Kijk eens naar evenementen op drupal.nl waar je andere ontwikkelaars kan ontmoeten. De grootste is net twee maanden geleden geweest, maar er moet na de zomer nog weer een Nederlandse conferentie komen. Er zijn verder genoeg kleine meetups in Nederland en België. Verder zijn #drupal en #drupal-nl op irc.freenode.net ook aanraders.

Het belangrijkste is Drupal gewoon installeren en gaan spelen. Waardevolle tip: niet gelijk aannames doen als je iets niet kan vinden of als iets niet lukt. Drupal is soms zo vreselijk flexibel dat je niet snel kan vinden wat je nodig hebt en op andere punten is het ook niet altijd even logisch, maar is de door jou gewenste functionaliteit wel gewoon aanwezig.

In het kort kan ik in ieder geval zeggen dat je als klein bedrijfje met een eigen systeem bijna altijd in het nadeel bent, voornamelijk wat onderhoud betreft.

[Tjeemp]

Mei schreef op zaterdag 22 mei 2010 @ 00:05:
[...]

Ik vraag me af hoe professioneel jullie zijn/hoeveel ervaring jullie hebben. Dat is niet negatief bedoeld, maar weten jullie zelf wel alle ins en outs van het ontwikkelen en beheren van een eigen systeem en het gebruiken van een OS CMS? Als jullie je brood ermee zouden moeten gaan verdienen, dan had ik iets meer research verwacht alvorens het op een plek als GoT te posten. Lijkt me handig dat jullie voornamelijk eens moeten kijken wat jullie nou in hemelsnaam precies willen. Je kan wel je eigen templatingsysteem willen schrijven, maar als je geen HELE goede reden heb, dan verklaar ik je nu al voor gek. Verder is Drupal qua functionaliteit volgens mij genoeg uitbreidbaar, aangaande op wat ik uit jouw posts kan ophalen.

Kijk eens naar evenementen op drupal.nl waar je andere ontwikkelaars kan ontmoeten. De grootste is net twee maanden geleden geweest, maar er moet na de zomer nog weer een Nederlandse conferentie komen. Er zijn verder genoeg kleine meetups in Nederland en België. Verder zijn #drupal en #drupal-nl op irc.freenode.net ook aanraders.

Het belangrijkste is Drupal gewoon installeren en gaan spelen. Waardevolle tip: niet gelijk aannames doen als je iets niet kan vinden of als iets niet lukt. Drupal is soms zo vreselijk flexibel dat je niet snel kan vinden wat je nodig hebt en op andere punten is het ook niet altijd even logisch, maar is de door jou gewenste functionaliteit wel gewoon aanwezig.

In het kort kan ik in ieder geval zeggen dat je als klein bedrijfje met een eigen systeem bijna altijd in het nadeel bent, voornamelijk wat onderhoud betreft.

Mijn post was vooral oriënterend bedoeld aangezien wij nog in het proces zijn om uit te zoeken hoe we de ontwikkeling gaan doen. We gaan het sowieso niet zelf doen, maar ik weet hier wel van een aantal bedrijfjes die veel Drupal ervaring hebben. Wij zitten zelf vooral in het ontwerpen van websites en tot nu komt het wel eens voor dat ze de voorkant geweldig vinden, maar het adminpanel (van Drupal) komt dan overweldigend over en ik moet zelf ook zeggen dat dat qua usability sowieso nog wel wat kan gebruiken.

Kernpunten zijn eigenlijk gebruikerservaring verbeteren en implementatie verkorten/versimpelen.

Maar zoals al gezegd was mijn post vooral oriënterend bedoeld. Het besluit is eigenlijk net gekomen om een aangepast/nieuw cms aan onze klanten te leveren, daardoor is er van technisch onderzoek nog niet veel gekomen, maar ik wilde graag weten waar we onze pijlen het best op kunnen richten.

[Mei]

Ga dan eerst eens duidelijk na wat je wil. Wat voor functionaliteit gebruik je veel en moet dus goed ontwikkeld zijn of zelf aan te passen? Je kan bijvoorbeeld wel een eigen templatingsysteem willen maken, maar als die van Drupal goed genoeg is, dan is het aanleren van iets nieuws een betere optie dan het systeem afkeuren.

Standaard heeft Drupal tot en met versie 6 geen aparte beheersectie. Dit is gewoon onderdeel van het complete systeem en profiteert daarom ook van alle mogelijkheden. Voor gebruikers is dit echter wat lastig, dus daarom is een admin theme bijna een must. Deze zit dan ook in Drupal 7. Voor Drupal 6 zijn genoeg admin themes te downloaden. Als je ook zorgt dat gebruikers niet meer kunnen dan ze moeten of mogen beperk je de interface al helemaal (in positieve zin).

[Eusebius]

@Tjeemp Het is mij ook nog niet duidelijk wat voor soort klanten je aan wilt spreken: bv een autodealer (presentatie & acties) of een webwinkel (inventaris & presentatie) etc. Wat voor data gaat er verwerkt worden? Misschien is het allang mogelijk datgene wat jullie willen te doen met Drupal.

Wat ik zelf altijd doe is voor klanten die toegangsrechten mogen hebben, een apart dropdownmenu maken met daarin alle admin taken. Voor standaardinstellingen die 1x per jaar (of nog minder) veranderd moeten worden, mogen ze me mailen (denk aan instellingen Google Analytics, andere tekst boven een output van Views, etc).

Iets heel anders: las elders iets over Concrete5. Op de website zelf geven ze aan "dat ze beter zijn dan Drupal" want .. en dan volgen er een paar argumenten. Grootste is bv dat je gelijk een node kunt bewerken (dat heeft een naam, weet even niet welke). In Drupal 7 zie ik dat al terugkomen. Zijn er hier mensen die Concrete5 hebben uitgeprobeerd en wat zijn de ervaringen? De userbase van concrete5 is volgens mij een stuk kleiner.
Ik zal niet overstappen hoor ;-) Als de Drupaltrein achterloopt tov Concrete5 zal deze snelheid maken en hem inhalen. Dat is een spelletje wat zich imho tussen CMS'en herhaald. In die zin bestaat het beste CMS niet, want iets wat vandaag niet bestaat wordt morgen geschreven.

[Peedy]

Hoi!

Eindelijk eens een middagje gevonden om met Drupal te prutsen en gelijk maar even 2 sites over gezet. Ben erg te spreken over de gemakkelijke installatie en het simpele templating systeem. Sommige dingetjes in de Admin zijn in mijn ogen nog wat onlogisch maar elk CMS heeft natuurlijk z'n eigen quirks en na verloop van tijd zal ik het vast wel logisch gaan vinden.

Ik moet alleen nog iets meer in de terminologie duiken, CCK en Taxonomy zeggen me op het moment nog niets. Ook moet ik de plugins sectie op Drupal.org maar eens door struinen, daar zit veel leuk spul tussen volgens mij. Zijn er nog echte must-have plugins? Ik kwam de Wysiwig plugin al tegen, en Blockbar en Control Panel staan ook al geinstalleerd.

Oh ja, nog iets wat me stoort; de Admin heeft dezelfde layout als de rest van de site. Dit loopt soms niet lekker ivm stylesheets. Had liever gehad dat de Admin een op zich staan iets is, met een eigen styling. Maar volgens mij zit dat er in Drupal 7 wel aan te komen?

[ Voor 15% gewijzigd door Peedy op 23-05-2010 20:11 ]

[Tim Schuhmacher]

Goed zoeken in de admin settings, daar is wel aan te geven dat de admin altijd een default layout moet gebruiken, ongeacht je stylesheet voor de site zelf.

[Mei]

Peedy schreef op zondag 23 mei 2010 @ 20:00:
Hoi!

Peedy! Ook ex-Designhulp, right?

Ik moet alleen nog iets meer in de terminologie duiken, CCK en Taxonomy zeggen me op het moment nog niets. Ook moet ik de plugins sectie op Drupal.org maar eens door struinen, daar zit veel leuk spul tussen volgens mij. Zijn er nog echte must-have plugins? Ik kwam de Wysiwig plugin al tegen, en Blockbar en Control Panel staan ook al geinstalleerd.

Pathauto sowieso. Views wordt vaak gebruikt, Webform ook.

Oh ja, nog iets wat me stoort; de Admin heeft dezelfde layout als de rest van de site. Dit loopt soms niet lekker ivm stylesheets. Had liever gehad dat de Admin een op zich staan iets is, met een eigen styling. Maar volgens mij zit dat er in Drupal 7 wel aan te komen?

Administer > Site configuration > Administration theme.

[Peedy]

Mei schreef op zondag 23 mei 2010 @ 20:34:
[...]

Peedy! Ook ex-Designhulp, right?

Right Dat is een tijdje geleden zeg Leuke tijd, leuke site destijds.

offtopic:
edit; haha, heb even lopen zoeken via the way back machine, vond ik deze link, naar een ouwe cache van Designhulp met mij nog in de list van aanwezige bezoekers

[...]

Pathauto sowieso. Views wordt vaak gebruikt, Webform ook.

Driedubbel check

[...]

Administer > Site configuration > Administration theme.

Top, relaxt. Stuk handiger. Nog iets; ik heb op deze site een slider staan. Die wil ik dus op meerdere pagina's laten terugkomen. Werkt dat nou het makkelijkst via een block of moet ik in de template gewoon PHP's include gebruiken? Wat is daar best practice?

[ Voor 15% gewijzigd door Peedy op 23-05-2010 22:12 ]

[Mei]

Peedy schreef op zondag 23 mei 2010 @ 22:04:
[...]

Right Dat is een tijdje geleden zeg Leuke tijd, leuke site destijds.

offtopic:
edit; haha, heb even lopen zoeken via the way back machine, vond ik deze link, naar een ouwe cache van Designhulp met mij nog in de list van aanwezige bezoekers

Hehe. Ik was toen ook één van de stamgasten. Nog regelmatig contact met de oprichter gehad trouwens, die Drupal aan mij geïntroduceerd heeft.

Top, relaxt. Stuk handiger. Nog iets; ik heb op deze site een slider staan. Die wil ik dus op meerdere pagina's laten terugkomen. Werkt dat nou het makkelijkst via een block of moet ik in de template gewoon PHP's include gebruiken? Wat is daar best practice?

Het handigste is om zo weinig mogelijk dingen hardcoded te maken voor maintenance later. Denk aan upgraden en veranderingen doorvoeren.

[Ook al Bezet]

Peedy schreef op zondag 23 mei 2010 @ 20:00:
Zijn er nog echte must-have plugins? Ik kwam de Wysiwig plugin al tegen, en Blockbar en Control Panel staan ook al geinstalleerd.

Views en pathauto zijn al genoemd. CCK kan extreem nuttig zijn als je bezoekers dingen op je site wilt laten plaatsen. De administration menu module (http://drupal.org/project/admin_menu) is ook een érg handige, het werkt een stuk prettiger dan het normale admin menu.

[Eusebius]

Met hierboven: admin menu. Gaat als eerste aan. En de Backup&Migrate is ook een heerlijk zwitsers zakmes omtrent backups en euh migratie.

Mei schreef op zondag 23 mei 2010 @ 20:34:


Pathauto sowieso. Views wordt vaak gebruikt, Webform ook.

Hoezo noem je webforms Als je polls maakt ok, maar niet elke site heeft per se polls nodig.

- edit: nog geen reactie op mijn vraag over Concrete5 <> Drupal. Niemand ervaring mee?

[ Voor 10% gewijzigd door Eusebius op 24-05-2010 08:52 ]

[Peedy]

Ook al Bezet schreef op zondag 23 mei 2010 @ 23:35:
[...]

Views en pathauto zijn al genoemd. CCK kan extreem nuttig zijn als je bezoekers dingen op je site wilt laten plaatsen. De administration menu module (http://drupal.org/project/admin_menu) is ook een érg handige, het werkt een stuk prettiger dan het normale admin menu.

Thanks, die admin_menu is wel een winnaar inderdaad. Ik heb ook meteen even Drush geinstalleerd, dat is een stuk handiger met al die modules installeren!

[kwaakvaak_v2]

Eusebius schreef op maandag 24 mei 2010 @ 08:50:
Met hierboven: admin menu. Gaat als eerste aan. En de Backup&Migrate is ook een heerlijk zwitsers zakmes omtrent backups en euh migratie.


[...]


- edit: nog geen reactie op mijn vraag over Concrete5 <> Drupal. Niemand ervaring mee?

Ik denk dat er niet zo heel veel mensen ervaring mee hebben, mij schrikte het feit dat ik voor extra functies direct mocht betalen bij de makers van het pakket al direct zo af dat ik niet eens meer de moeite heb genomen het te downloaden.

Dan vind ik persoonlijk het symfony2 project veel interessanter klinken


Niet dat drupal voor mij persoonlijk heilig is, verre van zelfs.. Maar het grote voordeel van drupal is wel dat je er een enorme hoeveelheid extra modules vanuit de community bij kunt halen. Nadeel vind ik weer dat het echt een onoverzichtelijke puinbende is in de module repo, en veel modules eigenlijk hetzelfde doen op een net iets andere manier. Dat is ook voor mij de hoofdreden geweest om op het werk een eigen profiel te maken met een selectie van een aantal modules en die als 'onze' drupal versie te bestempelen. Houdt het overzichtelijk, scheelt je per project een hoop tijd in het zoeken naar modules, en het is voor het bijhouden van coders documentatie/howto's ook een stuk makkelijker.

[Mei]

Eusebius schreef op maandag 24 mei 2010 @ 08:50:
Met hierboven: admin menu. Gaat als eerste aan. En de Backup&Migrate is ook een heerlijk zwitsers zakmes omtrent backups en euh migratie.


[...]

Hoezo noem je webforms Als je polls maakt ok, maar niet elke site heeft per se polls nodig.

Hij vroeg welke modules vaak gebruikt worden. Niet welke altijd gebruikt worden Webform is redelijk populair om via de UI een formuliertje in elkaar te sleutelen. Contactformulieren, aanmeldformulieren, poll dus blijkbaar ook.

[Eusebius]

Mei schreef op maandag 24 mei 2010 @ 12:07:
[...]

Hij vroeg welke modules vaak gebruikt worden. Niet welke altijd gebruikt worden Webform is redelijk populair om via de UI een formuliertje in elkaar te sleutelen. Contactformulieren, aanmeldformulieren, poll dus blijkbaar ook.

Kun je webform ook gebruiken voor een inschrijving op een gebeurtenis met een beperkt aantal plaatsen? Dat na inschrijving 1000 je niet meer kunt inschrijven?

[Mei]

Weet ik zo niet. We gebruiken de module wel op drupaljam.nl, maar zonder limiet, aangezien we dat nog nooit nodig gehad hebben.

[kwaakvaak_v2]

Eusebius schreef op dinsdag 25 mei 2010 @ 12:33:
[...]

Kun je webform ook gebruiken voor een inschrijving op een gebeurtenis met een beperkt aantal plaatsen? Dat na inschrijving 1000 je niet meer kunt inschrijven?

Niet als je die 1000 niet ergens anders in je code afvangt. Wat jij zoekt zit meer in deze hoek : http://drupal.org/project/signup

[Mei]

Mooi voorbeeld van een échte developer. Zijn project page is een lading ongestructureerde tekst

Nadeel aan signup (voor zover ik weet) is dat je geen extra velden kan toevoegen. Wil je bijvoorbeeld weten of iemand ook een maaltijd nodig heeft of extra wensen heeft, dan kan je dat daarmee niet afvangen.

[kwaakvaak_v2]

Mei schreef op dinsdag 25 mei 2010 @ 13:28:
Mooi voorbeeld van een échte developer. Zijn project page is een lading ongestructureerde tekst

Noem dat maar gerust het nadeel van Drupal Dat is wel wat mij in ieder geval de meeste tijd kost bij het ontwikkelen in Drupal.

Wat dat betreft valt er nog veel te leren van andere projecten, er zijn veeeel drupal modules.. Misschien zelfs wel te veel als je het mij vraagt, en zoals bij elke ontwikkelaar is ook hier de documentatie het ondergeschoven kind (*steekt vinger op, ben er net zo schuldig aan immers :

Nadeel aan signup (voor zover ik weet) is dat je geen extra velden kan toevoegen. Wil je bijvoorbeeld weten of iemand ook een maaltijd nodig heeft of extra wensen heeft, dan kan je dat daarmee niet afvangen.

Volgens mij hang je signup aan je node, en kun je die extra gegevens dus met CCK in je node kwijt. Beetje opdezelfde manier als dat bij content profile ook werkt.


---

Weet iemand hier hoe het nu precies zit met de naam 'drupal' in een domein naam, ik loop al een tijdje met het idee om samen met wat collegea/vrienden een nederlandstalige drupal site op te zetten met code snippets en uitleg in het nederlands over wat het precies doet. En ik wil dit graag in eigen beheer doen, maar de code wel onder een CC/GPL licentie publiceren, Volledig open dus.. Volgens de guidelines zou dat mogen mits het geen commercieel belang dient. (nu dient dat het ook niet behalve een link naar sponsors van de site die niet geheel toevallig ook drupal implementaties doen)

[Mei]

Waarom niet meehelpen aan drupal.nl? Iets met krachten bundelen enzo.

CCK is bedoeld voor extra velden op het moment dat je een node maakt. Signup voor die node is daarna pas beschikbaar, tijdens het bekijken van de node.

[kwaakvaak_v2]

Mei schreef op dinsdag 25 mei 2010 @ 13:51:
Waarom niet meehelpen aan drupal.nl? Iets met krachten bundelen enzo.

Ik weet dat ik hier mensen mee tegen het zere been schop, maar dupal.nl is een structuurloze hoeveelheid data en gelukkig heeft de community dat ook door gezien het feit dat ze een sprint organiseren maar als ik dan de punten lees die aangedragen zijn, wordt het voor mij redelijk duidelijk dat het teveel vrijheid/blijheid is en er weinig krachten te bundelen zijn imho. (geen flame overigens, eerder mijn eigenwijze vizie op dingen en het niet geloven in georganiseerde chaos zonder dat er een sturend orgaan is)

1
CCK is bedoeld voor extra velden op het moment dat je een node maakt. Signup voor die node is daarna pas beschikbaar, tijdens het bekijken van de node.

Hangt er vanaf hoe je de flow doet volgens mij, in de basis is signup toch een form waar je extra data aan mee kunt geen geven, en die data er in de post process hook van het form weer uit kunt halen en naar een eigen node weg kunt schrijven en dan eventueel later met een view weer kunt tonen?

Het is wat ingewikkeld, dat dan weer wel

Het is makkelijker om gewoon een stuk in je $variables te maken met een formuliier wat je in de node_preprocess met blocktools toevoegt als het aantal bevestigde deelnemers < 1000 is

(dat is overigens juist wel het boeiende aan Drupal, de flexibiliteit om dingen te doen.. En ook gelijk waar de stijle leercurve in gaat zitten )

[Mei]

kwaakvaak_v2 schreef op dinsdag 25 mei 2010 @ 15:14:
[...]


Ik weet dat ik hier mensen mee tegen het zere been schop, maar dupal.nl is een structuurloze hoeveelheid data en gelukkig heeft de community dat ook door gezien het feit dat ze een sprint organiseren maar als ik dan de punten lees die aangedragen zijn, wordt het voor mij redelijk duidelijk dat het teveel vrijheid/blijheid is en er weinig krachten te bundelen zijn imho. (geen flame overigens, eerder mijn eigenwijze vizie op dingen en het niet geloven in georganiseerde chaos zonder dat er een sturend orgaan is)

Je hebt deels gelijk. Stichting Drupal Nederland is nu aan het kijken of ze de ontwikkeling van drupal.nl kunnen steunen en sturen, maar ze is nog redelijk nieuw, dus dat heeft nu nog even geen prioriteit (eens andere belangrijkere zaken op orde krijgen). Jij kan echter gewoon op drupal.nl een voorzet geven voor een structuur met artikelen en mensen motiveren daar aan mee te helpen. Beide partijen profiteren ervan. Jij omdat drupal.nl reeds een bestaande site is met gebruikers, evenementen, een forum, enz. Om veel dingen hoef jij je dus niet druk te maken. De site is ook de enige officiële Nederlandse Drupalsite, dus dat helpt ook veel.

Jij bent toch van plan het werk te doen. Het enige wat je daar aan kan veranderen is waar je dat werk doet. Op een compleet nieuwe site, of een bestaande, die jou voordelen biedt.

[Peedy]

Ik heb nu een mooie View gemaakt (leuke tool is dat) en nu wil ik hem invoegen in een pagina. Dat is me wel al gelukt via

PHP:

<?
print views_embed_view($viewName);
?>

Maar dat wil ik gewoon via het admin systeem doen. Een soort van Blocks dus. Hoe werkt dat? Heb het nergens kunnen vinden. Het lijkt me wel dat het mogelijk is, waarom zou er anders een hele View tool zijn om vervolgens het laatste stukje alsnog met PHP te doen? Kinda defeats the purpose..

[Mei]

View aanmaken als block? Tijdens het maken, in de linker sidebar van de Views tool.

[Peedy]

Thanks, had die over het hoofd gezien. Dit is echt sweet, even wat CSS er over heen en m'n klant kan zelf referenties met logo's en een linkje eronder etc toevoegen Is er trouwens ook een manier om die Edit/Export/Clone linkjes te hiden, ook al ben je ingelogd? Wil het liefst zo veel mogelijk frontend en backend opties gescheiden houden. Gevonden.

[ Voor 41% gewijzigd door Peedy op 25-05-2010 20:41 ]

[Mei]

Ik denk dat Peedy nog even moet wennen aan de begrippen front end en back end in Drupal Het meeste kan je doen met permissions. Waarschijnlijk verschijnen de links die je bedoelt niet meer als je gebruikers geen rechten meer hebben om Views te beheren.

[Peedy]

Mei schreef op dinsdag 25 mei 2010 @ 21:00:
Ik denk dat Peedy nog even moet wennen aan de begrippen front end en back end in Drupal Het meeste kan je doen met permissions. Waarschijnlijk verschijnen de links die je bedoelt niet meer als je gebruikers geen rechten meer hebben om Views te beheren.

Weet ik, maar ik wil ze uberhaupt niet hebben op deze site. Hier is maar één iemand die de site gaat beheren en die leert maar hoe het Drupal admin menu werkt

Edit; ik wordt met de minuut enthousiaster over Drupal. Wat een geniaal systeem en wat een zonde dat ik er nu pas in duik. Die patches zijn ook ontzettend handig, al 2x nodig gehad

[ Voor 14% gewijzigd door Peedy op 25-05-2010 21:27 ]

[Mei]

Ik denk dat je de dagelijkse beheerde gewoon *NIET* in de buurt van Views moet laten komen, tenzij het de maker van de site is. Als dat niet zo is, dan met permissions werken.

[Peedy]

Mei schreef op dinsdag 25 mei 2010 @ 21:28:
Ik denk dat je de dagelijkse beheerde gewoon *NIET* in de buurt van Views moet laten komen, tenzij het de maker van de site is. Als dat niet zo is, dan met permissions werken.

Duidelijk, lijkt me een goede inderdaad. Nog een vraagje; ik wil een stuk HTML als dit;

code:

<div id="slider">
<img src="images/slider/plannederland.jpg" alt="" />
<img src="images/slider/smartpuls.jpg" alt="" />
</div>

als een block toevoegen, zodat ik per pagina kan aangeven of hij tevoorschijn komt of niet. Moet ik dit dan in een pagina zetten en daar een block van maken oid?

Ik wil dat de klant zelf jpg's onder elkaar kan plaatsen zodat de HTML als bovenstaand wordt, de jQuery doet de rest om er een mooie slider van te maken.

[ Voor 11% gewijzigd door Peedy op 25-05-2010 21:44 ]

[Mei]

Wat voor images zijn het precies? Wat moeten ze voorstellen? Verwijzen ze nog ergens naar? Waar komen ze vandaan?

[Peedy]

Mei schreef op dinsdag 25 mei 2010 @ 21:47:
Wat voor images zijn het precies? Wat moeten ze voorstellen? Verwijzen ze nog ergens naar? Waar komen ze vandaan?

Het zijn images die door middel van de CKEditor geupload worden. Het wordt gewoon een slider van wat gedaan werk voor een portfolio, ze worden al gecropped geupload. Ze verwijzen nergens naar. Ik heb het ook geprobeerd met de Views Gallery plugin maar dat werkt niet zo lekker.

[Mei]

Je kan op admin/build/block ook custom blocks toevoegen. Is natuurlijk wel weer jammer he, dat je zulke mooie images hebt die dan weer niet gelinkt zijn naar de portfolionodes

[Peedy]

Mei schreef op dinsdag 25 mei 2010 @ 21:53:
Je kan op admin/build/block ook custom blocks toevoegen. Is natuurlijk wel weer jammer he, dat je zulke mooie images hebt die dan weer niet gelinkt zijn naar de portfolionodes

Waar defineer je die custom blocks dan? Dat is een beetje het probleem.

Wel jammer van die nodes, maar ik heb de Gallery toegevoegd met een paar fotootjes, maar die fotootjes komen gewoon niet tevoorschijn? Kijk hier maar. In admin/build/views/edit/gallery staat wel Content: Image in de Fields list.
Wederom gevonden. In de Content:Image stond als Type 'Generic File'. Deze op Image gezet en ze komen tevoorschijn. Verder knutselen

For future reference; er zit bij de Views Gallery module dus ook verschil tussen de type Views. Heb hem nu in de sidebar ingeschakeld, dus moest nu de Gallery block onder Views aanpassen. Ik moet nog even de logica goed doorkrijgen, maar ben op weg!

Goed, volgend obstakel. Drupal maakt nogal veel div's aan. Mijn jQuery Slider plugin lust dat niet zo graag. Kan ik ergens die div's uitzetten? En kan ik ook aan bepaalde div een id meegeven zonder het te hardcoden?

Edit; ah, door de nog niet aangemaakte relevante .tpl.php files (views-view, views-view-unformatted en views-view-fields) aan te maken en aan te passen en ze dan te Rescannen Het werkt nu helemaal, super!

Goed, nu wil ik dus ' id="slider"' alleen toevoegen in de pagina's waar ook daadwerkelijk een slider in zit. Kan ik in een .tpl.php file checken of er een bepaalde block (in dit geval dus de 'gallery' block) voor de opgevraagde pagina is ingeschakeld? Ik heb het zo geprobeerd (in views-view.tpl.php) (I know, vrij ranzige oplossing);

code:

<div class="view-content"<? if(stripos($right,"imagefield-field_gallery_image")!==false) { echo " id=\"slider\""; } ?>>

Alleen hij geeft dus de variable $right niet door naar die template file...

Edit; logisch, die $right wordt natuurlijk 'geunpacked' in die template file. $right vervangen met $rows en hij doet het. Het zou alleen leuk zijn als hier een nettere oplossing voor is

[ Voor 63% gewijzigd door Peedy op 25-05-2010 22:34 ]

[Mei]

Peedy schreef op dinsdag 25 mei 2010 @ 22:00:
[...]

Waar defineer je die custom blocks dan? Dat is een beetje het probleem.

Er zit zo'n heel mooi tabje op die pagina, genaamd Add block

[Peedy]

Mei schreef op dinsdag 25 mei 2010 @ 22:38:
[...]

Er zit zo'n heel mooi tabje op die pagina, genaamd Add block

Als ik op Blocks klik krijg ik die pagina weer te zien in mijn eigen layout, en niet de admin layout. Waar pas ik dat aan?

Blijkbaar is het een bug, deze user heeft er ook last van (Gefixt in D7). Bij hem lag het aan de teleport module, maar die heb ik niet geinstalleerd. Blijkbaar wordt het veroorzaakt door hook_init() in één van mijn geinstalleerde modules. Hmmm, zoekwerkje.

Edit; ik kan de betreffende module helaas niet vinden. Er is ook geen fix voor D6 (zie hier)

[ Voor 47% gewijzigd door Peedy op 25-05-2010 22:59 ]

[Michali]

Het is normaal dat je de blocks admin page in de main theme te zien krijgt, niet in de admin theme. Je plaatst daar namelijk blokken in regions van je main theme, niet in de regions van je admin theme.

Wat lukt er precies niet dan? Wellicht geef je in je main theme nergens tabs (local tasks) weer?

[Mei]

@Peedy: Zodra je meerdere themes hebt ingeschakeld krijg je extra tabs te zien op admin/build, waar je je blocks per theme in kan stellen. Klopt dat en heb je dat inderdaad geprobeerd of was je nog niet zo ver gekomen?

[kwaakvaak_v2]

Mei schreef op dinsdag 25 mei 2010 @ 15:37:
[...]

Je hebt deels gelijk. Stichting Drupal Nederland is nu aan het kijken of ze de ontwikkeling van drupal.nl kunnen steunen en sturen, maar ze is nog redelijk nieuw, dus dat heeft nu nog even geen prioriteit (eens andere belangrijkere zaken op orde krijgen). Jij kan echter gewoon op drupal.nl een voorzet geven voor een structuur met artikelen en mensen motiveren daar aan mee te helpen. Beide partijen profiteren ervan. Jij omdat drupal.nl reeds een bestaande site is met gebruikers, evenementen, een forum, enz. Om veel dingen hoef jij je dus niet druk te maken. De site is ook de enige officiële Nederlandse Drupalsite, dus dat helpt ook veel.

Jij bent toch van plan het werk te doen. Het enige wat je daar aan kan veranderen is waar je dat werk doet. Op een compleet nieuwe site, of een bestaande, die jou voordelen biedt.

Je hebt wel een punt Alleen ik ben bang dat het teveel energie gaat kosten om mensen te overtuigen dat het anders moet/kan. niet zulke goede ervaringen met HCC gebruikersgroepen, en ik krijg bij drupal.nl beetje datzelfde smaakje in mijn mond

Plus wat je al zegt, het is de officiele NL/BE drupal site, en moet uit dat oogpunt ook ruimte bieden aan iedere drupal gebruiker. Wat een goede zaak is, maar niet aansluit bij mijn/onze ideeen.

Ik zit meer in de ontwikkelaarshoek dan de (eind)gebruikershoek en heb helemaal geen trek in artikelen over hoe iemand het beste zijn site moet indelen, maar meer in de praktische hoek zoals hoe je bijvoorbeeld een node hook kan gebruiken om eigen template suggesties te maken. Code snippets, korte howto's zoals je die ook op engelstalige sites/blogs tegenkomt. Het wordt ook meer een georganiseerde blog dan een echte handleiding zoals het nu in mijn hoofd zit Maar wel open ook voor andere mensen om inhoud te maken, maar wel met een redactieslag erover heen om een bepaalde kwaliteit te kunnen garanderen. (en ja dat klinkt arroganter dan het is )

Ik geloof heel sterk in dat de drupal kennis in Nederland te gefragmenteerd is en daar wil ik op mijn eigen eigenwijze wijze wat aan proberen te gaan doen

[Mei]

kwaakvaak_v2 schreef op woensdag 26 mei 2010 @ 13:19:
[...]


Je hebt wel een punt Alleen ik ben bang dat het teveel energie gaat kosten om mensen te overtuigen dat het anders moet/kan. niet zulke goede ervaringen met HCC gebruikersgroepen, en ik krijg bij drupal.nl beetje datzelfde smaakje in mijn mond

Valt in mijn ervaring nog wel mee. De meeste mensen zijn redelijk nuchter en de religieuze fanatici pik je er snel genoeg uit. Anders had ik het ook niet zo lang volgehouden in de community

Ik geloof heel sterk in dat de drupal kennis in Nederland te gefragmenteerd is en daar wil ik op mijn eigen eigenwijze wijze wat aan proberen te gaan doen

Door voor nog meer fragmentatie te zorgen? (geintje )

[Peedy]

Michali schreef op woensdag 26 mei 2010 @ 09:40:
Het is normaal dat je de blocks admin page in de main theme te zien krijgt, niet in de admin theme. Je plaatst daar namelijk blokken in regions van je main theme, niet in de regions van je admin theme.

Wat lukt er precies niet dan? Wellicht geef je in je main theme nergens tabs (local tasks) weer?

Mei schreef op woensdag 26 mei 2010 @ 10:47:
@Peedy: Zodra je meerdere themes hebt ingeschakeld krijg je extra tabs te zien op admin/build, waar je je blocks per theme in kan stellen. Klopt dat en heb je dat inderdaad geprobeerd of was je nog niet zo ver gekomen?

Klinkt wel logisch nu. Had inderdaad tabs niet aanstaan in die theme omdat ik voor die site back- en frontend gescheiden wil houden. Toch maar een uitzondering gemaakt voor de admin/build pagina.

[Michali]

Ik ben een analyse van Drupal aan het doen. Zit nu te kijken wat voor architecturele patronen zijn toegepast.

Er zijn nogal wat discussies over of het nu Presentation-Abstraction-Control of Model-View-Controller is wat toegepast wordt. Naar mijn mening wordt het beide gebruikt en een mix ervan.

De hiërarchie van PAC komt duidelijk terug via het themasysteem. Echter wordt binnen de templates de node (of andere abstracties) wel aangesproken, iets wat niet kenmerkend is voor PAC.

Verder denk ik dat de Form API meer op MVC leunt.
-Controller: bouwen, valideren, verwerken, redirecten.
-Model: de associatie array dat een representatie is van het weer te geven formulier.
-View: drupal_render die deze array rendert naar HTML via het themasysteem.

Om een beter beeld te krijgen heb ik daarvoor ook dit model gemaakt.

Wellicht dat jullie hier nog wat over te zeggen of te melden hebben?

[Mei]

Zie ook http://drupal.org/node/165104 en http://www.gliffy.com/pubdoc/1508856/L.png.

Daarnaast is het handig je diagram even langs wat experts in #drupal op irc.freenode.net te halen, voordat je het publiceert en er fouten in blijken te zitten.

[Michali]

Thanks, daar heb ik zeker wat aan. Deze gaan wel meer op de details in dan wat ik erin wil brengen, maar ik zie dat ik wel een en ander kan verbeteren.

Edit: ik heb het model bijgewerkt. Extra build stap voor de validate toegevoegd. Dit is overigens heel globaal. De build in dit model omvat het preparen en builden in Drupal.

[ Voor 43% gewijzigd door Michali op 27-05-2010 12:03 ]

[Cubic X]

Heeft het nog zin om Pro Drupal Development (second edition) te kopen in verband met Drupal 7? Zijn er veel wijzigingen wat betreft 6 en 7?

Ik ben namelijk begonnen met het ontwikkelen in Drupal en vindt het zo leuk dat ik me er zeker verder in wil verdiepen, ik ben nu redelijk een beginner. Ik heb al wel wat ervaring met PHP en heb ook al het een en ander aangepast in modules .

Is Pro Drupal Development een goed boek om meer te leren over Drupal? Ik wil ook nog het boek 'Drupal 6 themes' kopen om meer te leren over de styling. Of het het verstandiger om nog even te wachten op Drupal 7 en de daar bij behorende boeken?

[kwaakvaak_v2]

Pro drupal development hoort op het buro van iedere serieuze drupal ontwikkelaar thuis imho. Drupal 7 kan nog wel even gaan duren, en zelfs als het uitkomt kan het nog even duren voor de hele community bij is. Ondanks dat er behoorlijk veel module bouwers al wel klaar/bezig zijn met de conversie van hun module naar D7.

Wat je vooral niet moet kopen zijn die boeken van Pact publishing, te snel geschreven en gaan nauwelijks echt de diepte in. Ze lijken vooral gemaakt voor het snelle cashen van de uitgever. (uitzondering daar gelaten, maar hun drupal boeken zijn echt triest slecht)

[Eusebius]

Kijk, deze ervaring had ik nog niet meegemaakt met Drupal. Ik kom zelfs aan een vriendin via Dr.Org

Dear,
[e-mail],
I am Sofai 24yrs old girl from Sudan I read your profile at www.drupal.org, and find it truly interesting. That is why I am contacting you so that we can get to know each other better for personal relationship, beside I have a special issue to discuss with you on a very serious note. I can be reached through this Email:sofai_88 @ yahoo.com, Hope to hear from you soon. I will send my pictures to you and also tell you more about my self when you reply me. All I need is your understanding and interest for more information about me. Take care as I wait for your response through my private email address above bye bye for now.
Sofai.

[Michali]

Dat ziet er authentiek uit; ik zou zeggen: contact opnemen!

[Eusebius]

Ja, ze valt op mannen die met Drupal werken en of ik geld voor haar ticket wil overmaken. Ze wil graag met me trouwen ...

[kwaakvaak_v2]

Eusebius schreef op dinsdag 08 juni 2010 @ 21:49:
Ja, ze valt op mannen die met Drupal werken en of ik geld voor haar ticket wil overmaken. Ze wil graag met me trouwen ...

kinky!... ze valt dus op masochisten

[Eusebius]

Hahaha ... Oh die mag je rustig hier laten zien hoor ;-)


Iets anders: met Comment Alter kun je via de reacties de status van een CCK veld wijzigen. Maar is hier ook een snellere manier voor? Met bv een link? Ik heb namelijk een CCK veld die maar 2 waardes kent (0 en 1 ). Ik wil dat de gebruikers slechts op 1 link hoeven te klikken om de waarde van 0 naar 1 te veranderen. Voor zover ik gegoogled en gezocht heb, heb ik geen oplossing kunnen vinden.

[Michali]

Heeft iemand hier al eens gebruik gemaakt van de Context en Features modules? Erg interessant moet ik zeggen.

[MsG]

Is er ook een website of iets waar je kant en klare drupal scenario's kan downloaden om van te leren? Een soort werkende dummypakketten van bijvoorbeeld fictieve bedrijven. Ik heb namelijk vaak het idee dat ik dingen verkeerd gebruik in Drupal en mogelijk daarom nog niet zo overtuigd ben van het pakket.

[ Voor 9% gewijzigd door MsG op 16-06-2010 16:39 ]

[Mei]

Zoeken naar "install profiles". Moeten er op drupal.org ook wel wat staan. Geen ervaring mee (behalve met de profiles in Drupal 7), omdat ik ze als developer/organisator niet nodig heb.

[Eusebius]

Hey mensen, hierbij een schema van een ontwerp voor een site waar ik mee bezig ben. Waar ik niet uitkom is onderstaand schema:


Tijdens mijn zoektocht naar geschikte modules kom ik leuke pareltjes tegen als http://drupal.org/project/nodeaccess_userreference.

Waar ik tegenaan loop, zijn de volgende knelpunten: er zijn meerdere lokaties mogelijk. Ik wil dus een aparte nodetype maken met lokaties. Met nodereference oid kan er naar verwezen worden. Een user kan aan meerdere lokaties worden gekoppeld (lees: is verantwoordelijk voor meerdere plaatsen). Dus user/3 is gekoppeld aan lokatie-1, lokatie-96 en lokatie-111. Hoe zet ik de boel zo in elkaar, dat als user/2 lokatie-111 kiest, user/3 automatisch toestemming krijgt (dus zonder dat user/2 nog user/3 moet selecteren).

Ik dacht om in de userprofiel een nodereference naar de lokatie in te bouwen. Echter, het staat vantevoren niet vast hoeveel lokaties 1 user mag beheren. Dus dan zou bij het aanmaken van lokatie-111 de user/3 moeten selecteren via bv nodereference. Er hoeft per lokatie slechts 1 gebruiker geselecteerd te worden. Maar hoe krijg je voor elkaar dat user/3 automatisch toestemming krijgt om het event te bewerken?

[Michali]

Je kunt daarvoor een eigen access module schrijven. Via hook_access kun je dan zelf regelen wanneer het wel en niet mag.

[Eusebius]

Michali schreef op woensdag 16 juni 2010 @ 21:43:
Je kunt daarvoor een eigen access module schrijven. Via hook_access kun je dan zelf regelen wanneer het wel en niet mag.

Mwaahh zo goed ben ik niet in modules schrijven .. sterker nog, het zou mijn eerste worden Ja, ik ben nooit te oud om te leren natuurlijk maar dat gaat hem nu echt even niet worden.

[Michali]

Ik dacht dat dat geen probleem zou zijn, aangezien dit topic onder programmeren staat. Maar goed ik heb ook net een scriptie over Drupal achter de rug, dus wellicht denk ik er dan wat makkelijk over.

Het is overigens wel een stuk eenvoudiger dan je zou denken. Het is de moeite imo. wel waard om er eens wat tijd in te steken.

[ Voor 24% gewijzigd door Michali op 16-06-2010 22:25 ]

[Eusebius]

Ik ben net met een totaal andere scriptie bezig, vandaar. Mijn tijd gaat naar mijn afstuderen. Als ik al iets wil leren, staat Drush hoog op mn lijstje. Dan kan ik al mn sites zo beheren.

Onder de douche bedacht ik net dat t misschien ook wel met OG kan. Dat lost nog een paar extra drempels op, ook.

Even een korte uitleg: per lokatie maak ik n OG aan. Daarin kun je een nodetype "event" plaatsen. Dat moet gedaan worden door users als user/2 (heeft een andere rol dan user/3).
User/2 kan middels een View zijn eigen events zien.

[ Voor 27% gewijzigd door Eusebius op 16-06-2010 23:10 ]

[Michali]

Je zou ook hier eens naar kunnen kijken:

http://drupal.org/project/nodeaccess_autoreference

Er zijn zo nog wel wat modules beschikbaar, zoals deze:

http://drupal.org/project/nodeaccess_userreference
http://drupal.org/project/nodeaccess_nodereference
http://drupal.org/project/coherent_access

[Eusebius]

Ja precies, die had ik ook allemaal gevonden. In mijn ontwerp wordt de toegang bepaald door 2 stappen: het bijbehorende profiel van een lokatie moet ook toegang krijgen tot de eventnode. Dus: node/1 -- gekoppeld aan -- node/2 --- behoort bij user/3. Dan heb je het over 2 stappen in plaats van 1, en dat ben ik nog niet tegengekomen.

Daarom mijn oplossing om het via OG te regelen en de lokatie ipv event als spil te maken.

[Michali]

Hmmm, maar bij die auto reference staat wel dit:

It's scanning automatically for references with unlimited deep path

Ik heb het zelf nooit uitgeprobeerd.

[Eusebius]

Mmm interessant genoeg om eens naar te kijken! Bedankt, want ik had deze module wel gezien maar de "unlimited deep path" was me nog niet opgevallen.

En dan nu iets anders

Je kunt deze module als zandbak gebruiken: http://drupal.org/project/demo. Zelf gebruik ik altijd de Backup&Migrate (ik zet handmatig een oude backup terug). Misschien is dit een kwestie van 2 wegen die beide op een andere manier naar Rome leiden. Maar heeft iemand ervaring met demo en waarin is deze anders / beter dan de Backupmodule?

[Rekcor]

Nu we toch van de hak op de tak springen: kan ik er in mijn Javascript vanuit gaan dat iedere Drupal-pagina

HTML:

<div id="main"> 

...

</div>

bevat? Dat zou zaken een stuk gemakkelijker maken :-)

[kwaakvaak_v2]

Rekcor schreef op maandag 21 juni 2010 @ 09:17:
Nu we toch van de hak op de tak springen: kan ik er in mijn Javascript vanuit gaan dat iedere Drupal-pagina

HTML:

<div id="main"> 

...

</div>

bevat? Dat zou zaken een stuk gemakkelijker maken :-)

Dat hangt er toch echt vanaf hoe jij je template's maakt. Die voert uit wat jij vind dat er uitgevoerd moet worden

[Michali]

Nee daar kun je niet vanuit gaan. Het toegepaste thema en templates bepalen dit namelijk.

[Eusebius]

Momenteel zoek ik uit hoe je nodes over verschillende sites kunt laten delen.
- RSS is te weinig, daar op de "hoofdsite" de content (een aantal CCKvelden) nog kunnen veranderen.
- De module Nodeshare doet volgens mij precies wat ik wil http://drupal.org/project/nodeshare, alleen is deze nog in versie 5 Is het moeilijk deze te upgraden cq. wat zou iemand hiervoor vragen?
- andere modules heb ik nog niet gevonden. Het gaat om 1 contenttype, de andere moeten site-specifiek blijven. Dus het sharen van een DBtabel gaat ook al niet.

Zelfs iframe zou een oplossing kunnen zijn ...

[NaliXL]

Het wordt geloof ik tijd dat ik ook maar eens een vraag introduceer in dit topic. Ik ben bezig een web-to-print systeem te maken, en het is de bedoeling dat dat uiteindelijk in onze Drupal site geïntegreerd gaat worden. Ik ben begonnen met het maken van een PHP class die eigenlijk alle benodigde

basisfunctionaliteit biedt.

Mijn bedoeling is om een soort Wizard te creëren, met de volgende stappen:

1. Presenteer de gebruiker met een lijst met productcathegorieën. Deze kan worden opgevraagd met een functie van mijn web-to-print class.
2. Presenteer een lijst met productvoorbeelden en omschrijvingen binnen de in stap 1 gekozen cathegorie, waaruit de gebruiker kan kiezen. Deze
   
   productvoorbeelden worden ook weer dynamisch gegenereerd met behulp van mijn web-to-print class. Bovendien is het mogelijk dat het er best veel worden,
   
   en dat er dus meerdere pagina's aan keuzemogelijkheden moeten komen.
3. Pas de template van het in stap 2 gekozen product aan. Dit kan met behulp van textvelden en uploadvelden voor afbeeldingen. Welke velden er zijn die
   
   gewijzigd kunnen worden kan worden opgevraagd via mijn class.

Dat zijn de basis-stappen, en het liefst zou ik dat zo goed mogelijk met Drupal integreren, maar op dat laatste gebied schiet mijn kennis danig te

kort. Ik heb de volgende methoden opgezocht, en de voordelen, nadelen en mijn twijfels daarbij op een rijtje gezet:

• Mijn code slechts aanroepen vanuit Drupal en daarmee het grootste deel van Drupal passeren, door een nieuwe page aan te maken, PHP code te enablen en op die manier mijn code aan te roepen. Hoewel ik hier het meeste kennis van zaken heb, is het veruit de minst elegante hack naar mijn smaak, en waarschijnlijk meer werk dan nodig is. Bovendien lijkt het me wel erg mooi achteraf de details van de gedane bestelling op een mooie overzichtspagina te kunnen bekijken, iets waar Drupal goed in is bij mijn weten...
• Een module schrijven. Maar om eerlijk te zijn duizelt het me voor de ogen als ik de diverse tutorials lees. Kan ik dan het beste een module maken die een nieuw content-type genereert, of zijn daar andere/betere opties voor? Kan ik CCK-velden gebruiken (een node(pagina) met een bestellingsoverzicht van de gedane bestelling lijkt me wel mooi!)? Of is Webform een geschikte kandidaat? Hoe kan ik de meerdere stappen- en
  
  keuzepagina's aan elkaar koppelen (is schijnbaar lastig te implementeren met Drupal Forms / CCK)?
• Andere mogelijkheden hoor ik graag...!!

Kortom, heel graag hoor ik hoe jullie dit zouden aanpakken. Ik wil graag een iets geïnformeerder beslissing nemen, maar de documentatie duizelt me werkelijk voor de ogen.

[Mei]

Een module schrijven is meestal de beste oplossing, omdat je dan reusable code hebt die volgens bestaande standaarden gemaakt is.

De grote vraag is: wat wil je *precies* omzetten? Ik lees iets over bestellingen en nodes, maar echt een concreet beeld van de situatie wordt er niet geschetst. De implementatie hangt volledig af van welke data je wil gebruiken, waar deze vandaan komt, hoe dit hergebruikt moet worden, etc.

[Eusebius]

Huh? Als je bij bv Full HTML een rol weghaald, dan kan deze rol opeens geen enkele node meer die hij gemaakt heeft editten. Dat heeft me de hele avond gekost om dat uit te zoeken! Iemand een idee waarom dat is? Als je opeens geen Full HTML meer mag gebruiken op een node, dan kan het systeem toch terugschakelen op een ander invoerformaat?

[kwaakvaak_v2]

Eusebius schreef op vrijdag 25 juni 2010 @ 00:12:
Huh? Als je bij bv Full HTML een rol weghaald, dan kan deze rol opeens geen enkele node meer die hij gemaakt heeft editten. Dat heeft me de hele avond gekost om dat uit te zoeken! Iemand een idee waarom dat is? Als je opeens geen Full HTML meer mag gebruiken op een node, dan kan het systeem toch terugschakelen op een ander invoerformaat?

Nope.. want een node heeft een maar 1 input formaat, er is geen fallback...

[Eusebius]

kwaakvaak_v2 schreef op vrijdag 25 juni 2010 @ 08:46:
[...]


Nope.. want een node heeft een maar 1 input formaat, er is geen fallback...

Ik snap dat het systeem zo gebouwd is. Maar het zou wat sjieker kunnen:

- user/2 maakt node/20 met Full HTML
- user/1 verandert de rolrechten v/h invoerformaat
- user/2 kan nu node/20 niet meer met Full HTML bewerken
# Wat gebeurt er nu
- error, geen toegang tot de pagina
# Wat netter zou zijn
- node opent / converteert (?) met ander invoerformaat.
- user krijgt netjes melding dat het invoerformaat niet meer klopt en er derhalve eea niet meer goed werkt.

[Mei]

Eusebius schreef op vrijdag 25 juni 2010 @ 17:32:
[...]

Ik snap dat het systeem zo gebouwd is. Maar het zou wat sjieker kunnen:

- user/2 maakt node/20 met Full HTML
- user/1 verandert de rolrechten v/h invoerformaat
- user/2 kan nu node/20 niet meer met Full HTML bewerken
# Wat gebeurt er nu
- error, geen toegang tot de pagina
# Wat netter zou zijn
- node opent / converteert (?) met ander invoerformaat.
- user krijgt netjes melding dat het invoerformaat niet meer klopt en er derhalve eea niet meer goed werkt.

Dan kunnen users onbedoeld content niet meer kunnen laten werken, wat je op een live site ook liever niet wil.

[Eusebius]

Mei schreef op vrijdag 25 juni 2010 @ 19:31:
[...]

Dan kunnen users onbedoeld content niet meer kunnen laten werken, wat je op een live site ook liever niet wil.

En nu had ik op een live site dat een user helemaal niets meer kon editten. Tja dat wil ik ook niet :-| Site was nog niet helemaal live (wel toegankelijk, URL nog niet goed), dus dat scheelde. Drupal heeft een intern waarschuwingssysteem waar dit heel goed aan gekoppeld zou kunnen worden.

[kwaakvaak_v2]

en wie houd je tegen om dat te bouwen dan Als je het netjes kunt bouwen zonder aan de core te komen in een module Dat is immers het idee van drupal


Maar wat. voor fallback wil je dan? want stel dat ik een input type heb gedefinieerd met beperkte html, wat ik voor klanten best vaak doe, en die haal ik weg, dan wil ik niet dat iemand ineens full html krijgt. Ik had immers niet voor niets die klant een geforceerd filter gegeven zodat ie mooi geen content in comic sans kon zetten tussen blink tags

[ Voor 53% gewijzigd door kwaakvaak_v2 op 27-06-2010 07:46 ]

[Bozozo]

Ongeveer een week geleden is mijn website in een spammersbestand terecht gekomen. Tienduizenden comments over viagra

Voortaan maar meteen de Spam en Captcha modules installeren

[Ook al Bezet]

Bozozo schreef op zondag 27 juni 2010 @ 11:37:
Ongeveer een week geleden is mijn website in een spammersbestand terecht gekomen. Tienduizenden comments over viagra

Voortaan maar meteen de Spam en Captcha modules installeren

Mollom is een hele effectieve module om spam buiten de poorten te houden.
(enige nadeel is dat het een betaalde dienst is als je site veel (meer dan 100 per dag) comments/registraties te verwerken krijgt)

[ Voor 15% gewijzigd door Ook al Bezet op 27-06-2010 12:31 ]

[Eusebius]

Ook al Bezet schreef op zondag 27 juni 2010 @ 12:30:
[...]

Mollom is een hele effectieve module om spam buiten de poorten te houden.
(enige nadeel is dat het een betaalde dienst is als je site veel (meer dan 100 per dag) comments/registraties te verwerken krijgt)

Daar heb ik op 1 site ook last van. Captcha (mathvraag) wordt heerlijk omzeild. Helaas werkt de tekstcaptcha nog niet voor Dr6, dan had ik een vraag kunnen stellen als "hoe heet Donald Duck van zijn achternaam?"

[Bozozo]

Heb je de reCaptcha module geprobeerd? Die doet het bij mijn site (dr6) prima.

[Eusebius]

Wie is er eigenlijk verantwoordelijk voor Drupal.be? Die site ligt er vandaag uit en ik heb niets gelezen over onderhoud!

[Michali]

Ik heb de Chat Room module nodig voor een project, maar ik merkte dat er een serieuze bug in zat. Zelf opgelost en vandaar mijn eerste patch ingediend.

Je moet ook je steentje bijdragen, toch?

[Menesis]

Ik kom er niet uit: ik wil een fotogallery bouwen die alleen toegankelijk is voor 1 of 2 users.
Het lijkt wel of alle access control modules alleen uitgaan van verschillende user-roles, ipv individuele users...
Iemand tips?

[Ook al Bezet]

Een rol maken die toegang heeft tot de twee galleriën en alleen de mensen die er in mogen die rol geven.

[lordsnow]

Een deel van onze site geeft een overzicht van o.a. kroegen in verschillende steden, met info over elk.

In de nieuwe versie van de site willen wij ook de lokatie, als lattitude en longitude, gaan toevoegen aan de gegevens van een kroeg, zodat de websitebezoekers op een Google Maps venstertje kunnen zien waar een kroeg precies is.

De gegevens zullen voornamelijk ingevoerd / aangevult gaan worden door een groep vrijwilligers (forum mods). Nu kan je natuurlijk handmatig de lat en long gaan opzoeken via een site als http://itouchmap.com/latlong.html. Maar dat is wellicht net wat te omslagtig, en ik zie het al gebeuren dat mods willekeurige lats en longs gaan invullen om verder te kunnen met het invoerformulier.

Graag tips hoe je op een redelijk makkelijke manier voor een lokatie de lattitude en longitude op kan geven of selecteren. Wij zaten te denken aan het weergeven van een Google Map venster met daarin weergegeven het gebied van de eerder opgegeven postcode - nu zou je verder kunnen zoomen, en uiteindelijk de betreffende lokatie kunnen aanklikken. Maar hoe dit te realiseren? Of zijn er nog betere alternatieven?

[ Voor 146% gewijzigd door lordsnow op 12-07-2010 13:45 ]

[Verwijderd]

Na (voor de zoveelste keer, ik ben duidelijk geen ezel) in de onmogelijkheden, idioterie en ronduit bezopen architectuur van Joomla te zijn vastgelopen heb ik de stoute schoenen aangetrokken en ben Drupal gaan verkennen.

Eerste indruk: Wat een verademing!!
Met het gebruik van views, een aantal custom CCK velden, een zooitje tweaks in het Garland theme (grootste uitdaging: de "Garland" header met een groter logo en bepalen welke kleuren te gebruiken in style.css ....) en ik heb de site bijna af.

Nu ben ik nu op een punt waar het toch een beetje vastloopt. Mijn site zal enkel anonieme gebruikers kennen, enkele "beheerders" worden in een rol gestopt. De anonieme gebruikers moeten een form in kunnen vullen waarvan de beheerders, eventueel via e-mail, op de hoogte worden gesteld. Die form moet verder private blijven, zelfs de verzender hoeft 'm niet meer terug te zien.

Dit is te realiseren, maak een nieuw content type met CCK velden, geef anonieme gebruikers de rechten om zo'n content type in te vullen en gebruik de "rules" module om een "bedankt" pagina te tonen en e-mails te versturen. De ingevulde content hoeft niet eens gepubliceerd te worden en kan zelfs met een rule verwijderd worden. Toppie! Maar .... ik wil een datepicker in de form en ik wil clientside een eerste input controle doen. Daarvoor heb ik nog niet eens echt Ajax nodig maar die module lijkt voor de hand te liggen.

En dan komt het probleem ... De Ajax module herschrijft de php code van de form waardoor rules niet meer werken, verder ontbeert deze module enige mogelijkheid (zonder zelf een module te maken) om clientside controles uit te voeren. Dan maar wat anders geprobeerd; webforms ... die lijkt echter geen enkele Ajax/Javascript te ondersteunen. Versie 7, alpha 6 (alleen al omdat het nog alpha is niet geschikt voor productie zou ik zeggen, maar laten we het eens proberen) ... geen Datepicker (vanwege iets dat lijkt op een discussie over verantwoordelijkheden). Formbuilder, ook in alfa status en niet in staat een form te builden (de demo ziet er aardig uit maar probeer het niet te gebruiken).

Met andere woorden, ik zit vast. Het lijkt er op dat ik toch zelf een module zal moeten schrijven of in ieder geval bestaande modules moet gaan patchen.

Dan maak ik een account aan op Drupal.org om mijn gevonden bugs te kunnen ventileren/aanmelden/whatever en dan openbaart zich opnieuw een probleem;
Sinds mijn aanmelding is de site ineens rete-traag, acht van de tien paginas worden niet ineens geladen maar pas na ettelijke reloads ... Dat dit niet aan mijn einde van het internet (of het internet in het algemeen) lag werd pijnlijk duidelijk nadat ik uitlogde ... ineens werkt drupal.org weer naar behoren! Eenmaal ingelogd is de site onwerkbaar traag

Ik weet het op het moment even niet meer, het idee achter, of de opzet van, drupal krijgt van mij een 10+ met een griffel. De uitwerking is minder, bestaande modules conflicteren met elkaar. Oplossingen worden geboden maar enkel in versie 7 die nog alpha status heeft. Bugfixen van versie zes lijkt een veel lagere prio te hebben dan ontwikkeling van versie 7. Tenslotte is het maar de vraag hoe schaalbaar het systeem is gezien mijn ervaringen na inloggen?

Ik denk wel bij Drupal te blijven, hoe ik mijn forms goed ga krijgen weet ik nog niet ... ik hoop dat ze versie 7 snel klaar hebben ... Als iemand een suggestie heeft hoor ik het graag!

[Ook al Bezet]

Verwijderd schreef op zaterdag 07 augustus 2010 @ 02:20: Tenslotte is het maar de vraag hoe schaalbaar het systeem is gezien mijn ervaringen na inloggen?

Met je probleem kan ik je helaas niet helpen maar ik denk dat die traagheid of aan jouw kant zit of een gevolg was van tijdelijke problemen met hun server, ik heb er in elk geval geen last van.

[kwaakvaak_v2]

vergeet die hele aanpak met cck enzo, en ga voor webforms. Die is volgens mij precies gemaakt voor wat jij zoekt.

[bartvb]

lordsnow schreef op zaterdag 10 juli 2010 @ 22:51:

Graag tips hoe je op een redelijk makkelijke manier voor een lokatie de lattitude en longitude op kan geven of selecteren.

Hiervoor heb je de location module. Deze zet een adres/postcode om in coordinaten, bijvoorbeeld via de Google Maps API. Als je ook de gmap module installeert dan kan je de kroegen ook op een kaartje toveren.

[Verwijderd]

Ook al Bezet schreef op zaterdag 07 augustus 2010 @ 09:38:
[...]

Met je probleem kan ik je helaas niet helpen maar ik denk dat die traagheid of aan jouw kant zit of een gevolg was van tijdelijke problemen met hun server, ik heb er in elk geval geen last van.

Als het aan mijn kant zit zou ik verwachten dat andere sites ook traag zijn, dat zijn ze niet. Pas nadat ik inlog op de Drupal.org site word deze langzaam, log ik weer uit dan is 'ie weer snel. Ik ervaar het probleem nog steeds, ook op een ander systeem (wel beiden linux).

@kwaakvaak_v2:
Ik heb webforms geprobeerd, het datum veld en de bijbehorende datepicker werkten voor mij niet (chrome op linux), ik kon wel een date picken maar de select boxen werden niet geupdate.Ik probeer nu opnieuw webforms maar dan via eigen javascript een datepicker aan een textbox te hangen.

[Mei]

Verwijderd schreef op maandag 09 augustus 2010 @ 17:20:
[...]


Als het aan mijn kant zit zou ik verwachten dat andere sites ook traag zijn, dat zijn ze niet. Pas nadat ik inlog op de Drupal.org site word deze langzaam, log ik weer uit dan is 'ie weer snel. Ik ervaar het probleem nog steeds, ook op een ander systeem (wel beiden linux).

@kwaakvaak_v2:
Ik heb webforms geprobeerd, het datum veld en de bijbehorende datepicker werkten voor mij niet (chrome op linux), ik kon wel een date picken maar de select boxen werden niet geupdate.Ik probeer nu opnieuw webforms maar dan via eigen javascript een datepicker aan een textbox te hangen.

Drupal is erg schaalbaar en wordt met Drupal 7 nog veel schaalbaarder ook. Drupal.org gebruikt page caching. Dit betekent dat complete pagina's voor anonieme bezoekers gecachet worden. Dit geeft een enorme performancewinst, behalve als je dus ingelogd bent. Op Drupal.org ligt dit aan wat verouderde architectuur (er wordt momenteel aan een nieuwe versie van de site gewerkt), plus gebrek aan resources voor hardware die alle requests aan kan.

Welke modules conflicteren volgens jou?