[Ervaringen] Het grote Drupal-topic

[Anoniem: 228838]

Mei schreef op maandag 09 augustus 2010 @ 17:31:
[...]

Drupal is erg schaalbaar en wordt met Drupal 7 nog veel schaalbaarder ook.

Wat mijn site betreft maak ik me niet zo'n zorgen om de schaalbaarheid, ik verwacht daar geen enorme toeloop van bezoekers en ik zou ook niet weten waarom die in de toekomst wel zou komen.

V7 ziet er fantastisch uit en ik zou het ook graag gebruiken, maar die alpha status ...

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.

Ok, dat lijkt me een plausibele verklaring. Dan ga ik me wel meteen afvragen, wat voor hardware wordt er gebruikt, hoeveel hits krijgt de site per dag en hoe word de workload verdeeld?

Welke modules conflicteren volgens jou?

De Rules en de Ajax modules conflicteren. Als je Ajax gebruikt worden je form submit rules niet meer uitgevoerd.

[kwaakvaak_v2]

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


@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.

Installeer je de jquery ui module, die vervangt de standaard drupal datepicker voor de versie uit jquery, en die doet het voor zover ik weet zo'n beetje overal.

En schaalbaarheid, dat zit op zichzelf wel snor, mits je eigen infrastructuur ook een beetje okay is. Zelf gebruik ik eigenlijk alleen nog maar de pressflow release van drupal6 voor mijn projecten. Niet dat die zo groot zijn, maar het gevoel dat in ieder geval alle legacy php4 code eruit is, en de 'overhead' voor support van allerlei databases waardoor er bepaalde snelheids binnenbochten genomen kunnen worden. En ook best belangrijk uit de doos support voor varnish

Oh en mijn LAMP stack gaat binnenkort omgeruild worden voor een nginx+php+mysql+mongo+memcached stack... Puur omdat het gewoon echt serieus veel beter performed Toch best fijn eigen VPS'en waar je dingen op kunt doen zoals je dat zelf wilt


Maar eerst het twig for drupal project maar eens afronden, eindelijk verlost van die smerige lappen PHP code in tpl.php files en gewoon een wat nettere scheiding tussen vormgeving en techniek

[Anoniem: 228838]

kwaakvaak_v2 schreef op maandag 09 augustus 2010 @ 21:33:
[...]
Installeer je de jquery ui module, die vervangt de standaard drupal datepicker voor de versie uit jquery, en die doet het voor zover ik weet zo'n beetje overal.

Op dit moment heb ik jquery datepicker werkend, ik weet eerlijk gezegd niet waarom die het bij mijn vorige test niet deed. Inmiddels heb ik echter zoveel module (de)installs en patches achter de rug dat ik mijn huidige install niet zonder meer kan reproduceren ...

Ik ben redelijk tevreden met wat ik nu heb, er zijn nog wat losse eindjes die toegevoegd moeten worden en enkele puntjes die mij een doorn in het oog zijn maar die de gemiddelde gebruiker hoogstwaarschijnlijk niet eens op zullen vallen ... Ik ga proberen mijn huidige setup te reproduceren (fresh install en alleen benodigde modules en patches) en de losse eindjes aanvullen. Als dat werkt gaat de site live en ga ik me concentreren op v7.

[MsG]

Is het mogelijk om voor de gebruiker de zichtbaarheid van node-details bij het bewerken van een node te minimaliseren?

Invoerformaat
Revisie-informatie
Auteursinformatie
Publicatie-opties


Zijn allemaal niet relevant voor de gebruiker maar wel zeer verwarrend.


Ik heb het idee dat bij Drupal helaas de developer vooraan staat, terwijl het uiteindelijke doel een beetje wordt vergeten. Uiteindelijk moeten er human beings mee werken, geen techneuten / programmeurs. Voor hen vind ik Joomla! toegankelijker. Dat zou toch anders moeten zijn in een systeem welke qua basis een betere opzet heeft?

[kwaakvaak_v2]

MsG schreef op donderdag 02 september 2010 @ 13:13:
Is het mogelijk om voor de gebruiker de zichtbaarheid van node-details bij het bewerken van een node te minimaliseren?

Invoerformaat
Revisie-informatie
Auteursinformatie
Publicatie-opties

ja dat kan... Makkelijkste is gewoon het even zelf doen, form_alter hook dingen uit zetten, en er zal vast ook wel een module zijn waar het mee kan

code:

