:strip_exif()/i/1306492847.png?f=thumbmini)
/u/241825/Avatar_for_terrorist.png?f=community){kind=avatar}
Denk om uw spatiegebruik. Dit scheelt Tweakers.net kostbare databaseruimte! | Groninger en geïnteresseerd in Domotica? Kom naar DomoticaGrunn
:strip_icc():strip_exif()/u/393369/crop55d593566408c.jpeg?f=community)
:strip_icc():strip_exif()/u/112202/lighthouse.jpg?f=community)
Ok thanks, die ziet er wel interessant uit ja:
Misschien is dit wat?
http://drupal.org/project/draggableviews
Even wat meer info:
Je maakt dus een extra view(of gewoon een page bij je bestaande view), die een draggable table met de items laat zien. De volgorde die daar bij hoort kun je vervolgens weer bij je andere view gebruiken. Werkt echt goed
Hoe updaten jullie Drupal trouwens? Gewoon nieuwe bestanden over de oude kopieren? Of halen jullie echt alles eerst weg?
Mixed Reality dev
:strip_icc():strip_exif()/u/146648/full.jpg?f=community)
Dat ligt aan je terminal en je PHP CLI-instellingen. Onder Linux/OS X gaat dat (bijna) altijd vanzelf. Onder Windows moet je wat extra dingen doen, omdat er standaard geen terminal bij zit die enigszins kan wat de varianten onder andere systemen wel kunnen.:
Ik merk het inderdaad bij het kijken naar een Drush tutorial. Ik kan geen commands uitvoeren helaas
Dat wordt dus handmatig updaten... pfff.
:strip_icc():strip_exif()/u/304716/enforcer_small.jpeg?f=community)
beetje FTP client kan wel sync denk ik. Maar goed, een drupal site op een shared hosting omgeving van 1,95 per maand is sowieso geen feestje als je meer bezoekers hebt dan enkel je oma
Driving a cadillac in a fool's parade.
Denk om uw spatiegebruik. Dit scheelt Tweakers.net kostbare databaseruimte! | Groninger en geïnteresseerd in Domotica? Kom naar DomoticaGrunn
:strip_exif()/u/145304/nick.gif?f=community)
Tot nu toe nog geen problemen gehad met hosting van 1,09 per maand. Werkt snel en heeft alles wat ik nodig heeft ;p Alleen geen terminal toegang, maar dat zou je niet nodig moeten hebben. WordPress kan het ook 
Maar goed, ik zie dat sommige 'grote' websites ook in Drupal gebouwd zijn, dus schijnbaar heeft het wel ptoentie.. dus ik zal het toch leren gebruiken
Maar goed, ik zie dat sommige 'grote' websites ook in Drupal gebouwd zijn, dus schijnbaar heeft het wel ptoentie.. dus ik zal het toch leren gebruiken
Je hebt het ook niet perse nodig, maar je kan er wel erg veel tijd mee besparen. Veel dingen kun je opeens in de commandline doen.:
Tot nu toe nog geen problemen gehad met hosting van 1,09 per maand. Werkt snel en heeft alles wat ik nodig heeft ;p Alleen geen terminal toegang, maar dat zou je niet nodig moeten hebben. WordPress kan het ook
Maar goed, ik zie dat sommige 'grote' websites ook in Drupal gebouwd zijn, dus schijnbaar heeft het wel ptoentie.. dus ik zal het toch leren gebruiken
Maar volgens mij is Drush ook vooral voor lokaal gebruik.
:strip_exif()/u/14385/malibu.gif?f=community)
“The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.”
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers.
Uiteraard, ik ben het helemaal met je eens; dit probleem moet je oplossen door alle content om te zetten zodat de talen kloppen, niet d.m.v. hacks.
Misschien verkeerd, maar ik kreeg de indruk dat Menesis zelf ook wel weet dat omzetten de beste oplossing is en eigenlijk opzoek is naar een quick fix.
Als ik het verkeerd heb: mijn excuus.
Misschien verkeerd, maar ik kreeg de indruk dat Menesis zelf ook wel weet dat omzetten de beste oplossing is en eigenlijk opzoek is naar een quick fix.
Als ik het verkeerd heb: mijn excuus.
[ Voor 7% gewijzigd door OkkE op 15-02-2013 10:17 ]
“The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.”
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers.
Ik gok zomaar dat taal het kleinste probleem gaat zijn als je gaat upgraden hoor
Maar los van dat, als je pagina's in verschillende talen in je systeem hebt zitten en je wilt gewoon een light-weight taal optie zonder dat je alle vertaal i8n/i10n crap erbij moet nemen is de snelste optie gewoon een extra veld in je entity(lees content type/node) te maken met twee taal opties. En die gebruiken om de meta tags in je template te vullen. En dat laatste lukt je niet als je alles 'the drupal way' via de GUI wilt regelen, maar gaat prima als je niet bang bent om ergens een print render($content.field_languagedingske); te doen
Persoonlijk kies ik bijna altijd ervoor om bepaalde dingen als dit op deze manier te doen ipv een UI module en dan nog 5 andere modules te moeten installeren om iets te maken wat met een simpele echo in php (of twig for drupal
) ook kan. Maar dat is niet helemaal des drupals schijnt
Driving a cadillac in a fool's parade.
Het probleem met dat soort grappen is dat Drupal core niet de enige module is die van de taalinstellingen gebruikmaakt. Ik beheer bijvoorbeeld enkele contributed modules die dit ook doen. Sommige dingen zijn niet voor niets centraal geregeld:
[...]
Ik gok zomaar dat taal het kleinste probleem gaat zijn als je gaat upgraden hoor
Maar los van dat, als je pagina's in verschillende talen in je systeem hebt zitten en je wilt gewoon een light-weight taal optie zonder dat je alle vertaal i8n/i10n crap erbij moet nemen is de snelste optie gewoon een extra veld in je entity(lees content type/node) te maken met twee taal opties. En die gebruiken om de meta tags in je template te vullen. En dat laatste lukt je niet als je alles 'the drupal way' via de GUI wilt regelen, maar gaat prima als je niet bang bent om ergens een print render($content.field_languagedingske); te doen
Persoonlijk kies ik bijna altijd ervoor om bepaalde dingen als dit op deze manier te doen ipv een UI module en dan nog 5 andere modules te moeten installeren om iets te maken wat met een simpele echo in php (of twig for drupal
Als je het denkt beter te weten en er een hack in wil stoppen, prima, maar documenteer dat dan en besef dat als het mis gaat, je er waarschijnlijk meer tijd in moet stoppen dan in eerste instantie nodig was geweest. Dat is dan gewoon een afweging die je neemt. Veel mensen denken het echter beter te weten terwijl dat eigenlijk niet zo is. Alsnog niet mijn probleem, maar klaag dan niet
Edit: om even terug te komen op Menesis' probleem: dit ligt dus aan je interface/page language en NIET aan je content language.
[ Voor 3% gewijzigd door Mei op 15-02-2013 10:53 ]
Ik klaag ook niet, ik concludeer alleen dat soms het overdreven is om een heel vertaal systeem erin te hangen als je voor de rest nergens die taal opties gebruikt. Heeft niets te maken met het beter denken te weten, maar vooral met het gebruiken van je eigen verstand ipv als een lemming achter de meute op D.O aan te rennen en een shitload aan modules aan te zetten, omdat het misschien ooit hypothetisch gezien nog wel eens voor kan komen dat je site in het swahili vertaald moet worden, met bijpassende performance issues vanwege het lineare karakter van de drupal code.
Hopelijk gaat D8 dat serieus verbeteren en enkel maar in laden wat nodig is voor het request af te handelen
Als het enkel om pagina's gaat die in een afwijkende taal kunnen staan t.o.v van andere paginas, en je hier geen panels,views,context of wat voor systeem voor nodig hebt om op basis van die taal dingen te moeten selecteren etc, het niet altijd nodig hoeft te zijn om de soms nodeloos complexe drupal best practices te volgen. Maar idd dat is een afweging die je per situatie moet nemen. Zoals met elk drupal project moet je van te voren goed bedenken wat de context van je project gaat worden, en daar ook rekening mee houden.
Ik maak redelijk wat sites waar de 'voorkant' in het nederlands is, en het beheer gedeelte in het standaard engels staat. En daar is het imho niet noodzakelijk om een volledig vertaal systeem met talen, taalkeuze's en interface vertaling voor in te zetten als het puur en alleen erom gaat dat de meta tags goed weg gezet worden. Tuurlijk haal ik waar nodig wel door de de t() functie heen, maar dat is meer om de beheerder de optie te geven labels en andere dingen makkelijk te veranderen dan dat het echt voor taal gebonden zaken is.
En ja ik beheer ook wat modules, vooral voor velden en templating, en daar wordt netjes rekening gehouden de taal. Maar dat gaat redelijk vanzelf als je de field API gewoon netjes volgt dus er bestaat geen excuus voor ontwikkelaars omdat niet te doen. En ja ik ben behoorlijk pro-drupal voor veel projecten, maar ook kritisch. En dat laatste heb ik gemerkt trekken de meeste drupal-fanatici erg slecht.
Hopelijk gaat D8 dat serieus verbeteren en enkel maar in laden wat nodig is voor het request af te handelen
Als het enkel om pagina's gaat die in een afwijkende taal kunnen staan t.o.v van andere paginas, en je hier geen panels,views,context of wat voor systeem voor nodig hebt om op basis van die taal dingen te moeten selecteren etc, het niet altijd nodig hoeft te zijn om de soms nodeloos complexe drupal best practices te volgen. Maar idd dat is een afweging die je per situatie moet nemen. Zoals met elk drupal project moet je van te voren goed bedenken wat de context van je project gaat worden, en daar ook rekening mee houden.
Ik maak redelijk wat sites waar de 'voorkant' in het nederlands is, en het beheer gedeelte in het standaard engels staat. En daar is het imho niet noodzakelijk om een volledig vertaal systeem met talen, taalkeuze's en interface vertaling voor in te zetten als het puur en alleen erom gaat dat de meta tags goed weg gezet worden. Tuurlijk haal ik waar nodig wel door de de t() functie heen, maar dat is meer om de beheerder de optie te geven labels en andere dingen makkelijk te veranderen dan dat het echt voor taal gebonden zaken is.
En ja ik beheer ook wat modules, vooral voor velden en templating, en daar wordt netjes rekening gehouden de taal. Maar dat gaat redelijk vanzelf als je de field API gewoon netjes volgt dus er bestaat geen excuus voor ontwikkelaars omdat niet te doen. En ja ik ben behoorlijk pro-drupal voor veel projecten, maar ook kritisch. En dat laatste heb ik gemerkt trekken de meeste drupal-fanatici erg slecht.
Driving a cadillac in a fool's parade.
Mijn punt was dat men niet moet klagen als men het beter denkt te weten, maar dat niet het geval blijkt te zijn. Weet je het beter en doe je het anders? Prima, go ahead. Sla je adviezen en best practices in de wind en blijkt het later verkeerd te gaan zonder dat jezelf de kennis hebt om het te fiksen of bereid bent mensen in te huren om dat voor je te doen, dan is het toch écht je eigen stomme schuld.
Je overdrijft hier een beetje. Ja, je hebt overhead als je slechts wat ander taalopties aan wil bieden aan gebruikers, omdat dit historisch gezien samen ging met het vertalen van de user interface. Daarnaast is alles volgens mij redelijk goed geregeld, alhoewel niet altijd even consistent, wat betekent dat je voor elke scheet een andere vertaalmodule nodig hebt. Maakt dit het onoverzichtelijker? Ja. Is dit per se slecht voor bijvoorbeeld performance? Nee.
Er zijn wat dat betreft weinig verschillende opties. Content translation zit in core en dat werkt mooi samen met de language negotiation die óók in core zit. Redelijk weinig overhead.
Waarom zouden de meta tags anders ingesteld moeten worden als de daadwerkelijke taal niet anders is? Op het moment dat je de UI in een andere taal wil, zet je Locale aan, en dan volgen de meta tags de paginataal.
Moh, fields zijn ook maar tot op zekere hoogte leuk. Ik doe genoeg dingen waarbij ze niets toevoegen en ik direct global $language moet aanspreken (waarin de paginataal staat). Daarnaast zijn D8 config entities helaas niet fieldable vanwege een paar mooie ontwikkelingen (config on file), en de historische (IMHO véél te strakke) relatie tussen entities en fields (EFQ).En ja ik beheer ook wat modules, vooral voor velden en templating, en daar wordt netjes rekening gehouden de taal. Maar dat gaat redelijk vanzelf als je de field API gewoon netjes volgt dus er bestaat geen excuus voor ontwikkelaars omdat niet te doen. En ja ik ben behoorlijk pro-drupal voor veel projecten, maar ook kritisch. En dat laatste heb ik gemerkt trekken de meeste drupal-fanatici erg slecht.
Ik ben ook kritisch op Drupal, maar waar je als Drupalontwikkelaar wel bij stil moet staan, is de vraag "Waarom gebruik ik het eigenlijk?". Ga je hacken, dan raak je allerlei voordelen als interoperability en upgradability kwijt, terwijl dat juist belangrijke redenen voor het gebruik van dit soort software is.
Ik heb wel eens een opdracht gekregen waarbij ik als noodoplossing ingeschakeld werd, omdat de hoofdontwikkelaar iets niet kon en ze tijdens het gehele traject al behoorlijke vertraging opgelopen hadden. Tot zo ver niets aan de hand. De vorige ontwikkelaar had een one-page checkout in elkaar gehackt. Die waren wel mogelijk, maar niet volgens de eisen van de klant. Prima, maar het was niet gedocumenteerd. Ik werd ingehuurd, omdat ik als Drupal dev wel zou weten hoe ik hun Drupal site moest fiksen. Dat was ook zo, totdat ik bij de implementatie tegen die ongedocumenteerde hacks aan liep. Poef, daar gingen de voordelen van het gebruik van Drupal, simpelweg vanwege incompetentie van de vorige ontwikkelaar, en kostte het de klant flink wat extra om last-minute alles nog goed te laten implementeren (kosten die grotendeels veroorzaakt werden doordat de klant een klootzak van een yup was, maargoed
)
Dat kom ik helaas ook redelijk vaak tegen, probleem is vaak dat er dan idd te vaak hack op hack op hack gestapeld is en er bijna niets meer te redden is zonder een forse ingrijp (meestal gepaard met content conversie/migratie). En dat kost geld, en dan is het ineens minder belangrijk
Had er paar maanden terug eentje die vroeg ik of ik ff wat kon fixen aan een site, bleek dat de oorspronkelijke developer(s) blijkbaar entity field query niet had gevonden en zelf dus een volledig erop lijkend systeem er tegen aan had geplakt met kilo's aan glue code. Project toch maar afgewezen, weiger mijn vingers te branden aan dit soort constructies.
Per se misschien niet , maar absoluut gezien wordt bij elke request module_invoke_all('init'); uitgevoerd en dat is relatief zware functie omdat ie de eerste keer letterlijk alle modules moet laden en niet alle modules even 'slim' geschreven zijn en alleen in de .module hebben staan wat nodig is (en ja daar maak ik mij ook wel eens schuldig aan)
Tuurlijk helpen dingen als APC hier prima bij, maar het blijft een relatief dure operatie, en dat is iets wat met een goede implementatie van DIC en namespaces wel degelijk opgelost kunnen worden. De DIC kan ala symfony2 als compiled class worden opgeslagen en bevat enkel maar verwijzingen naar services die pas verder ge-initializeerd worden en dus via autoloading worden geladen als het nodig is.
Dat dit nog wat problemen gaat geven in drupal land is zeker..
Driving a cadillac in a fool's parade.
:strip_icc():strip_exif()/u/86599/crop681cb5088171b_cropped.jpg?f=community)
Hmm, ik heb wel het idee dat ik op de goede richting zit, maar het wil allemaal net niet lukken.
Ik heb zowel mijn Pages als mijn Products een Taxonomy veld gegeven (field_category). Dan zou ik toch met contextual filters / relations dit moeten kunnen koppelen toch? Dus alle Products weergeven, die dezelfde term hebben.
Edit: Ah gevonden:
Contextual filter: Content: Category:
- Default value: texonomy term ID from URL
- Load default filter form nod page, .. aanvinken
- Vocabulary categories kiezen.
En dan validation uitvoeren voor Taxonomy Term, met type Term ID. Als het niet goed is, view verbergen.
En een Contextual relation toevoegen voor Content: Taxonomy terms on node, met ook die vocabulary.
Nu lijkt het te werken (Gewoon block op alle pagina's van het content type Basic Page)
Ik heb zowel mijn Pages als mijn Products een Taxonomy veld gegeven (field_category). Dan zou ik toch met contextual filters / relations dit moeten kunnen koppelen toch? Dus alle Products weergeven, die dezelfde term hebben.
Edit: Ah gevonden:
Contextual filter: Content: Category:
- Default value: texonomy term ID from URL
- Load default filter form nod page, .. aanvinken
- Vocabulary categories kiezen.
En dan validation uitvoeren voor Taxonomy Term, met type Term ID. Als het niet goed is, view verbergen.
En een Contextual relation toevoegen voor Content: Taxonomy terms on node, met ook die vocabulary.
Nu lijkt het te werken
(Gewoon block op alle pagina's van het content type Basic Page)
[ Voor 43% gewijzigd door Barryvdh op 07-03-2013 14:22 ]
Ik probeer een portfolio overzichtje te bouwen, waarbij de portfoliostukken in een categorie zijn opgedeeld (WEB en 3D bijv.) dat zijn uiteraard taxonomy terms.
Die terms hebben ook een icoontje wat ik graag wil tonen.
1. ik probeer dus een term op een node als plaatje weer te geven. Dit lukt niet: de taxonomy image module van D6 hebben ze afgekapt omdat het zonder al te veel moeite met drupal 7 zou moeten kunnen. Maar na heeel veel geklooi met de entity module ben ik echt geen steek verder... Wie heeft de gouden tip?
2. vervolgens wil ik die term ook als plaatje weergeven in views (een view die een aantal nodes laat zien), maar dat lukt ook niet..
Ik heb het gevoel dat ze dingen nu iets te ingewikkeld aan het maken zijn bij Drupal... Of zie ik nu iets over het hoofd?
Die terms hebben ook een icoontje wat ik graag wil tonen.
1. ik probeer dus een term op een node als plaatje weer te geven. Dit lukt niet: de taxonomy image module van D6 hebben ze afgekapt omdat het zonder al te veel moeite met drupal 7 zou moeten kunnen. Maar na heeel veel geklooi met de entity module ben ik echt geen steek verder... Wie heeft de gouden tip?
2. vervolgens wil ik die term ook als plaatje weergeven in views (een view die een aantal nodes laat zien), maar dat lukt ook niet..
Ik heb het gevoel dat ze dingen nu iets te ingewikkeld aan het maken zijn bij Drupal... Of zie ik nu iets over het hoofd?
Mixed Reality dev
:strip_icc():strip_exif()/u/41669/lego-60.jpg?f=community)
@Mei: aha ok. Daarmee ben je dus afhankelijk van de module bouwer begrijp ik..
@ lennart: Wat is een OG?
@ lennart: Wat is een OG?
Mixed Reality dev
OrganicGroup:
@Mei: aha ok. Daarmee ben je dus afhankelijk van de module bouwer begrijp ik..
@ lennart: Wat is een OG?
==
hoi
:strip_icc():strip_exif()/u/77332/crop5e54ec42433bc_cropped.jpeg?f=community)
Nee. Developers moeten het gewoon correct doen. Is dat niet gedaan, dan is het een bug.:
@Mei: aha ok. Daarmee ben je dus afhankelijk van de module bouwer begrijp ik..
@ lennart: Wat is een OG?
:strip_icc():strip_exif()/u/205841/crop5770e8a391a18_cropped.jpeg?f=community)
Denk om uw spatiegebruik. Dit scheelt Tweakers.net kostbare databaseruimte! | Groninger en geïnteresseerd in Domotica? Kom naar DomoticaGrunn
Denk om uw spatiegebruik. Dit scheelt Tweakers.net kostbare databaseruimte! | Groninger en geïnteresseerd in Domotica? Kom naar DomoticaGrunn
Is er een manier om de alias van een pagina als contextual filter te gebruiken in views?
Voor een site probeer ik namelijk via 2 verschillende aliassen naar een pagina te verwijzen:
[list]
• site.com/alias (=normale node)
• site.com/embed/alias (=gekoppeld aan een view)
[/list]
De view heeft als path uiteraard /embed. Maar nu lukt het niet om het juiste contextual filter te vinden. Met NID lukt het wel, maar ik zou liever de alias invoeren ipv NID...
het is dus voor een funtie zoals youtube dat ook heeft om content te embedden via een iframe. Mijn iframes zullen naar /embed/paginanaam verwijzen...En natuurlijk moet alles onder embed worden uitgesloten van searchbots
Ben alweer een stuk verder, loop echter nog tegen een onbekend probleem aan. Ik post later een screenshotje!
Voor een site probeer ik namelijk via 2 verschillende aliassen naar een pagina te verwijzen:
[list]
• site.com/alias (=normale node)
• site.com/embed/alias (=gekoppeld aan een view)
[/list]
De view heeft als path uiteraard /embed. Maar nu lukt het niet om het juiste contextual filter te vinden. Met NID lukt het wel, maar ik zou liever de alias invoeren ipv NID...
het is dus voor een funtie zoals youtube dat ook heeft om content te embedden via een iframe. Mijn iframes zullen naar /embed/paginanaam verwijzen...En natuurlijk moet alles onder embed worden uitgesloten van searchbots
Ben alweer een stuk verder, loop echter nog tegen een onbekend probleem aan. Ik post later een screenshotje!
[ Voor 8% gewijzigd door Menesis op 24-04-2013 16:08 ]
Mixed Reality dev
Denk om uw spatiegebruik. Dit scheelt Tweakers.net kostbare databaseruimte! | Groninger en geïnteresseerd in Domotica? Kom naar DomoticaGrunn
Ok cool, ik ben nu met de hosting aan het overleggen of zij cron kunnen runnen (zodat bezoekers niet de dupe worden van cron wachttijden...)
Ik probeerde een tijdje terug iets met views, en ik vermoed haast dat het een bug is in views. Het kan natuurlijk ook aan mij liggen, maar:
Hiermee probeer ik simpelweg een node te benaderen via zijn alias, zoiets als:
site.com/embed/aliaslalala
Het werkt echter niet. Het werkt wél als ik de nodeID invul..
site.com/embed/2
(alias van de nodes is in de vorm site.com/alias)
Ik heb al gespeeld met het path component nummertje...
Ik probeerde een tijdje terug iets met views, en ik vermoed haast dat het een bug is in views. Het kan natuurlijk ook aan mij liggen, maar:
Hiermee probeer ik simpelweg een node te benaderen via zijn alias, zoiets als:
site.com/embed/aliaslalala
Het werkt echter niet. Het werkt wél als ik de nodeID invul..
site.com/embed/2
(alias van de nodes is in de vorm site.com/alias)
Ik heb al gespeeld met het path component nummertje...
Mixed Reality dev
:strip_icc():strip_exif()/u/261244/avatar4-64x64.jpg?f=community){kind=avatar}
Weet iemand hoe je zoiets in Drupal maakt?
Ik ben inmiddels aardig bekend met views en zit te spelen met better exposed filters en exposed filters, maar ik kom niet echt in de buurt..
Wat je hier ziet is een betaalde ik geloof zelfs externe Drupal search module...
Ik ben inmiddels aardig bekend met views en zit te spelen met better exposed filters en exposed filters, maar ik kom niet echt in de buurt..
Wat je hier ziet is een betaalde ik geloof zelfs externe Drupal search module...
[ Voor 4% gewijzigd door Menesis op 16-06-2014 22:47 ]
Mixed Reality dev
Als ik erop Google, dan kom ik bij deze module: Facet API.
Ziet er bijna exact hetzelfde uit, maar dan gratis.
Ziet er bijna exact hetzelfde uit, maar dan gratis.
:strip_icc():strip_exif()/u/303510/brooklyn-bridge-hd-wallpaper-2560x1600.jpg?f=community)
Ik ben ook begonnen met een drupal site, de bedoeling is dat ik mijn bestaande html/css/javascript site ombouw naar een site volledig in drupal.
Momenteel ben ik de 70! Tutorial video’s van LevelUpTuts aan het volgen, ik zit nu nog maar aan de 12de maar ik vind wel dat alles heel duidelijk en vlot uitgelegd wordt.
Mijn eerste indruk van Drupal is dat het heel leuk werken is bij het bouwen van een site, je hebt ook super veel mogelijkheden lijkt het wel.
Momenteel ben ik de 70! Tutorial video’s van LevelUpTuts aan het volgen, ik zit nu nog maar aan de 12de maar ik vind wel dat alles heel duidelijk en vlot uitgelegd wordt.
Mijn eerste indruk van Drupal is dat het heel leuk werken is bij het bouwen van een site, je hebt ook super veel mogelijkheden lijkt het wel.
Dank voor je reactie. We moeten idd de formulier zelf maken/ontwerpen en je voorstel voor entityform ben ik nu aan het bekijken. De vragen en antwoorden krijgen we natuurlijk en wel in een doc bestand. Dus nu alleen nog uitzoeken hoe ik de formulier dan aan de server kan koppelen(SOAP 1.2).
Ook voor HTTP POST heb ik gekeken en deze code gevonden
code:
1
2
3
4
5
6
7
8
9
10
| $data = 'name=value&name1=value1';
$options = array(
'method' => 'POST',
'data' => $data,
'timeout' => 15,
'headers' => array('Content-Type' => 'application/x-www-form-urlencoded'),
);
$result = drupal_http_request('http://somewhere.com', $options); |
Echter kan nergens vinden waar je dan deze code moet injecteren/toevoegen.
Is het de bedoeling dat het in een bestaande bestand toe wordt gevoegd (bv common.inc zoals ze hier?) of moet er een nieuwe bestand worden aangemaakt?
En ook hiervoor kan ik nergens vinden hoe men dan de formulier aan de server koppelt of lees ik ergens overheen?
Dat eerste geld voornamelijk voor de core, voor contrib is dit een andere verhaal vind ik, maar hangt sterkt af van de context waarin je iets moet aanpassen. Maar als je een module moet aanpassen omdat er een bug of iets niet goed in zit, fork deze dan of zorg er voor dat je een patch maakt zodat je, na een update van die module niet gelijk je veranderingen kwijt bent.
Het is en blijft altijd een afweging of je direct 1 functie aanpast of je een module maakt en het bos der _hooks in gaat. Soms is het ene gewoon sneller en stabieler. Vooral omdat je maar tot zekere hoogte zekerheid hebt over de volgorde waarin hooks aangeroepen worden.
Maar in het geval van de functionaliteit die hierboven beschreven wordt, dat roept aan alle kanten om een custom module
[ Voor 6% gewijzigd door kwaakvaak_v2 op 14-11-2014 09:20 ]
Driving a cadillac in a fool's parade.