function MYMODULE_form_alter(&$form, $form_state, $form_id)
{
  global $user; // Bring $user object into scope if displaying shall depend on userid or role
  #if ( $user->uid != 1 ) // 0 -> Anonymous, 1 -> SuperAdmin, 2+ -> Authenticated users
  if ( !in_array('USER ROLE NAME', $user->roles) ) // Check for role (using role name)
  {
    // add class 'hideme' to elements which shall be hidden
    $form['revision_information']['#attributes'] = array('class' => 'hideme'); // Revision information
    $form['author']['#attributes'] = array('class' => 'hideme'); // Author information
    $form['options']['#attributes'] = array('class' => 'hideme'); // Publishing options
    $form['xmlsitemap']['#attributes'] = array('class' => 'hideme'); // XML sitemap
    $form['print']['#attributes'] = array('class' => 'hideme'); // Printer, e-mail and PDF versions
    $form['path']['#attributes'] = array('class' => 'hideme'); // URL path settings
    $form['menu']['#attributes'] = array('class' => 'hideme'); // Menu settings
    // Don't forget to add this class to your template CSS file:
    // .hideme { display: none; }
  }

Snippet komt overigens gewoon van drupal.org, waar dit ook uitgebreid besproken wordt

[MsG]

En er is niet gewoon een user friendly manier om dit uit te zetten ipv een CSS display: none workaround?

jammer.

[kwaakvaak_v2]

Uuh die is er vast ook, maar dingen uitzetten met CSS is gewoon bad practice. Zet het dan echt uit ipv te verstoppen voor een gebruiken. Wat nu als die gebruiker een screen reader gebruikt? Mooi dat jouw display:none dingen wel voorgelezen worden.


^{En hoeveel moeite is het om even zelf een module te maken en die aan je eigen code bibliotheek toe te voegen? Of komt je moeder ook nog s'ochtends je schoenen strikken, brooddoosje mee en met een aai over je bol achterop de fiets naar je school/werk brengen?}

[MsG]

Het gaat mij er om dat het een workaround is. iedereen is lyrisch over Drupal maar ik vind het voor de eindgebruiker nog echt totaal niet goed werken. Vervolgens moet je je alsnog in diverse workarounds steken. Het hele idee van een CMS is dat je niet alles meer handmatig hoeft te doen met code, maar dat iets gewoon instelbaar is. Niet dat ik voor de meest standaardscenario's al een module moet gaan schrijven. Maar goed, technische mensen missen vaak de eigenschap om dingen te zien als "domme" eindgebruiker die domweg een verhaaltje wil typen. En dat is imo jammer. Ik vind drupal verder best redelijk werken, maar het schiet een beetje zijn doel mis vind ik. Ik kijk dan ook uit naar 7 en hoop dat dingen dan wat meer voor aardlingen zijn bedoeld.

[kwaakvaak_v2]

Je misvatting zit hem er in dat je drupal een CMS noemt, en daardoor zijn doel voorbij schiet. Want dat is het in principe wel en ook weer niet in de zin dat het net zo'n systeem als wordpress/joomla., Zelf vertel ik mijn klanten meestal dat het meer een Content Management Platform is, want dat dekt de lading al een stuk meer en het vereist gewoon wat meer werk van een ontwikkelaar om het klaar te zetten voor een gebruiker. En net als bij ieder ander systeem is het overigens wel bad practice om een gebruiker als "Administrator' user in te laten loggen, maar is het verstandiger om gewoon een rol aan te maken waarin jij als ontwikkelaar/administrator bepaald wat wel en niet gedaan mag/kan worden.

Drupal 7 gaat wel wat veranderen, maar het basis principe dat het geen installeer, klik links, klik rechts en weer een site klaar systeem is, gaat zeker niet veranderen.

Wat je overigens prima al kunt zien als je een nightly uit CVS trekt en installeert .Zoveel gaat er niet meer wijzigen aan de final qua looks en werkwijze in D7

[Peedy]

MsG schreef op donderdag 02 september 2010 @ 13:13:
Is het mogelijk om voor de gebruiker de zichtbaarheid van node-details bij het bewerken van een node te minimaliseren?

Invoerformaat
Revisie-informatie
Auteursinformatie
Publicatie-opties


Zijn allemaal niet relevant voor de gebruiker maar wel zeer verwarrend.


Ik heb het idee dat bij Drupal helaas de developer vooraan staat, terwijl het uiteindelijke doel een beetje wordt vergeten. Uiteindelijk moeten er human beings mee werken, geen techneuten / programmeurs. Voor hen vind ik Joomla! toegankelijker. Dat zou toch anders moeten zijn in een systeem welke qua basis een betere opzet heeft?

Daar hebben we een hele mooie module voor; FormFilter. Overigens, je verhaal over 'aardlingen'; als jij Drupal niet zo kan instellen dat je eindgebruiker niets van die overkill merkt dan zou ik maar even nog wat dieper in de Drupal materie springen. Je bent tenslotte developer, toch? Ik heb al een hele rits Drupal sites gemaakt en de eindgebruikers klagen nooit. Overbodige dingen hiden/weghalen en de permissions goed instellen en you're good to go.

@kwaakvaak_v2; perceptie is hierin ook een belangrijk punt. Ik vind Drupal zelf heel erg een "klik hier, klik daar en klaar ben je" systeem. Dingen die ik eerder zelf hardcoded moest schrijven klik ik nu dmv CCK en Views in elkaar. Ik programmeer zo'n 80% minder regels sinds ik Drupal gebruik ipv een ander CMS (custom danwel off-the-shelf).

[Voor 31% gewijzigd door Peedy op 02-09-2010 14:58]

[MsG]

kwaakvaak_v2 schreef op donderdag 02 september 2010 @ 14:48:
Je misvatting zit hem er in dat je drupal een CMS noemt, en daardoor zijn doel voorbij schiet. Want dat is het in principe wel en ook weer niet in de zin dat het net zo'n systeem als wordpress/joomla., Zelf vertel ik mijn klanten meestal dat het meer een Content Management Platform is, want dat dekt de lading al een stuk meer en het vereist gewoon wat meer werk van een ontwikkelaar om het klaar te zetten voor een gebruiker. En net als bij ieder ander systeem is het overigens wel bad practice om een gebruiker als "Administrator' user in te laten loggen, maar is het verstandiger om gewoon een rol aan te maken waarin jij als ontwikkelaar/administrator bepaald wat wel en niet gedaan mag/kan worden.

Drupal 7 gaat wel wat veranderen, maar het basis principe dat het geen installeer, klik links, klik rechts en weer een site klaar systeem is, gaat zeker niet veranderen.

Wat je overigens prima al kunt zien als je een nightly uit CVS trekt en installeert .Zoveel gaat er niet meer wijzigen aan de final qua looks en werkwijze in D7

Ik heb mijn klanten ook wel een apart account gegeven, met al minimale functies. Maar een paar dingen moeten ze toch kunnen. Dat het een platform of framework is vind ik een beetje een non-discussie, dat moet toch geen verschil maken voor de eindgebruiker? Prima dat het veel kan, maar waarom kan het voor de eindgebruiker niet makkelijk zonder je in allerlei bochten te wringen. Kijk eens naar wordpress als eindgebruiker om een pagina te maken / bewerken, daar is echt bij stil gestaan dat hoe mooi diepgaand het framework ook moet zijn, hoe veel features en hoeveel programmeurgeile dingen er ook inkomen: uiteindelijk zal er een normaal persoon, zonder diepgaande kennis van computers er content in kunnen typen. Ik moet de eerste Drupal website nog zien met een goede noobfriendly plain simple content edit systeem. Wat ik zie zijn halfvertaalde interfaces met onlogische opties. Drupal 7 doet het qua interface iig al een stuk beter, al is het wel een stuk zwaarder door al die javascripthipheid.

[Voor 7% gewijzigd door MsG op 02-09-2010 15:00]

[kwaakvaak_v2]

MsG schreef op donderdag 02 september 2010 @ 14:58:
[...]


Ik heb mijn klanten ook wel een apart account gegeven, met al minimale functies. Maar een paar dingen moeten ze toch kunnen. Dat het een platform of framework is vind ik een beetje een non-discussie, dat moet toch geen verschil maken voor de eindgebruiker?

Het is wel een discussie, jij hebt een andere verwachting bij drupal, en dat is prima maar je vergelijkt hier nu peren met appels en dat is geen eerlijk vergelijk in deze. Drupal 6 of 7 vereist gewoon wat meer werk van jouw als implementatie deskundige, maar drupal heeft een andere primaire doelgroep, mensen die een krachtig systeem willen en bereid zijn daar wat tijd in te stoppen. Wordpress heeft als doelgroep eindgebruikers die snel een blog op willen zetten. Logisch dat je in dat laatste gewoon een aantal harde binnenbochten kan nemen. Je hoeft immers nooit rekening er mee te houden dat er iemand een ander admin gedeelte maakt dan wat er standaard in zit. Drupal is daar flexibiler in, maar die flexibiliteit komt met de prijs dat het gewoon meer moeite kost om het op te zetten. Maar juist daarvoor zijn er modules en themes uitgevonden.

Als ik voor mijn klant een installatie van drupal moet doen, heb ik daar standaard een aantal modules + installatie profiel in zitten die een aantal zaken voor mij klaar zet, bepaalde content type's aanmaakt, mijn admin stuk naar het 'seven' theme zet, adminbar aan zet, tinyMCE als editor instelt etc. etc.

Je zou kunnen stellen dat drupal dit uit de doos moet doen en kunnen, maar dat druist behoorlijk tegen de flexibiliteit in. Want ik wil seven als admin theme, andere mensen vinden rubik handiger. Ik wil tinyMCE, maar jij wilt CKeditor. etc. etc.

En om het te verduidelijken, een screenshot van project waar ik nu aan werk

[Voor 4% gewijzigd door kwaakvaak_v2 op 02-09-2010 15:39]

[Mei]

MsG schreef op donderdag 02 september 2010 @ 13:13:
Is het mogelijk om voor de gebruiker de zichtbaarheid van node-details bij het bewerken van een node te minimaliseren?

Invoerformaat
Revisie-informatie
Auteursinformatie
Publicatie-opties


Zijn allemaal niet relevant voor de gebruiker maar wel zeer verwarrend.


Ik heb het idee dat bij Drupal helaas de developer vooraan staat, terwijl het uiteindelijke doel een beetje wordt vergeten. Uiteindelijk moeten er human beings mee werken, geen techneuten / programmeurs. Voor hen vind ik Joomla! toegankelijker. Dat zou toch anders moeten zijn in een systeem welke qua basis een betere opzet heeft?

Veel dingen of zelfs alles is met permissions op te lossen. Als een gebruiker maar één input format mag gebruiken, komt er ook geen optie om te kiezen. Voor revisions geldt hetzelfde. Weet je zeker dat je test met een 'gewone' account en niet met jouw admin user?

[Peedy]

MsG schreef op donderdag 02 september 2010 @ 14:58:
[...]


Ik heb mijn klanten ook wel een apart account gegeven, met al minimale functies. Maar een paar dingen moeten ze toch kunnen. Dat het een platform of framework is vind ik een beetje een non-discussie, dat moet toch geen verschil maken voor de eindgebruiker? Prima dat het veel kan, maar waarom kan het voor de eindgebruiker niet makkelijk zonder je in allerlei bochten te wringen. Kijk eens naar wordpress als eindgebruiker om een pagina te maken / bewerken, daar is echt bij stil gestaan dat hoe mooi diepgaand het framework ook moet zijn, hoe veel features en hoeveel programmeurgeile dingen er ook inkomen: uiteindelijk zal er een normaal persoon, zonder diepgaande kennis van computers er content in kunnen typen. Ik moet de eerste Drupal website nog zien met een goede noobfriendly plain simple content edit systeem. Wat ik zie zijn halfvertaalde interfaces met onlogische opties. Drupal 7 doet het qua interface iig al een stuk beter, al is het wel een stuk zwaarder door al die javascripthipheid.

Ik werk niet met admin themes, ik bouw mijn 'admin' in de frontend. Hier een screenshot van hoe het voor mijn eindgebruiker eruitziet:



Alleen menu-instellingen heb ik er bij laten staan zodat ze een pagina onder een menu-item kunnen plaatsen en het knopje Disable rich-text omdat een van de webmasters met HTML kan werken en dat soms dus wil doen (wel gefilterd natuurlijk). Zo onoverzichtelijk is dit allemaal toch niet?

[Voor 3% gewijzigd door Peedy op 02-09-2010 16:07]

[Mei]

Peedy schreef op donderdag 02 september 2010 @ 16:05:
[...]

Ik werk niet met admin themes, ik bouw mijn 'admin' in de frontend. Hier een screenshot van hoe het voor mijn eindgebruiker eruitziet:

[afbeelding]

Alleen menu-instellingen heb ik er bij laten staan zodat ze een pagina onder een menu-item kunnen plaatsen en het knopje Disable rich-text omdat een van de webmasters met HTML kan werken en dat soms dus wil doen (wel gefilterd natuurlijk). Zo onoverzichtelijk is dit allemaal toch niet?

Een admin theme is een apart theme voor alles wat onder /admin hangt. Niets meer, niets minder. Zegmaar de 'backend' in termen van sitebeheer. Het voordeel is dat admin themes vaak meer ruimte hebben voor de grote tabellen en formulieren die op de admin pages gebruikt worden en dat onnodige dingen, zoals sidebars met content, niet getoond worden, wat voor rust en een beetje extra snelheid zorgt.

[MsG]

kwaakvaak_v2 schreef op donderdag 02 september 2010 @ 15:35:
[...]


Het is wel een discussie, jij hebt een andere verwachting bij drupal, en dat is prima maar je vergelijkt hier nu peren met appels en dat is geen eerlijk vergelijk in deze. Drupal 6 of 7 vereist gewoon wat meer werk van jouw als implementatie deskundige, maar drupal heeft een andere primaire doelgroep, mensen die een krachtig systeem willen en bereid zijn daar wat tijd in te stoppen. Wordpress heeft als doelgroep eindgebruikers die snel een blog op willen zetten. Logisch dat je in dat laatste gewoon een aantal harde binnenbochten kan nemen. Je hoeft immers nooit rekening er mee te houden dat er iemand een ander admin gedeelte maakt dan wat er standaard in zit. Drupal is daar flexibiler in, maar die flexibiliteit komt met de prijs dat het gewoon meer moeite kost om het op te zetten. Maar juist daarvoor zijn er modules en themes uitgevonden.

Als ik voor mijn klant een installatie van drupal moet doen, heb ik daar standaard een aantal modules + installatie profiel in zitten die een aantal zaken voor mij klaar zet, bepaalde content type's aanmaakt, mijn admin stuk naar het 'seven' theme zet, adminbar aan zet, tinyMCE als editor instelt etc. etc.

Je zou kunnen stellen dat drupal dit uit de doos moet doen en kunnen, maar dat druist behoorlijk tegen de flexibiliteit in. Want ik wil seven als admin theme, andere mensen vinden rubik handiger. Ik wil tinyMCE, maar jij wilt CKeditor. etc. etc.

En om het te verduidelijken, een screenshot van project waar ik nu aan werk

[afbeelding]

maar de uiteindelijke doelgroep is toch hetzelfde? Makkelijk content aanmaken / bewerken door eindgebruikers. Dat Drupal wat technischer is, is leuk maar de eindgebruiker hoeft daarom toch niet met een mindere ervaring opgezadeld te worden?

Als ik naar jouw screenshot kijk zie ik allemaal dingen half engels. En dat heb ik dus ook. Teksten als "disable rich text" e.d. Waarvan mijn oma op hol zou slaan. En dat het bewerkingstabje steevast "Edit en View heet" ipv alles gewoon Nederlands. Het zijn misschien kleine dingen om te fixen, maar het zijn wel allemaal van die papercuts. Net als dat het inloggen er overal hetzelfde uitziet, ik heb me er nog niet compleet in verdiept maar volgens mij kan dat niet zomaar 1 2 3 anders gebouwd. Mijn beeld van Drupal was een beetje Joomla maar dan zonder de workarounds en limitaties. Het tweede is misschien waar, maar het eerste helaas niet. Desondanks wil ik er toch best mee leren werken, want een deel van mijn frustraties zal vast nog wel aan mezelf liggen.

Het schijnt dat Drupal 7 ook wat meer met een soort distributiesysteem wil komen. Waar bij je uit soorten websites kan kiezen met bijbehorende packages. Dat lijkt me al een verbetering.

[kwaakvaak_v2]

Ik heb niet voor niets het administrator stuk in beeld laten staan en voor de rest den ik dat jij er inderdaad verstandig aan doet je in eens wat meer in drupal in te lezen, want je uitspraken cq. huidigr mening slaan als een spreekwoordelijke tang op een varken. Distributie systeem waar jij het over hebt heet profiles en zit nu ook al in d6. Wat jij bedoelt is dat Dries gezegt heeft dat hij graag zou zien dat er meerdere kant en klare drupal installaties met een subset van modules etc gaan komen, maar dat staat volledig los van drupal 7.

[Mei]

MsG schreef op donderdag 02 september 2010 @ 22:45:
[...]


maar de uiteindelijke doelgroep is toch hetzelfde? Makkelijk content aanmaken / bewerken door eindgebruikers. Dat Drupal wat technischer is, is leuk maar de eindgebruiker hoeft daarom toch niet met een mindere ervaring opgezadeld te worden?

Als ik naar jouw screenshot kijk zie ik allemaal dingen half engels. En dat heb ik dus ook. Teksten als "disable rich text" e.d. Waarvan mijn oma op hol zou slaan. En dat het bewerkingstabje steevast "Edit en View heet" ipv alles gewoon Nederlands. Het zijn misschien kleine dingen om te fixen, maar het zijn wel allemaal van die papercuts. Net als dat het inloggen er overal hetzelfde uitziet, ik heb me er nog niet compleet in verdiept maar volgens mij kan dat niet zomaar 1 2 3 anders gebouwd. Mijn beeld van Drupal was een beetje Joomla maar dan zonder de workarounds en limitaties. Het tweede is misschien waar, maar het eerste helaas niet. Desondanks wil ik er toch best mee leren werken, want een deel van mijn frustraties zal vast nog wel aan mezelf liggen.

Het schijnt dat Drupal 7 ook wat meer met een soort distributiesysteem wil komen. Waar bij je uit soorten websites kan kiezen met bijbehorende packages. Dat lijkt me al een verbetering.

Dude Heb je überhaupt al eens geprobeerd Nederlandse vertalingen te importeren?

[MsG]

Ja hoor, ik vertaal zelf mee. Maar veel dingen blijven by default engels, of je moet per module handmatig de vertalingen doen, ipv 1 overkoepelend systeem. Met de Nederlandse drupal geïnstalleerd, dus alles Nederlands heten de tabs "View" en "Bewerken". Dat is precies van die half-afheid die ik te vaak zie helaas.

[Mei]

Als alle vertalingen volledig zijn geïmporteerd, en de vertalingen zijn ook allemaal compleet (wat niet altijd zo is), dan moet alles in het Nederlands zichtbaar zijn.

En als het je niet zint dat de vertalingen niet compleet zijn, dan kan je mooi meehelpen op http://localize.drupal.org.

[thefal]

Ik heb een probleem, ik denk dat het een probleem is van de service waar ik gebruik van maak maar misschien is het ook een fout van Drupal. Ik hoop dat jullie er even naar kunnen kijken.

Drupal lijkt namelijk helemaal niet overweg te kunnen met tables. Zie bijvoorbeeld http://refleks.tp2p.com/nl/node/9
waar de tables helemaal onder aan de pagina wordt weergegeven terwijl ik deze boven wil hebben.
Beide tables nemen ook de hele breedte van het scherm in, terwijl bij de eerste staat width="200" en bij de laatste width="600". De waarde van width wordt dus helemaal niet meegenomen, maar ik wil kleinere tables hebben.

Iemand een idee?

[MsG]

Dit heeft eigenlijk niks met Drupal te maken, maar ik zie dat je 2x width: 100% defineert in CSS bij "table". Die moet je dus weghalen of overrulen. Gebruik anders eens firebug voor Firefox, dan kan je zulke dingen binnen een tel zien.

[thefal]

Ik zal eerlijk zijn: Ik zie het niet. Maargoed het maakt verder niks uit, ik kan die css bestanden namelijk niet veranderen (Die "krijg" je standaard bij de tp2p service). Dus de enige oplossing is... ergens anders heengaan?

Edit: Ahh ik zie het, bij pictures.css, bedankt! Blijft het probleem dat ik die niet zomaar veranderen kan...

[Voor 20% gewijzigd door thefal op 12-10-2010 15:56]

[Eusebius]

thefal schreef op dinsdag 12 oktober 2010 @ 15:50:
Ik zal eerlijk zijn: Ik zie het niet. Maargoed het maakt verder niks uit, ik kan die css bestanden namelijk niet veranderen (Die "krijg" je standaard bij de tp2p service). Dus de enige oplossing is... ergens anders heengaan?

Joh, ga bij een hoster zitten voor een paar euro per maand .. dat is en leuker en heb je de boel echt zelf in de hand. Wel eentje met genoeg opties & ram kiezen. Zijn er genoeg te vinden via reviews ed.

^kuch

[thefal]

Nog een paar vraagjes voor de beginner:

1. Ik heb drupal gedownload. Kan ik gewoon de bestanden uit het tar.gz bestand dmv FTP uploaden en dan werkt het direct?
2. Zo ja, kan ik dan ook alle bestanden gewoon downloaden dmv FTP, dan ergens anders uploaden en dan worden alle instellingen en pagina's enzo onthouden?

Ik wil namelijk bij een gratis hoster uitproberen omdat uiteindelijk de bedoeling wordt dat de vereniging betaald. Ikwil ze dus overtuigen door de site online te zetten dmv een gratis hoster (op een andere plek dan waar die nu staat), en als het goed gekeurd wordt door het bestuur wil ik de site overzetten naar hun hoster.

[Voor 34% gewijzigd door thefal op 13-10-2010 20:44]

[Eusebius]

Euhm .. hoe je eea dient te installeren staat gewoon in de handleiding. Als je daar niet uitkomt, zou ik er helemaal niet aan beginnen. Want als je eenmaal die proefsite in de lucht hebt, komt er veel meer op je af

[Mei]

Eusebius schreef op woensdag 13 oktober 2010 @ 21:35:
Euhm .. hoe je eea dient te installeren staat gewoon in de handleiding. Als je daar niet uitkomt, zou ik er helemaal niet aan beginnen. Want als je eenmaal die proefsite in de lucht hebt, komt er veel meer op je af

Hé, mensen kunnen leren he ;-)

Maar Lennart heeft wel gelijk over de handleiding. Wat jij wil is mogelijk, maar er komt nog heel iets meer bij kijken. Drupal slaat net als elk ander systeem zijn gegevens namelijk op in een SQL database. Deze moet je voor de installatie aanmaken en als je je site verhuist, dan moet deze meeverhuizen.

[thefal]

Ik had ergens gelezen dat je de bestanden zo kan uploaden. Maargoed ik zal de handleiding lezen, bedankt!

[Eusebius]

Mei schreef op woensdag 13 oktober 2010 @ 21:46:
[...]

Hé, mensen kunnen leren he ;-)

Jo

We hebben allemaal te leren, maar volgens mij zit thefal met zijn vraag hier op de verkeerde plek. Ik wil m met alle liefde helpen, maar in het verleden riep deze of gene mod nog weleens dat we ons bij ervaringen dienden te houden.

Een goede tip voor beginners maar ook gevorderden: Drupal.org of Drupal.be. En als je er dan niet uitkomt, natuurlijk dit forum

(of ben ik nu te streng )

[Creepy]

Het is en blijft een ervaringen topic ja
Voor problemen kan je altijd een los topic openen, maar de handleiding zul je moeten lezen voordat je uberhaupt een topic gaat openen zoals weer uitgelegd staat in Het algemeen beleid #quickstart

[Voor 3% gewijzigd door Creepy op 14-10-2010 11:36]

[thefal]

Ja ok ik had die al even doorgenomen maar in de handleiding die ik erbij heb staat alleen hoe de installatie op linux verloopt.

Even iets anders: Ik heb vanmiddag de taal veranderd op mijn website (refleks.tp2p.com) en nu is mijn hele pagina niet meer vindbaar?!? Hoe kan dat nu weer? Of is het zo dat het even duurt om alles te vertalen?

Pagina niet gevonden

Edit: ik ging naar administer, en dan localisation.

[Voor 13% gewijzigd door thefal op 14-10-2010 17:10]

[Mei]

Zou gewoon moeten werken, maarja, zonder voldoende informatie kan zelfs mijn glazen bol je niet vertellen wat er verkeerd gaat.

[thefal]

Ik weet niet wat voor indormatie ik verder nog kan geven. De site staat gehost op http://freedrupal5hosting.com/ Daar kan je je aanmelden en dan staat er direct een verse Drupal installatie klaar die je kan aanpassen. Standaard staat die in het Engels. Nederlands hebben e daar niet, dus ik probeerde Afrikaans om hopelijk wat tijd te besparen. Dus ik ging naar administer -> localization. Daar heb je iets als een knopje "add language". Uit de lijst die ik daar kreeg koos ik Afrikaans.

[Mei]

thefal schreef op donderdag 14 oktober 2010 @ 17:23:
Ik weet niet wat voor indormatie ik verder nog kan geven.

Oh?

nu is mijn hele pagina niet meer vindbaar?!?

Welke pagina?

Edit: ik ging naar administer, en dan localisation.

Ik ga ook wel eens ergens heen, maar dat hoeft niet te betekenen dat ik daar ook daadwerkelijk iets gedaan heb.

Kortom: meer informatie. Anders geen antwoord. Kan er ook niets meer van maken, met of zonder glazen bol

[Menesis]

thefal schreef op woensdag 13 oktober 2010 @ 20:42:
Nog een paar vraagjes voor de beginner:

1. Ik heb drupal gedownload. Kan ik gewoon de bestanden uit het tar.gz bestand dmv FTP uploaden en dan werkt het direct?
2. Zo ja, kan ik dan ook alle bestanden gewoon downloaden dmv FTP, dan ergens anders uploaden en dan worden alle instellingen en pagina's enzo onthouden?

Ik wil namelijk bij een gratis hoster uitproberen omdat uiteindelijk de bedoeling wordt dat de vereniging betaald. Ikwil ze dus overtuigen door de site online te zetten dmv een gratis hoster (op een andere plek dan waar die nu staat), en als het goed gekeurd wordt door het bestuur wil ik de site overzetten naar hun hoster.

1. ja
2. je moet de bestanden indd weer kopieren via FTP, maar ook de database exporteren (of downloaden mbv back&migrate module) en bij je nieuwe host importeren. Als laatste moet je waarschijnlijk settings aanpassen (dat bestandje dat je tijdens het installeren ook moet uploaden). Allemaal vrij makkelijk

[thefal]

Edit: Laat maar nu ben ik al zo lang aan het typen dat ik ineens een ingeving kreeg die mijn site weer tevoorschijn tovert...

Mei schreef op donderdag 14 oktober 2010 @ 18:23:
[...]

Oh?

[...]

Welke pagina?

[...]

Ik ga ook wel eens ergens heen, maar dat hoeft niet te betekenen dat ik daar ook daadwerkelijk iets gedaan heb.

Kortom: meer informatie. Anders geen antwoord. Kan er ook niets meer van maken, met of zonder glazen bol

Ok nog 1x, dit is alles wat ik kan vertellen, anders zeg je even specifiek welke info je nodig hebt?

Mijn website was refleks.tp2p.com, gehost door freedrupal5hosting. Als je daar nu heen gaat ziet je dat er alleen staat pagina niet gevonden. Dit is sinds vanmiddag zo. Ik liet een paar mensen mijn site zien en logde in als admin. Ik liet de pagina "teams" zien, dit is waar de teamindelingen en foto's stonden. Daarna liet ik ze de pagina video's zien. Hierop stonden 2 plaatjes die naar Youtube verwezen. De mensen aan wie ik mijn site liet zien gingen weg, maar 1 iemand vroeg nog: "Waarom staan er een paar dingen in het Engels?".

Ik klikte op "Administer" , toen op "Localisation". Daar stond een "rijtje" met talen, maar er stond alleen Engels. Toen drukte ik op Add Language en ik liet die persoon zien dat er daar een heleboel talen instonden.Echter Nederlands stond er niet bij. Ik zag wel Afrikaans erop staan, dus ik drukte erop in de hoop dat een heleboel dingen Nederlands of Nederlands-achtig zouden worden. Ik drukte op OK (of add language of welke knop daar ook onder zit).

Binnen een seconde nadat ik dit deed kreeg ik de pagina die je nu ziet op refleks.tp2p.com , namelijk een pagina waarvan de "head" en de banner er nog steeds staan, maar waar je verder alleen de melding "Pagina niet gevonden" ziet staan.

En dat is mijn verhaal. Ik wilde mijn site precies vandaag laten zien aan het bestuur van mijn vereneging, maar dat gaat dus helaas niet meer.

Als je naar http://refleks.tp2p.com/node/2 is mijn oude site nog te zien, maar klikken op een link resulteert weer in "pagina niet gevonden"

[Voor 3% gewijzigd door thefal op 14-10-2010 21:39]

[Mei]

thefal schreef op donderdag 14 oktober 2010 @ 21:36:
Edit: Laat maar nu ben ik al zo lang aan het typen dat ik ineens een ingeving kreeg die mijn site weer tevoorschijn tovert...

En wat was die ingeving? Is niet leuk om ons nieuwsgierig te maken en dan niets te zeggen he

[...]


Ok nog 1x, dit is alles wat ik kan vertellen, anders zeg je even specifiek welke info je nodig hebt?

Jij stelt een vraag, dus jij moet beginnen met info te geven. Jij weet waar je wat gedaan hebt. Ik kan wel willekeurige oplossingen voorstellen, maar daar schiet niemand wat mee op. Helemaal niet bij iets vaags als 404 errors.

[thefal]

Mei schreef op donderdag 14 oktober 2010 @ 21:48:
[...]

En wat was die ingeving? Is niet leuk om ons nieuwsgierig te maken en dan niets te zeggen he


[...]

Jij stelt een vraag, dus jij moet beginnen met info te geven. Jij weet waar je wat gedaan hebt. Ik kan wel willekeurige oplossingen voorstellen, maar daar schiet niemand wat mee op. Helemaal niet bij iets vaags als 404 errors.

Voor zover ik weet had ik de belangrijkste stappen allemaal al hier gepost, daarna nog maar even uitgebreid met allerlei info (die volgens mij totaal irrelevant is, maar ok). Als dat niet genoeg geweest zou zijn schat ik de kans klein dat ik een oplossing zou krijgen

Anyway ik ging naar de site van drupal en het viel me op dat alle pagina's in principe eindigen met /node/<cijfer>. Ik kwam op het idee om dit gewoon achter de URL te plakken en kijken of een pagina het nog deed. /node/2 werkte dus. Vanaf daar drukte ik op administer (/nl/admin) en dat werkte weer niet. Blijkt dat ik na elke keer drukken op een knop het /nl gedeelte moest weghalen en dat werkte weer. Stappenplan was dus eigenlijk:
probeer /node/1, /node/2 werkt!
druk op een knop, ik ging naar /nl/admin, werkt niet.
haal het gedeelte /nl weg, werkt wel weer.
druk op localisation , /nl/admin/settings/locale werkt weer niet.
haal /nl weg, werkt weer wel
verander de taal en druk op OK

en gefixt

[Mei]

Tip voor de volgende keer: de URL die je probeert te laden kan relevant zijn

[thefal]

Ik ging er vanuit dat je links automatisch meeveranderen als je de taal verandert Bovendien deed mijn homepage zelf het ook al niet dus dat vond ik bijzonder raar. Maar oke alles werkt weer!

[Stroopwafels]

_{*Kleine bumpje*}

Ik ben op het moment een Joomla template aan het omzetten naar een Drupal template.
Is makkelijker dan ik had gedacht.

Verder ben ik tevreden over Drupal alhoewel ik het administratie gedeelte van Joomla mooier vindt.

[Voor 6% gewijzigd door Stroopwafels op 26-10-2010 13:30]

[MsG]

Klopt, is niet echt heel moeilijk. Het meeste werk bij templates is imo altijd de html zelf.

Wat was bij jou de reden om naar Drupal te gaan?

[zx9r_mario]

Mijn 2 cents over drupal:

Ik heb redelijk wat gedaan in Joomla. Met Wordpress 3.0 ben ik ook mee aan het stoeien. Wp is simpel te bedienen (vooral de update functie). Maar als je wat extra functionaliteit wil of custom posts oid, dan moet je gelijk in de php code gaan liggen werken.

Nu ben ik Drupal 7 Beta2 aan het testen, en ik moet zeggen dat dit wel lekker werkt met de nieuwe admin schermen tov V6 . De themes vind ik zelf professioneler over komen. Joomla themes lijken te veel op elkaar en Wordpress vind ik nog te 'bloggy'.

Ik denk dat ik bij Drupal 7 blijf.

[Eusebius]

MsG schreef op dinsdag 26 oktober 2010 @ 14:05:

Wat was bij jou de reden om naar Drupal te gaan?

Bij mij? Liep tegen de grenzen van Joomla aan. En vanaf Dr5 gebleven en zie uit naar Dr7!

[Bozozo]

Hmm, ik loop bij het maken van een zen-based theme tegen iets vreemds aan. De breadcrumb werkt niet zoals ik zou verwachten.

Als ik navigeer naar Home > Item > Subitem dan bevat de breadcrumb Home > Subitem. Dat lijkt mij toch ongewenst gedrag?

Zie hier voor een voorbeeld. Komt dit iemand bekend voor?

[Eusebius]

Bozozo schreef op donderdag 02 december 2010 @ 00:27:
Hmm, ik loop bij het maken van een zen-based theme tegen iets vreemds aan. De breadcrumb werkt niet zoals ik zou verwachten.

Als ik navigeer naar Home > Item > Subitem dan bevat de breadcrumb Home > Subitem. Dat lijkt mij toch ongewenst gedrag?

Zie hier voor een voorbeeld. Komt dit iemand bekend voor?

Volgens mij een bekend probleem.

Ligt niet aan Zen (thema, da's layout enzo) maar aan code. Dus voor een oplossing dien je naar modules e/o fixes te zoeken.

[Bozozo]

Fixed met de Menu Breadcrumb module. Wel een belachelijke bug/feature als je het mij vraagt.

[Cheeky]

Waar hosten jullie je drupal site? Ik heb momenteel een mediatemple (gs), maar die gaat m'n drupal 7 site niet echt trekken ben ik bang.

Ik heb gekeken naar wat VPS opties, zoals VPS.net en linode.com, maar ik ben bang dat zoiets te veel administratie werk oplevert?

Een andere optie is een mediatemple (dv), maar daar heb je vrij weinig ram voor je geld?

[MsG]

Is het zoveel zwaarder dan? Ik heb er gister even mee gespeeld, maar de recommended ram was van 32MB naar 40MB gegaan.

[Mei]

Bozozo schreef op donderdag 02 december 2010 @ 22:25:
Fixed met de Menu Breadcrumb module. Wel een belachelijke bug/feature als je het mij vraagt.

Hangt er vanaf waardoor die pagina's en de breadcrumbs gemaakt worden. Zonder info daarover kan niemand iets zinnigs zeggen en kan het net zo goed je eigen fout zijn.

Cheeky schreef op maandag 20 december 2010 @ 04:52:
Waar hosten jullie je drupal site? Ik heb momenteel een mediatemple (gs), maar die gaat m'n drupal 7 site niet echt trekken ben ik bang.

Ik heb gekeken naar wat VPS opties, zoals VPS.net en linode.com, maar ik ben bang dat zoiets te veel administratie werk oplevert?

Een andere optie is een mediatemple (dv), maar daar heb je vrij weinig ram voor je geld?

Ben nu zelf aan het spelen met een VPS, maar dat is omdat ik bijvoorbeeld zelf PHP extensions wil kunnen installeren voor de wat exotischere dingen die ik ontwikkel. Voor eenvoudige sites die geen exotische functionaliteit nodig hebben (Ik werk nu bijvoorbeeld met Pspell, wat veel shared hosters niet aanbieden) zal shared hosting gewoon voldoen.

[Cheeky]

MsG schreef op maandag 20 december 2010 @ 05:54:
Is het zoveel zwaarder dan? Ik heb er gister even mee gespeeld, maar de recommended ram was van 32MB naar 40MB gegaan.

Drupal 6 was op die mediatemple (gs) al niet te doen. Ja, met de Boost module, maar die zet dan gewoon html bestanden klaar in de cache..

@Mei Hoeveel tijd aan onderhoud ben je kwijt aan die VPS ong?

[Anoniem: 228838]

Cheeky schreef op maandag 20 december 2010 @ 14:44:
[...]

Drupal 6 was op die mediatemple (gs) al niet te doen. Ja, met de Boost module, maar die zet dan gewoon html bestanden klaar in de cache..

Je laat het klinken alsof daar op de een of andere manier iets mis mee is?

Volgens mij bewijst je opmerking namelijk dat het caching mechanisme goed werkt, als het niet goed had gewerkt was de site - ondanks de caching - langzamer geworden.

Het eerste waar ik naar zou kijken is modules; reduceren tot strikt noodzakelijk. En een algemene tip; ontwikkel op een site die hooguit de helft van de capaciteit en performance van een produktie omgeving heeft maar wel beschikt over produktie data. Als daar je performance goed is heb je in produktie tenminste nog een beetje speling.

[Cheeky]

Anoniem: 228838 schreef op maandag 20 december 2010 @ 22:04:
[...]


Je laat het klinken alsof daar op de een of andere manier iets mis mee is?

Volgens mij bewijst je opmerking namelijk dat het caching mechanisme goed werkt, als het niet goed had gewerkt was de site - ondanks de caching - langzamer geworden.

Het nadeel is dat Boost alleen werkt voor anonymous users. Zodra iemand inlogt zit je weer op een laadtijd van een aantal seconden. Plus dat Boost voor D7 nog niet uit is..

Daarnaast moet na een belangrijke verandering de cache geleegd worden en of iemand elke pagina met een lange laadtijd 1 keer bezoeken of de hele site afgecrawld worden om de cache weer op te bouwen..

[Anoniem: 228838]

Cheeky schreef op maandag 20 december 2010 @ 23:03:
[...]
Het nadeel is dat Boost alleen werkt voor anonymous users. Zodra iemand inlogt zit je weer op een laadtijd van een aantal seconden. Plus dat Boost voor D7 nog niet uit is..

Ok, dat heb ik aan den lijve ondervonden op de drupal site zelf ... zodra je inlogged is de performance van de site er uit. Ik weet niet hoe dat met de nieuwe site is. (Even getest, mijn eerdere problemen komen daar nu niet voor)

Je zou zeggen dat er dan winst te halen is door een soort group-based caching toe te voegen?

Daarnaast moet na een belangrijke verandering de cache geleegd worden en of iemand elke pagina met een lange laadtijd 1 keer bezoeken of de hele site afgecrawld worden om de cache weer op te bouwen..

Dat lijkt mij een fout in het caching mechanisme? Ik bedoel caching wil zeggen - als de pagina ongewijzigd is haal 'm dan uit de cache, anders laad 'm overnieuw ... Ik moet toegeven dat ik niet een, twee drie kan zeggen hoe je kunt bepalen of een pagina gewijzigd is ...

[afraca]

*kick*

Sowiezo dat Joomla niet een dergelijke receptie heeft:

(@ Drupal 7 release)

Mensen al wat ervaring met D7? Veel "pledges" van module developers, dus dat zit inderdaad snor?

[Voor 33% gewijzigd door afraca op 08-01-2011 11:22]

[Mei]

De adoptie van een nieuwe versie duurt altijd een tijdje, maar voor Drupal 7 is dat beter geregeld. Van veel modules is al een versie voor D7 beschikbaar, al dan niet in de laatste fase van ontwikkeling.

[Eusebius]

Ik kan bijna niet wachten totdat ik tijd heb DR7 te installeren (natuurlijk eerst kijken of alle relevante modules zijn geupgrade ..)

Een vraagje: ik heb een viertal sites, van 4 kerkelijke gemeentes. Die hebben elk een roostertje met diensten (dus titel, tekst, datum, bijlage). Eén site is een hoofdsite. Nu worden alle diensten op de site's apart ingevoerd. Maar ik zou het liever zien gebeuren vanaf 1 site en dat de andere het dan overnemen. Ze staan op dezelfde server. Dit zou nog kunnen met RSS (RSS to groupnode oid), maar het probleem is de datum: de geimporteerde datum moet in hetzelfde CCKveld komen als de andere datums, omdat VIEWS data uit verschillende contenttypes niet door elkaar heen sorteert maar eerst contenttype 1 doet en dan 2.
Of kun je via RSS ook velden koppelen aan CCKvelden?

[kwaakvaak_v2]

feeder module

[Peedy]

Aggregator kan het ook, hoewel Feeder inderdaad simpeler is.

De nieuwste versie van Drush schopt overigens kont

[Voor 32% gewijzigd door Peedy op 13-01-2011 14:25]

[Eusebius]

Tnx voor Feeder! Zal ernaar kijken.

Peedy schreef op donderdag 13 januari 2011 @ 14:25:
Aggregator kan het ook, hoewel Feeder inderdaad simpeler is.

De nieuwste versie van Drush schopt overigens kont

Zeg je nou Feeder en Drush in 1 post omdat ze bij elkaar horen?

[Peedy]

Eusebius schreef op donderdag 13 januari 2011 @ 20:26:
Tnx voor Feeder! Zal ernaar kijken.


[...]

Zeg je nou Feeder en Drush in 1 post omdat ze bij elkaar horen?

Nouja, in hoeverre horen ze bij elkaar? 'drush dl feeder && drush pm-enable feeder' en daar houdt het wel mee op.

[moozzuzz]

Een zoveelste D7-noobvraagje...

Drupal ken ik als concept maar ik struikel nog even over de filters. Wanneer ik een article wil aanmaken in filtered_html modus (gecombineerd met een tinymce RTE) blijkt het beestje de RTE-opmaak om te zetten naar "UBB". Niet meteen handig... Wat doe ik fout?

[Mei]

moozzuzz schreef op dinsdag 25 januari 2011 @ 11:19:
Een zoveelste D7-noobvraagje...

Drupal ken ik als concept maar ik struikel nog even over de filters. Wanneer ik een article wil aanmaken in filtered_html modus (gecombineerd met een tinymce RTE) blijkt het beestje de RTE-opmaak om te zetten naar "UBB". Niet meteen handig... Wat doe ik fout?

Een WYSIWYG die de boel omzet naar UBB? Lijkt me een instelling van TinyMCE dan.

[Eusebius]

Ik ben Dr7 aan het uitproberen en het ziet er gelikt uit Ik moet mijn kennis weer een stukje verhogen, want OG's worden nu geregeld via Panels.

Waarom voegen ze Panels en Views eigenlijk niet samen? Voor mijn gevoel raken die 2 elkaar, je kunt er nl 2x instellen hoe je de content wilt zien. Natuurlijk zijn er grote verschillen, maar daarom heet het ook samenvoegen Noem het Piews ofzo haha.

Wat ik wel lastig vind: hoe kun je precies een specifiek panel maken voor 1 OG? Ik heb nu bij de tab "selection rules" gekozen voor String: URL path en dan current path is [hele URL naar OG]. Ik weet in ieder geval dat dat niet werkt ;-) Maar hoe dan wel?

[moozzuzz]

Mei schreef op dinsdag 25 januari 2011 @ 11:40:
Een WYSIWYG die de boel omzet naar UBB? Lijkt me een instelling van TinyMCE dan.

Thanks, zoals je ziet een stomme noobtoestand . Ik ging er foutievelijk van uit dat de UBB-plugin er voor zorgde dat UBB-code ook herkend werd... Niet dus! Ondertussen ook ICME werkend gekregen (dat ging even wat makkelijker =-)

[kwaakvaak_v2]

Van mij mogen ze heel panels best afschaffen ipv samen te voegen met views! Het concept is leuk.. Maar het geeft net als views een enorme bak html plak code om één scherm op te bouwen. Het concept is best goed, daar niet van hoor. Maar ik vind de uitwerking wel erg krom gedaan. Ik snap hoe theming in drupal werkt, wat nog niet weg neemt dat ik het soms wel nodeloos complex vind om te gebruiken. Zeker als je net als wij op het werk, gewoon kant en klare HTML aangeleverd krijgt en die naar drupal moet zetten. En eigenlijk geen tijd/zijn hebt om een groot deel van de CSS aan te passen, of voor elke theme functie/hook/element die een contributed module bedacht heeft een eigen implementatie moet schrijven in je template.php om gewoon pure data (dus zonder HTML!) naar je schoppen, zodat je de uiteindelijke display code kan regelen op het nivo waar het geregeld hoort te
worden.

[Eusebius]

Volgens mij is Panels / Views vooral bedoelt om een wysiwyg ding te maken. Van mij mag dat, ik ben qua webdevelopment een hobbyist, geen pro. Maar het ironische is, dat de pro het overbodig vind en de hobbyist (ikke dus) moeilijk ;-)

[Mei]

kwaakvaak_v2 schreef op dinsdag 25 januari 2011 @ 17:51:
Van mij mogen ze heel panels best afschaffen ipv samen te voegen met views! Het concept is leuk.. Maar het geeft net als views een enorme bak html plak code om één scherm op te bouwen. Het concept is best goed, daar niet van hoor. Maar ik vind de uitwerking wel erg krom gedaan. Ik snap hoe theming in drupal werkt, wat nog niet weg neemt dat ik het soms wel nodeloos complex vind om te gebruiken. Zeker als je net als wij op het werk, gewoon kant en klare HTML aangeleverd krijgt en die naar drupal moet zetten. En eigenlijk geen tijd/zijn hebt om een groot deel van de CSS aan te passen, of voor elke theme functie/hook/element die een contributed module bedacht heeft een eigen implementatie moet schrijven in je template.php om gewoon pure data (dus zonder HTML!) naar je schoppen, zodat je de uiteindelijke display code kan regelen op het nivo waar het geregeld hoort te
worden.

Daarom is het ook het beste om het design door een Drupal themer om te laten zetten naar een theme en niet eerst door een willekeurige webdodo naar HTML & CSS. Het is leuk en aardig, maar uiteindelijk tellen de kosten en functionaliteit het meeste mee. Een klein beetje HTML te veel is dan niet erg relevant meer.

[Peedy]

Ik ga voorzichtig aan ook maar eens naar D7 gluren.. heb het de afgelopen tijd zo druk gehad met allerlei sites dat ik het nog niet heb aangedurfd om voor een vol traject in D7 te springen terwijl ik D6 op m'n duimpje ken. Eerst maar eens onderzoeken of de door mij gebruikte modules (of functionaliteiten van die modules) allemaal wel beschikbaar zijn in D7; iemand al tegen belangrijke modules aangelopen waar nog geen D7 variant van is?

[MsG]

Ik zit nu een beetje te spelen met views, omdat ik Drupal een beetje wil leren begrijpen, maar hoe ga je om met gegevens die je zonder Drupal anders gewoon zelf in je database had gezet.

Bijvoorbeeld woonplaatsen enzo, wordt dan elke woonplaats een node die weer gekoppeld is aan provincie enzo?

[Mei]

Met CCK/Field kan je extra velden aan content (en in Drupal 7 aan users, comments en meer) toevoegen. Deze velden zijn dan automatisch beschikbaar in Views.

[MsG]

Ik bedoelde eigenlijk ook CCK, maar als ik wil dat die beschikbaar is dan moet ik handmatig al die data invoegen, of is daar ook een andere manier voor?

[Peedy]

MsG schreef op dinsdag 25 januari 2011 @ 22:46:
Ik bedoelde eigenlijk ook CCK, maar als ik wil dat die beschikbaar is dan moet ik handmatig al die data invoegen, of is daar ook een andere manier voor?

Je kan met de Data module tables die in je database staan maar die niet bij Drupal horen 'adopten' zodat ze binnen Views beschikbaar zijn. Als je woonplaats bijvoorbeeld in een Webform zou willen gebruiken zou ik eens naar deze blog kijken; http://www.designhammer.c...ons-webform-module-drupal en dan vooral naar mijn toevoegingen daarop (de laatste 3 comments).

Overigens heb je ook een module Node import waarmee je, als je eenmaal je content types hebt aangemaakt, snel een CSVtje kan importeren.

dit is allemaal D6 trouwens

[Voor 16% gewijzigd door Peedy op 26-01-2011 17:59]

[TheDane]

Iemand ervaring met Ubercart?

Ik ben met een webshop bezig, en dat gaat helemaal prima .. maar het is kennelijk out of the box niet mogelijk om de producten in een bepaalde categorie (bepaald door taxonomy) anders te sorteren. Bijvoorbeeld op prijs (goedkoop-duur of andersom) of alfabetisch.

Ik heb het idee dat ik dit met Views kan ... maar kan ik daarmee dan ook de user laten kiezen? Wat ik tot nog toe begrepen heb is dat ik dan voor iedere sortering een aparte view moet maken.. maar is dat niet vreselijk omslachtig?

[Mei]

TheDane schreef op woensdag 26 januari 2011 @ 02:15:
Iemand ervaring met Ubercart?

Ik ben met een webshop bezig, en dat gaat helemaal prima .. maar het is kennelijk out of the box niet mogelijk om de producten in een bepaalde categorie (bepaald door taxonomy) anders te sorteren. Bijvoorbeeld op prijs (goedkoop-duur of andersom) of alfabetisch.

Ik heb het idee dat ik dit met Views kan ... maar kan ik daarmee dan ook de user laten kiezen? Wat ik tot nog toe begrepen heb is dat ik dan voor iedere sortering een aparte view moet maken.. maar is dat niet vreselijk omslachtig?

Je kan per filter kiezen of deze exposed is, wat betekent dat gebruikers deze kunnen instellen.

[kwaakvaak_v2]

Mei schreef op dinsdag 25 januari 2011 @ 21:17:
[...]

Daarom is het ook het beste om het design door een Drupal themer om te laten zetten naar een theme en niet eerst door een willekeurige webdodo naar HTML & CSS. Het is leuk en aardig, maar uiteindelijk tellen de kosten en functionaliteit het meeste mee. Een klein beetje HTML te veel is dan niet erg relevant meer.

Onzin... Sorry, ik vind dat een systeem nooit, maar dan ook echt nooit mag afdwingen hoe de HTML eruit hoort te zien. Dat is de wereld op zijn kop,dat is hetzelfde als dat Nederland bepaalt dat je alleen maar op vredenstein banden over onze snelwegen mag rijden.

Oh enne ik denk ook niet dat onze frontenders in de studio hier, als webdodo mag bestempelen,. Er zit behoorlijk wat meer kennis tussen hun oren over hoe correcte HTML eruit hoort te zien, en daar kan hier en daar de drupal community behoorlijk wat van leren

Maar goed dit is idd wel een non-issue in drupal land, want iedereen conformeert zich er maar aan dat drupal nu eenmaal ietsje meer html uitbraakt dan nodig en dat vind ik erg jammer.. Want het is voor de rest een leuk systeem, en ik vind het oprecht best leuk om er projecten in te maken. Dus hebben wij hier wat eigen modules gemaakt, en een fatsoenlijkere template engine dan phptemplate, om er toch voor te zorgen dat er nette(re) HTML uit komt rollen.

[Eusebius]

Mei schreef op dinsdag 25 januari 2011 @ 21:17:
[...]

Daarom is het ook het beste om het design door een Drupal themer om te laten zetten naar een theme en niet eerst door een willekeurige webdodo naar HTML & CSS. Het is leuk en aardig, maar uiteindelijk tellen de kosten en functionaliteit het meeste mee. Een klein beetje HTML te veel is dan niet erg relevant meer.

Euh .. ik heb 10 sites van lokale non-profitorganisaties. Welke professionele themer wil hier zijn tijd insteken in het ontwikkelen en onderhouden? ... [stilte] .. dacht ik al, niemand ;-) Als hobbyist kijk ik ook naar theming (*.tpl.php etc aanpassen) maar de kunde, kennis en geld heb ik niet. Dus dan ben ik maar wat blij met deze oplossingen. En wat ik geleerd heb is dat je met de flow mee moet gaan, want anders loop je vast.

Wat ik daarmee bedoel: had een paar sites met Drupal 4.x neergezet en een paar 'exotische' modules gebruikt. Bij Dr5 en Dr6 werden deze niet meer gebruikt. Zodoende kon ik en alles omgooien en aan gebruikers nog een keer gaan uitleggen hoe het nou weer moest. Dat kost alleen maar tijd. Daarom gebruik ik zoveel mogelijk de meest gangbare modules (of ik schrijf ze zelf om iets te hooken (heet dat zo )).

De vraag die ik eerder stelde is nog niet opgelost: hoe kan ik panels gebruiken voor geselecteerde OG's in Dr7?

[Mei]

kwaakvaak_v2 schreef op woensdag 26 januari 2011 @ 09:36:
[...]


Onzin... Sorry, ik vind dat een systeem nooit, maar dan ook echt nooit mag afdwingen hoe de HTML eruit hoort te zien. Dat is de wereld op zijn kop,dat is hetzelfde als dat Nederland bepaalt dat je alleen maar op vredenstein banden over onze snelwegen mag rijden.

Oh enne ik denk ook niet dat onze frontenders in de studio hier, als webdodo mag bestempelen,. Er zit behoorlijk wat meer kennis tussen hun oren over hoe correcte HTML eruit hoort te zien, en daar kan hier en daar de drupal community behoorlijk wat van leren

Maar goed dit is idd wel een non-issue in drupal land, want iedereen conformeert zich er maar aan dat drupal nu eenmaal ietsje meer html uitbraakt dan nodig en dat vind ik erg jammer.. Want het is voor de rest een leuk systeem, en ik vind het oprecht best leuk om er projecten in te maken. Dus hebben wij hier wat eigen modules gemaakt, en een fatsoenlijkere template engine dan phptemplate, om er toch voor te zorgen dat er nette(re) HTML uit komt rollen.

Drupal dwingt je ook niet af de standaard HTML te gebruiken. Wat ik duidelijk probeer te maken is dat je een design door Jan-Jaap om kan laten zetten naar HTML en CSS, om vervolgens zelf tientallen theme overrides te doen, of je kan het design direct door een Drupal themer om laten zetten. Je bent vrij om te doen wat je wil, maar de laatste optie kost minder moeite. Ik ben het met je eens dat Drupal soms te veel markup uitspuugt, maar je kan niet je kop in het zand steken en zeggen dat het de schuld van een specifiek systeem is, als jij besluit met dat systeem te werken, maar je werkwijze er niet op aanpast.

[kwaakvaak_v2]

Mei schreef op woensdag 26 januari 2011 @ 12:09:
[...]

Drupal dwingt je ook niet af de standaard HTML te gebruiken. Wat ik duidelijk probeer te maken is dat je een design door Jan-Jaap om kan laten zetten naar HTML en CSS, om vervolgens zelf tientallen theme overrides te doen, of je kan het design direct door een Drupal themer om laten zetten. Je bent vrij om te doen wat je wil, maar de laatste optie kost minder moeite. Ik ben het met je eens dat Drupal soms te veel markup uitspuugt, maar je kan niet je kop in het zand steken en zeggen dat het de schuld van een specifiek systeem is, als jij besluit met dat systeem te werken, maar je werkwijze er niet op aanpast.

Dit blijft een welles nietus discussie, want ik probeer duidelijk te maken dat drupal zich als je dat wilt, niet met de layout moet bemoeien. Tuurlijk, kun je dat met theme functies overschrijven, maar dat betekend dat je voor bijna alles een eigen theme functie moet maken, of een hele hoop preg_replace etc functies in je template.php moet doen. Of het meer of minder moeite kost, om content van drupal te untheme'n weet ik, niet het zoeken naar de juiste field_fieldname.0.blaat['doowap']['#value'] in een tpl.php is ook niet altijd even snel.

[Mei]

kwaakvaak_v2 schreef op woensdag 26 januari 2011 @ 13:50:
[...]


Dit blijft een welles nietus discussie, want ik probeer duidelijk te maken dat drupal zich als je dat wilt, niet met de layout moet bemoeien. Tuurlijk, kun je dat met theme functies overschrijven, maar dat betekend dat je voor bijna alles een eigen theme functie moet maken, of een hele hoop preg_replace etc functies in je template.php moet doen. Of het meer of minder moeite kost, om content van drupal te untheme'n weet ik, niet het zoeken naar de juiste field_fieldname.0.blaat['doowap']['#value'] in een tpl.php is ook niet altijd even snel.

Hoe wil je het anders doen? Een systeem dat zich helemaal niet met de output bemoeit zal je alsnog zelf moeten instellen, net als dat je dat nu voor Drupal moet doen. Een theme override is niets anders dan aangeven dat hoe theme een bepaald ding wel zal renderen. Stel dat Drupal niets zou uitvoeren, dan had je dat alsnog in je theme moeten zetten.

Daarnaast heb je altijd mensen die zeiken. De één vindt dat er te weinig classes en elementen zijn om enkel met CSS te stylen, terwijl de ander vindt dat het te veel is, want hij wil z'n markup zo clean mogelijk hebben. Het is een systeem waar iedereen aan en mee werkt, dus moet je compromissen sluiten. Deze discussie voor Views is een hele soap geworden, dus zo'n simpele situatie is het helaas niet.

Layout heeft trouwens een andere betekenis. Layouts maak je nog steeds in je CSS en daar heeft Drupals default markup geen praktische invloed op.

[Voor 18% gewijzigd door Mei op 26-01-2011 14:47]

[kwaakvaak_v2]

Jammer dat je kritiek gelijk afdoet als zeiken.. Dat is het grootste zwaktebod wat iemand in een discussie kan doen, maar dat terzijde.

Het probleem van drupal zit hem erin dat content vanaf het kleinste element naar het grootste element opgebouwd wordt. En dat is opzich prima als je idd niet anders gewent bent, of prima kan leven met de overdaad een html containers in je output. Echter ik vind, dat in controller (node/block/page/view whatever element) niet voor mij hoeft te bepalen dat ik perse een bepaalde DIV om mijn data moet hebben, En ja dat kun je regelen in een <theme_name>_theme() hook. Maar ik zou dat liever doen op de plek waar het hoort, en dat is een tpl.php zelf. Immers daar wordt bepaald hoe iets eruit moet zien, daar weet ik 100% in welke context ik die data moet/wil gebruiken.

Het grote 'probleem' van drupal, is dat er imho met een paar flinke oogkleppen op, teveel gekeken wordt naar de eindgebruiker. Die moet alles met sleur en pleur in elkaar kunnen klikken, en dat er dan wat extra dingen met css op display:none, of met een preg_replace in een theme functie uitgehaalt moet worden, dat wordt dan maar voor lief genomen.

Views zou een stuk minder complex zijn, als het gewoon een deed wat het redelijk goed kan, queries opbouwen en uitvoeren en dan ipv per element een tpl.php of theme functie aan te roepen, gewoon een ouderwetse array met data naar één tpl.php zou sturen zodat je met wat foreach'es die data prima kunt kleien zoals het nodig is.Dat zou elke fatsoenlijke theme builder een hoop gedoe schelen.

Gelukkig lijken er meer mensen in drupalland wakker te zijn geworden, en zijn er in D7 al redelijk wat verbetering doorgevoerd, en gelukkig biedt Drupal, hetzij wat krom, de mogelijkheid voor puristen en andere mensen die gewoon weten wat ze aan doen zijn, om data alsnog 'raw' op te halen en te gebruiken, en nog steeds alle voordelen van systeem te gebruiken.

[Mei]

kwaakvaak_v2 schreef op woensdag 26 januari 2011 @ 15:34:
Jammer dat je kritiek gelijk afdoet als zeiken.. Dat is het grootste zwaktebod wat iemand in een discussie kan doen, maar dat terzijde.

1) Ik doe kritiek niet af als zeiken. Ik zeg alleen dat er zeikerds zijn.
2) Ik zeg nergens dat jij zeikt.
3) Zelfs al zou ik dat wel zeggen of impliceren, laat jij je daardoor kennen? (Gezien de rest van je reactie gelukkig niet)

Het probleem van drupal zit hem erin dat content vanaf het kleinste element naar het grootste element opgebouwd wordt. En dat is opzich prima als je idd niet anders gewent bent, of prima kan leven met de overdaad een html containers in je output. Echter ik vind, dat in controller (node/block/page/view whatever element) niet voor mij hoeft te bepalen dat ik perse een bepaalde DIV om mijn data moet hebben, En ja dat kun je regelen in een <theme_name>_theme() hook. Maar ik zou dat liever doen op de plek waar het hoort, en dat is een tpl.php zelf. Immers daar wordt bepaald hoe iets eruit moet zien, daar weet ik 100% in welke context ik die data moet/wil gebruiken.

Het enige wat hook_theme() doet is tpl files of theme functions definiëren, zodat Drupal weet dat het daar rekening mee moet houden. Dit heeft verder niets te maken met hoe het themingproces in elkaar zit.

Het grote 'probleem' van drupal, is dat er imho met een paar flinke oogkleppen op, teveel gekeken wordt naar de eindgebruiker. Die moet alles met sleur en pleur in elkaar kunnen klikken, en dat er dan wat extra dingen met css op display:none, of met een preg_replace in een theme functie uitgehaalt moet worden, dat wordt dan maar voor lief genomen.

1 woord: doelgroep. Jouw problemen met de overdaad aan markup hebben verder niets met sleur en pleur te maken, maar met eindgebruikers die slechts met CSS zoveel mogelijk kunnen aanpassen. Of dit een goede ontwikkeling is, daar durf ik niets over te zeggen. Ik snap echter wel de redenatie erachter.

Views zou een stuk minder complex zijn, als het gewoon een deed wat het redelijk goed kan, queries opbouwen en uitvoeren en dan ipv per element een tpl.php of theme functie aan te roepen, gewoon een ouderwetse array met data naar één tpl.php zou sturen zodat je met wat foreach'es die data prima kunt kleien zoals het nodig is.Dat zou elke fatsoenlijke theme builder een hoop gedoe schelen.

Wederom 1 woord: performance. Ik heb zelf ook al met anderen gebrainstormd hierover, want idealiter wil je inderdaad één grote array met content en metadata, maar dat wordt simpelweg te traag.

Gelukkig lijken er meer mensen in drupalland wakker te zijn geworden, en zijn er in D7 al redelijk wat verbetering doorgevoerd, en gelukkig biedt Drupal, hetzij wat krom, de mogelijkheid voor puristen en andere mensen die gewoon weten wat ze aan doen zijn, om data alsnog 'raw' op te halen en te gebruiken, en nog steeds alle voordelen van systeem te gebruiken.

"Weten wat ze aan het doen zijn" is in mijn ogen net zo denigrerend als andere mensen zeikerds noemen. De wereld bestaat niet alleen uit professionals en zelfs de professionals zijn soms (vaak?) slechter dan de amateurs/hobbyisten. Daarnaast is het allemaal een kwestie van de doelgroep op welke je je richt. Wordt Drupal gemikt op hardcore ontwikkelaars die niets liever doen dan abstract en clean programmeren? Of op mensen die met point & click complexe sites in elkaar steken? Of juist op beginners, die een eenvoudige eigen blog willen opzetten voor hun reis naar het buitenland?

Het hele verhaal is wat ingewikkelder dan dat het in eerste instantie lijkt. Daarom is ook niet 1, 2, 3 een beste oplossing te geven.

[kwaakvaak_v2]

Wederom 1 woord: performance. Ik heb zelf ook al met anderen gebrainstormd hierover, want idealiter wil je inderdaad één grote array met content en metadata, maar dat wordt simpelweg te traag.

Ik weet niet wat nu meer performance gaat kosten, zeg dat je een view hebt met 20 velden en dus in het meest ongunstige geval 20 keer een theme() aan moet roepen om die velden te stijlen en dan nog 4 keer voor de wrappers rond die velden. Dat kunnen 24 lees aktie van disk zijn, of een wrapper waar je een array met het query result aan mee geeft. Waarom ik de metadata van views in een template nodig heb, ontgaat mij een beetje. Feit is dat een object in php 5.2 redelijk efficient intern wordt opgeslagen en het standaard bij reference is.

"Weten wat ze aan het doen zijn" is in mijn ogen net zo denigrerend als andere mensen zeikerds noemen

Dat is waar, en idd niet zo heel netjes van mij.

Wordt Drupal gemikt op hardcore ontwikkelaars die niets liever doen dan abstract en clean programmeren? Of op mensen die met point & click complexe sites in elkaar steken? Of juist op beginners, die een eenvoudige eigen blog willen opzetten voor hun reis naar het buitenland?

Daar komen denk ik de verschillende distributies die Dries graag ziet voor D7 boven drijven, probleem is daarbij alleen dat het voor het aanpassen van bepaalde abstractie lagen (zoals idd theming) er toch echt wat aan de core gehacked moet worden. En dat wil ik die arme kittens niet aan doen

Aan de andere kant, four kitchens doet het ook met pressflow, dus helemaal raar is het niet denk ik.

[Eusebius]

Even een vraag van Drupal.be hier pluggen:

In Dr7 heb ik een datefield die je meerdere keren kunt toevoegen per node. Dus 1 node, 10 datums. Als ik er een view van maak, laat hij steeds de eerste datum zien. De node wordt in de kalender wel 10 getoond en op de juiste plek, maar hinderlijk genoeg steeds met de eerste datum

Mogelijk zie ik iets over het hoofd, maar wat?

[Mei]

Heeft iedereen al gezien dat volgende week maandag 20 juni DrupalJam 2011 plaatsvindt? Toegang is gratis en kan zonder aanmelding. Wil je echter een lunch, dan kan je je nog tot en met vandaag aanmelden!

Volg ook @DrupalJam voor dagelijkse updates.

[MsG]

Is er ook een mogelijkheid om bij het menu-systeem van Drupal ipv dat hij na een nieuw menu-item hij die alfabetisch plaatst, het gewoon gaat van hoe later gemaakt hoe later in de lijst? Ik vind het zo contra-productief dat hij ze alfabetisch plaatst, omdat ik en de eindgebruiker waar ik iets voor maak een menu gewoon op volgorde invoert.

[kwaakvaak_v2]

zorgen dat je gewichten gebruikt als sortering ipv namen

[MsG]

Ja dat snap ik, maar dat is alsnog elke keer handmatig, en vrij abstract voor eindgebruikers imo. Er is niet iets instelbaars of een module waardoor het gewoon op volgorde van invoeren gaat?

[kwaakvaak_v2]

Je kunt altijd menu items drag'en in het menu edit scherm zelf, maar of er voor de node ook iets is.. Geen idee, nog nooit nodig gehad omdat ik vooral systemen maak die niet echt tree gebaseerd zijn.

[Eusebius]

MsG schreef op woensdag 13 juli 2011 @ 08:02:
Ja dat snap ik, maar dat is alsnog elke keer handmatig, en vrij abstract voor eindgebruikers imo. Er is niet iets instelbaars of een module waardoor het gewoon op volgorde van invoeren gaat?

Ken je deze? http://drupal.org/project/menu_editor Module brengt een paar stappen bij elkaar. Ik vind m altijd handig als ik een nieuwe site moet opzetten en snel menu's moet instellen.

[Voor 10% gewijzigd door Eusebius op 13-07-2011 10:26]

[MsG]

Die brengt al wat meer opties dat is wel handig inderdaad. En je kan dan een nieuwe pagina als menu-item doen. Vaak maak ik namelijk eerst het menu technisch werkend, maar dan moet je altijd moeilijk doen met neplinks.

Gebruiken jullie het standaardsysteem voor menu's ook gewoon voor de eindgebruiker? Ik mis een beetje die simpelheid in bediening voor gebruikers soms, die Joomla! (even los van dat dat technisch brak is) wel bied. Maar de modules zijn in Drupal weer veel geïntegreerder .

[Eusebius]

MsG schreef op woensdag 13 juli 2011 @ 12:23:
Die brengt al wat meer opties dat is wel handig inderdaad. En je kan dan een nieuwe pagina als menu-item doen. Vaak maak ik namelijk eerst het menu technisch werkend, maar dan moet je altijd moeilijk doen met neplinks.

Gebruiken jullie het standaardsysteem voor menu's ook gewoon voor de eindgebruiker? Ik mis een beetje die simpelheid in bediening voor gebruikers soms, die Joomla! (even los van dat dat technisch brak is) wel bied. Maar de modules zijn in Drupal weer veel geïntegreerder .

Is denk ik inherent aan Drupal. Met Lego begin je ook bij 0. Innovaties worden heel langzaam in de core opgenomen. In Dr7 kun je eindelijk eindeloos (nou ja..) fields aan contenttypes toevoegen. Heerlijk. In Dr6 had je daarvoor nog modules nodig.

[BramVroy]

Hello

Ik probeer met Drupal een taxonomy structuur i.c.m. fotogallerij te maken, maar mijn pogingen leiden tot niets.

Ik heb een content-type 'gallery' waaraan ik een taxonomy field heb toegevoegd zodat er moet gekozen worden tussen termen in m'n taxonomy, het gaat om de volgende termen:

• foto's
• foto's 2004
• foto's 2005
• foto's 2006
• filmpjes
• filmpjes 2005
• filmpjes 2006
• filmpjes 2007

"foto's" en "filmpjes" zijn parents van de termen eronder.

Nu zo ik graag willen dat er in het hoofdmenu twee items staan ("foto's" en "filmpjes"; heb ik reeds manueel toegevoegd - gelinkt aan de taxonomy pagina's die automatisch aangemaakt werden) en dat als iemand op bv. "foto's" klikt naar de fotopagina gaat. Daar ziet hij/zij dan kleine previews van de pagina's lager in de structuur van de taxonomy (foto's 2004, foto's 2005 etc. - vandaar de taxonomy terms "foto's 2004" etc.) Daar kan dan verder worden geklikt naar dat album naar keuze en daarna nog eens naar de activiteit.

Ik dacht eerst met taxonomy de pagina's aan te maken (gebeurt automatisch) en dan als de content toegevoegd via de content type 'gallery' en met de juiste tag komt het wel op z'n plaats, maar ik weet niet hoe ik dan de pagina-in-paginastructuur krijg. Dus hoe ik het zou willen: http://i52.tinypic.com/zn68ag.png de pijlen stellen 'moet gepreviewd worden in' en de 'activiteiten' stelt meedere items voor (die per jaar verschillen).

Hulp welkom, ik ga er zelf nog wat achter zoeken! (Gevraagd op 9lives en Tweakers)

EDIT: aan de admins: ik heb voor te posten even gezocht naar 'drupal' om te kijken waar de andere topics ivm Drupal stonden, maar die staan in verscheidene subfora, dus ik post deze bij web. Denk deze hier het beste past.
Merged naar [Ervaringen] Het grote Drupal-topic

[Voor 14% gewijzigd door RobIII op 28-08-2011 20:51]

[MsG]

Ik heb een view gemaakt welke mij een nodelijst geeft van mijn zelfgemaakte contenttypen.

Deze view heb ik gekoppeld aan een menu-item "accommodaties".

Ik wil echter dat alle inhoud in deze view onder accommodaties valt qua structuur.

Momenteel is het zo:

Home > Accommodaties

Waar dan de nodes staan van de accomodaties.

Als ik echter op zo'n accommodatie klik valt Accommodaties er qua hierarchie buiten, dus zo:

Home > Accommodatie 1

Hoe krijg ik mijn structuur zo:

Home > Accommodaties > Accommodatie 1

Iemand een idee?

Hoe geven jullie zelf structuur in jullie sites? Ik vind het menu-systeem nog wat raar werken bij Drupal namelijk.

[kwaakvaak_v2]

Je moet het menu van drupal meer zien als de router uit een MVC applicatie. Je menu item hangt aan een URL, die url hangt aan een action en die geeft content terug.

Makkelijkste om iets voor elkaar te krijgen is of zelf je hook_menu implementeren, of je view zo instellen dat ie met een wildcard iets kan. (iets als /accomodatie/%var )

[Mei]

Views maakt lijstjes van dingen, geen menu items. Als je per se zoveel menu items wil (beetje mee oppassen: meer menu items > langzamere site), dan moet je per 'menu item' (content type?) een aparte view maken. Het beste is echter gewoon als je een browsable view in elkaar zet.

[Eusebius]

Mei schreef op zondag 04 december 2011 @ 17:35:
Views maakt lijstjes van dingen, geen menu items. Als je per se zoveel menu items wil (beetje mee oppassen: meer menu items > langzamere site), dan moet je per 'menu item' (content type?) een aparte view maken. Het beste is echter gewoon als je een browsable view in elkaar zet.

Maar: op een goed gevulde site wil je een goede structuur hebben. Wat is 'niet veel menu-items'? En hoe houd je de structuur duidelijk?

[kwaakvaak_v2]

Ik vraag mij ook af hoe veel menu items een site traag maken? Ik heb dat bij de meeste drupal sites die ik opgeleverd heb eigenlijk nooit echt gemerkt. Wel dat bepaalde views, en vooral het niet fatsoenlijk gebruik maken van de cache een site traag maakt.

Maar menu items (hook_menu) worden als het goed is alleen maar opnieuw geladen als je heel bewust de menu cache flushed.

Overigens als ik het zo lees, wil msg vooral een soort clickpath maken en dat ruikt nog steeds het meeste naar views-arguments. (http://www.drupalove.com/...ng-views-arguments-drupal) waarbij je het node-type het argument laat zijn. Hoef je niet per node type een eigen view te maken.

[MsG]

Maar als ik bijvoorbeeld naar www.drupal.nl ga en dan naar evenementen, dan krijg ik een lijst met evenementen

en als ik dan op een item daaronder klik krijg ik /evenementen/evenement

Maar hetzelfde probleem als wat ik had: namelijk het menu-item evenementen is dan niet meer actief, wat onduidelijk is en niet wat ik wil.

Ik zal eens naar views-arguments kijken. Het alternatief is dus programmeren? Dat is voor mij niet echt een optie :-P.

Het ging trouwens niet per se om menu-items, maar wel hoe de hierarchie er uitziet. Als de accommodaties zelf niet onder "accommodaties" vallen, dan is het menu-item dus ook niet actief.


Iemand trouwens ook ervaring met Feeds XPath? Ik wil de te importeren nodes nog een hardcoded waarde geven voor een veld die niet uit een feed zelf komt, bijvoorbeeld de feed-aanbieder.

[Voor 13% gewijzigd door MsG op 05-12-2011 14:31]

[Marc3l]

MsG schreef op zondag 04 december 2011 @ 00:21:
Ik heb een view gemaakt welke mij een nodelijst geeft van mijn zelfgemaakte contenttypen.

Deze view heb ik gekoppeld aan een menu-item "accommodaties".

Ik wil echter dat alle inhoud in deze view onder accommodaties valt qua structuur.

Momenteel is het zo:

Home > Accommodaties

Waar dan de nodes staan van de accomodaties.

Als ik echter op zo'n accommodatie klik valt Accommodaties er qua hierarchie buiten, dus zo:

Home > Accommodatie 1

Hoe krijg ik mijn structuur zo:

Home > Accommodaties > Accommodatie 1

Iemand een idee?

Hoe geven jullie zelf structuur in jullie sites? Ik vind het menu-systeem nog wat raar werken bij Drupal namelijk.

Pathauto geprobeerd?