[Ervaringen] Het grote Drupal-topic

[Menesis]

Weet iemand een goede oplossing om een soort global variabele als een field te gebruiken?

Voor een x aantal nodes heb ik een datumveld dat allemaal dezelfde datum moet zijn. Echter kan die datum nog veranderen, maar ik wil dat niet x keer hoeven te veranderen
Zou mooi zijn om een soort referentie in een field te zetten en die dan 1x aan te passen

[kwaakvaak_v2]

gewoon met een entity field query in code op lossen Drupal betekend niet dat je alles altijd maar met een GUI moet oplossen. Soms kun je het sneller en beter voor elkaar krijgen door even snel een custom module of drush scriptje te maken.

[Menesis]

ok thanks
Ben inmiddels met iets heel anders bezig: een inschrijfsysteem voor workshop voor een klein festivalletje (allemaal vrijwilligers).

Er zijn meerdere soorten workshops en elke soort start om het uur. Mensen mogen zich eigenlijk maar voor 1 type workshop inschrijven.

Momenteel is elk tijdslot een aparte node.

Ik gebruik node_registrations. Het enige wat mist is het inbouwen van die limiet. Ik zit te denken:
1. elke workshop van een taxonomy tag voorzien en dan checken of die tag al voorkomt in de node_registrations van de user
2. of elk type workshop een ander content type maken en dan checken of het content type niet al voorkomt in de registrations van de user..

Op Drupal.org kreeg ik antwoord hoe ik het deels kan oplossen:
Implement hook_node_registration_access() (to hide form and page/tab) or hook_form_node_registration_form_alter() to add a custom validation error/message.

Maar ik weet nog niet hoe ik kan checken of een taxonomy tag of content type al in de registrations van een gebruiker voorkomt. Ik denk dat het een die-hard DB query moet worden oid?

[Marc3l]

Ken deze module niet maar ga een poging doen, heb even de module files bekeken.

Met de functie _node_registration_event_nodes kan je alle event nodes ophalen.
Over deze nodes loop je dan en voer je de volgende functie uit _node_registration_user_registered($node, $account = NULL). Die kijkt of je bent ingeschreven voor een bepaald event.

Als daar niets uitkomt weet je dat de user nog niet ingeschreven is op events.
Functies zijn te vinden in bestand node_registration.api.inc

[Menesis]

Op Drupal kreeg ik ook antwoord van de maker van node registrations:
1. Fetch all nids from nodes that have this term, using an EntityFieldQuery
2. Fetch all registrations from this user with these nids
3. If there are any, they have already registered for this type
Hoewel ik Drupal wel aardig onder de knie heb ben ik nogal noob als het op development aankomt.

Afgezien van de check weet ik niet precies wanneer die check moet worden uitgevoerd.

Nu heb ik een testje dat inderdaad aangeroepen wordt als ik me registreer:

code:

function limit_registrations_by_taxonomy_field_attach_submit(){
    
    drupal_set_message(t('test'), 'error');
    
}

edit: heb grote moeite om de taxonomy term van de huidige pagina te laden.
geprobeerd:

code:

$test1 = taxonomy_term_load(arg(2));
$test2 = menu_get_object('taxonomy_term', 2);
$test3 = $node->field_term['und']['0']['tid'];

tips iemand?

[Voor 52% gewijzigd door Menesis op 03-05-2015 19:52]

[Menesis]

Ben weer wat verder maar:
1. Niet zeker wanneer mijn module te starten (momenteel heb ik: function limit_registrations_by_taxonomy_field_attach_submit ($ knooppunt) {)
In de documentatie van node registrations las ik dat de functie "node_registration_submit" wordt aangeraden. Maar afaik is dit niet een hook. Hoe moet je dat dan gebruiken? halverwege hier
2. Ik ben erin geslaagd om alle nodeid's voor een bepaalde taxonomie term te krijgen, maar kan niet achterhalen hoe ik de term van de huidige pagina te pakken krijg.
3. Ik weet niet Hoe ik alle registraties kan ophalen voor een bepaalde userid. Via _node_registration_user_registered ($ node $ account)?
4. Hoe zorg ik ervoor dat node_registrations stopt met het registreren van een gebruiker, wanneer mijn code dat wil?

[Voor 20% gewijzigd door Menesis op 04-05-2015 20:17]

[Amanush]

1e slechte (en hopelijk de laatste) ervaring met Drupal opgedaan. Module `dblog`, een module om te loggen (ik meen vergelijkbaar met `watchdog`), probeerde logs in de database te stoppen. Column `severity` had geen waarde, en hier werd een probleem van gemaakt. Heb handmatig in de Module moeten schrijven dat `severity` de DEFAULT value moest krijgen als de variable `severity` gelijk is aan false || null.

De module `dblog` ga ik voor de komende 10 jaar vermijden, en Drupal misschien ook..

[Mei]

watchdog() is een algemene loggingfunctie. Dblog kan gebruikt worden als logging backend. Je moet de oorzaak van het probleem niet bij Drupal zoeken, maar bij de code die logs wil laten wegschrijven zonder severity, want dat is ongeldig. Deze code kan bijvoorbeeld in een contributed module zitten.

Jouw fix werkt nu misschien, maar wees niet verbaasd als je straks op andere plekken fouten voorbij ziet komen vanwege ontbrekende severity values.

[Amanush]

Mei schreef op vrijdag 08 mei 2015 @ 12:43:
[...]
Je moet de oorzaak van het probleem niet bij Drupal zoeken.
[...]
Jouw fix werkt nu misschien, maar wees niet verbaasd als je straks op andere plekken fouten voorbij ziet komen vanwege ontbrekende severity values.

Ik ben blij dat het uberhaupt werkt op het moment.
Heeft watchdog/dblog geen default value wat betreft `severity`?

[Voor 8% gewijzigd door Amanush op 08-05-2015 12:46]

[Mei]

Dat maakt überhaupt niet uit. Als calling code heb je je aan de regels te houden. Doe je dat niet, dan krijg je bijvoorbeeld dit soort problemen.

Als ik jou was, zou ik je verandering ongedaan maken en de daadwerkelijke oorzaak zoeken. Als zoiets stoms als dit fout gaat, wil ik toch altijd graag weten welke code daarvoor verantwoordelijk is. Daarnaast blijf je met de huidige oplossing na elke upgrade core patchen.

[Amanush]

Mei schreef op vrijdag 08 mei 2015 @ 13:45:
[...]
Als ik jou was, zou ik je verandering ongedaan maken en de daadwerkelijke oorzaak zoeken. Als zoiets stoms als dit fout gaat, wil ik toch altijd graag weten welke code daarvoor verantwoordelijk is. Daarnaast blijf je met de huidige oplossing na elke upgrade core patchen.

Dank voor je advies!

[Amanush]

Mei schreef op vrijdag 08 mei 2015 @ 13:45:
[...]
Als ik jou was, zou ik je verandering ongedaan maken en de daadwerkelijke oorzaak zoeken. Als zoiets stoms als dit fout gaat, wil ik toch altijd graag weten welke code daarvoor verantwoordelijk is. Daarnaast blijf je met de huidige oplossing na elke upgrade core patchen.

De plugin `Panopoly` is de verantwoordelijke.



Zijn er misschien mensen met soortgelijke ervaring(en) met `Panopoly`?

[Mei]

Het kan gewoon een stomme bug zijn. Die sluipen er soms in.

Als je in die functie in dblog.module een backtrace uitvoert (dat kan met var_dump(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS)) als je zelf geen debugger hebt draaien), dan kan je de fout herleiden naar de calling code en zo precies zien waar het fout gaat.

[Amanush]

Thanks, ik zal de output naar een file writen.

[Menesis]

Vraagje mbt DB queries:
via

code:

dpm(drupal_get_schema());

ben ik erachter dat ik de inhoud van de volgende array wil hebben:

type (String, 3 characters ) int
$...['node_registration']['fields']['uid']['type']

Hoe krijg ik die te pakken? Ik denk dat ik een static querie meot uitvoeren oid?

[Pizzalucht]

Ik snap je vraag niet helemaal, maar misschien kan je iets met db_select()?

[Pizzalucht]

Ow en even een schaamteloze plug voor mijn module: https://www.drupal.org/project/paragraphs

[Marc3l]

Pizzalucht schreef op dinsdag 12 mei 2015 @ 23:28:
Ow en even een schaamteloze plug voor mijn module: https://www.drupal.org/project/paragraphs

Nice
Helaas al een functie gemaakt met Field collection voor mijn site maar voor toekomstige projecten ga ik deze wel gebruiken.

[Menesis]

Pizzalucht schreef op dinsdag 12 mei 2015 @ 23:19:
Ik snap je vraag niet helemaal, maar misschien kan je iets met db_select()?

Ja ik denk het maar ik heb geen idee hoe ik dat moet gebruiken (ben niet zo goed in programmeren..)

[Pizzalucht]

Menesis schreef op woensdag 13 mei 2015 @ 17:16:
[...]

Ja ik denk het maar ik heb geen idee hoe ik dat moet gebruiken (ben niet zo goed in programmeren..)

Er staan heel wat voorbeelden op die pagina.
Als je daar niet verder mee komt kan ik het wel uitleggen maar ik ben bang dat je al vrij snel weer vast komt te zitten.

[Menesis]

Het is me gelukt.
M'n eerste module is een add on voor node registrations. Hij checkt of de user niet al is ingeschreven voor een event dat dezelfde taxonomy term heeft. Handig voor evenementen met meerdere workshops die elk meerdere tijdslots hebben, waarbij je je maar één keer voor een type workshop kunt inschrijven.

PHP:

<?php
function limit_registrations_by_taxonomy_node_registration_access(){      
    //load current node
    $node = menu_get_object('node');
    //load current taxonomy term
    $currentTaxId = $node->field_type_clinic['und']['0']['tid'];
    
    //get all the nodeid's that contain the taxonomy terms from the current page
    $nodesToCheck = taxonomy_select_nodes($currentTaxId,FALSE,FALSE);
        
    //loop over the taxonomy id's and check for registrations. Return FALSE if any registration is found.
    foreach ($nodesToCheck as &$value) {
        if(_node_registration_user_registered(node_load($value))){
            dpm("al ingeschreven voor ".$value."!");
            return FALSE;
        }
    } 
}

-> Nog wel een vraagje want ik gebruik de hook niet helemaal goed.
Hook wordt zo gedefinieerd: function hook_node_registration_access($registration, $op, $account, $reason) {

Ik wil graag de var $reason opgeven om aan te geven waarom men zich niet kan inschrijven. Ik moet dan iets opgeven voor $registration, $op en $account Ik weet alleen niet wat en krijg dat niet werkend...

* @param NodeRegistrationEntityClass $registration
* The relevant $registration, which might be new (so no registration_id) in case
* of operation 'add'/'create'.
* @param string $op
* The operation this access overrides. One of: delete, view, cancel, edit/update,
* add/create. The last two have aliases you must check for.
* @param stdClass $account
* The relevant user object that tries to do this $op to this $registration. Never
* empty;
* @param string $reason
* The reason the standard NR access was FALSE. Relevant for all operations. If the
* reason is unknown, this will be '?', so it's only empty IF access was granted
* by standard NR logic. This argument is useful if your code has expensive logic
* to disallow a certain operation: if $reason is not empty AND you're the only
* module overriding this access, your expensive code doesn't have to run.

O.a. geprobeerd:

PHP:

global $user;

function limit_registrations_by_taxonomy_node_registration_access(NULL,"create",$user,"Al ingeschreven"){

[Voor 4% gewijzigd door Menesis op 14-05-2015 22:08]

[Marc3l]

Menesis schreef op donderdag 14 mei 2015 @ 21:51:

-> Nog wel een vraagje want ik gebruik de hook niet helemaal goed.
Hook wordt zo gedefinieerd: function hook_node_registration_access($registration, $op, $account, $reason) {

Ik wil graag de var $reason opgeven om aan te geven waarom men zich niet kan inschrijven. Ik moet dan iets opgeven voor $registration, $op en $account Ik weet alleen niet wat en krijg dat niet werkend...

[...]

Klopt je moet de params nog toevoegen aan je functie.

PHP:

function limit_registrations_by_taxonomy_node_registration_access($registration, $op, $account, $reason){

PHP:

function limit_registrations_by_taxonomy_node_registration_access(NULL,"create",$user,"Al ingeschreven"){

Dit zal niet werken, uit deze functie verwacht hij alleen een true of false terug.
Met $reason kan alleen jij wat doen in je functie. Je kan de $reason niet teruggeven.

Niet een mooie oplossing maar misschien zou je dit eens kunnen proberen voor je return FALSE;

PHP:

 drupal_set_message(t('Already registered for this event.'), 'error');

Ook hoef je

PHP:

$node = menu_get_object('node');

niet te doen, deze zit al in param $registration

PHP:

$registration->node;

[Voor 5% gewijzigd door Marc3l op 15-05-2015 09:17]

[Menesis]

thanks voor de feedback
Die set_message had ik ook even erin staan, alleen komt die melding direct nadat je je aanmeld. Dat stond een beetje raar, want je krijgt eerst een info message dat je bent ingeschreven en daaronder één dat het niet kan omdat je al bent ingeschreven.

Misschien had ik het verkeerd gekopieerd van die $reason variabele.
In die module staat het zo:

PHP:

function node_registration_node_access($node, $op, $account = NULL, &$reason = NULL)

Dat betekent dat ik die &$reason wel kan instellen toch? Ik begrijp alleen niet hoe Ik heb niets om met die andere variabele te doen

[Voor 35% gewijzigd door Menesis op 15-05-2015 17:38]

[Menesis]

Is dit veel voor een views pagina die een overzichtje weergeeft van ongv. 80 pagina's?
Executed 459 queries in 75.72 ms

459 klikt erg veel imho

[Marc3l]

Menesis schreef op vrijdag 15 mei 2015 @ 17:35:
thanks voor de feedback
Die set_message had ik ook even erin staan, alleen komt die melding direct nadat je je aanmeld. Dat stond een beetje raar, want je krijgt eerst een info message dat je bent ingeschreven en daaronder één dat het niet kan omdat je al bent ingeschreven.

Misschien had ik het verkeerd gekopieerd van die $reason variabele.
In die module staat het zo:

PHP:

function node_registration_node_access($node, $op, $account = NULL, &$reason = NULL)

Dat betekent dat ik die &$reason wel kan instellen toch? Ik begrijp alleen niet hoe Ik heb niets om met die andere variabele te doen

Nee, die is voor de node. Jij moet die hebben uit de api (http://cgit.drupalcode.or...node_registration.api.php)
Die params die je meekrijgt die geef je niet terug, je geeft alleen TRUE of FALSE terug.

Is dit veel voor een views pagina die een overzichtje weergeeft van ongv. 80 pagina's?
Executed 459 queries in 75.72 ms

Heb even een testje gedaan op een nieuwe standaard install met 1 node en daar view van gemaakt (basic page, zonder extra velden)
Daar komt ' Executed 146 queries in 57.34 ms.' uit.

[Mei]

Views zelf maakt over het algemeen zeer goede queries. Als je zelf echter allerlei geavanceerde dingen in de view in kwestie stopt, dan kan de performance snel achteruit gaan. Een goed voorbeeld zijn entity operations (die dropbuttons): deze kunnen alleen opgebouwd worden als eerst de hele entity geladen is en dat kost weer meerdere queries, zeker als er veel fields op zitten. Dit gebeurt vervolgens per entity in de view, afhankelijk van de interne optimalisaties in de Views plugins (die ook uit andere modules dan Views kunnen komen), is tientallen queries per result row niet enorm raar, alhoewel het de performance natuurlijk niet positief beïnvloedt.

[Menesis]

Hmm, beetje dood topic, ik hoop dat er toch iemand meekijkt :):
Ik wil graag een widget maken voor het "location" field (een field om je geolocatie op te slaan in lengte en breedetegraad).
Het widget moet de HTML5 geo api beter integreren. Ik heb vele modules geprobeerd maar geen een geeft de controle en "experience" die ik wil. Daarom wil ik een widget maken om de input gemakkelijker te maken.

Eerste stap:
- hoe vind ik de echt naam van een field? Ik heb nu dit, maar er verschijnt nog geen widget onder mijn content type met het location field.

function geofield_field_widget_info() {
return array(
'geofield' => array(
'label' => t('Location'),
'field types' => array('location'),
),
);
}

[ruuds]

Naast hook_field_widget_info dien je ook hook_field_widget_form te implementeren. Deze dient een element array te returnen wat gerenderd kan worden door drupal_render.

[Mei]

Drupal 8 is uit: https://www.drupal.org/8

Met vanavond een gratis toegankelijke release party in Amsterdam: http://www.meetup.com/drupalnl/events/226585621/

[Menesis]

Het is hier vrij rustig.. Op welk forum zijn de meeste Drupalaars te vinden?

Ik zit met het volgende. Voor een klein festival kunnen mensen zich inshrijven voor workshops via views en de signup module.

Probleem: het inschrijven opent op een bepaald tijdstip en 1000 man zitten dan continue te F5en (refreshen) om de eerste te zijn. Caching gaat geloof ik niet, want de site geeft aan hoeveel plekken er nog beschikbaar zijn, en als een workshop vol is moet deze niet meer opduiken, anders krijg je teleurgestelde mensen.

Vraag: Bestaat er een vorm van caching waarbij ingelogde gebruikers toch de nieuwste versie van een pagina te zien krijgen?


De site stond op shared hosting en ging dan kapot. Nu heb ik m via Cloudways op Digital Ocean gehost, maar weet nog niet zeker of dat het oplost.

[Voor 5% gewijzigd door Menesis op 31-01-2016 20:52]

[Mei]

Alleen Drupal 8 heeft slimme caching, dus op 7 is de enige optie om page caching uit te schakelen.

[Voutloos]

Alles statisch maken, en dan met js (ajax) de teller invullen en het form enablen indien mogelijk. Workshop vol, geen form. Geen js, jammer dan.

Zit je wellicht alsnog met een race conditie als tijdens t invullen de laatste plekken vergeven zijn, maar om dat te fixen moet je al plekken op voorbehoud reserveren etc en kan je nog wel een jaar developen.

Iets meer aan hosting dokken helpt ook, 1000 man is ook niet meer zo eng als t geweest is.

[kwaakvaak_v2]

Mei schreef op zondag 31 januari 2016 @ 21:33:
Alleen Drupal 8 heeft slimme caching, dus op 7 is de enige optie om page caching uit te schakelen.

Niet helemaal waar, je zou dit voor een deel kunnen doen met https://www.drupal.org/project/Authcache en dan bepaalde stukken via ajax (of bigpipe zoals het hip genoemd wordt) in de pagina injecteren. Los van dat je dan geen cache tags hebt zoals Drupal 8 kun je wel het grootste van je niet gewijzigde content prima cachen.

Ik gebruik dit op een site waar gebruikers achter een registratie muur zitten om bepaalde artikelen te mogen lezen, en het werkt na wat configuren zonder problemen uit den doos.

[Mei]

Ik ging er vanuit dat @Menesis niet wilde coden. Wellicht geen geldige aanname.

[Eusebius]

Menesis schreef op zondag 31 januari 2016 @ 20:51:
Het is hier vrij rustig.. Op welk forum zijn de meeste Drupalaars te vinden?

Drupal.org natuurlijk. Of drupal.stackexchange.com. Daar krijg je soms sneller en beter antwoord.

[Pizzalucht]

Ik ben ook regelmatig op IRC te vinden om Drupal support vragen te beantwoorden.

[Menesis]

Toch wel een actief topic bedankt voor de antwoorden! Zelf de modules omschrijven naar iets met Ajax gaat hem niet worden denk ik, maar die Authcache ziet er wel goed uit!

Het is me gister gelukt om m'n site persoonlijk te ddossen door simpelweg F5 voor een minuut ingedrukt te houden En dat op een 1 core, 1GB hosting van digital ocean. Er is dus nog wat optimalisatie nodig voordat 1000 ingelogde users zich op hetzelfde tijdstip kunnen gaan inschrijven. Ik was aanvankelijk erg verbaasd dat shared hosting geen 1000 man aankon, maar Drupal is misschien toch wel wat zwaarder dan ik dacht.

op dit moment zijn de stats volgens devel: Executed 147 queries in 25.91 ms. Queries exceeding 5 ms are highlighted. Page execution time was 272.54 ms. Memory used at: devel_boot()=0.75 MB, devel_shutdown()=13.71 MB, PHP peak=15 MB.

Volgens mij is dat wel acceptabel?

[Pizzalucht]

Menesis schreef op dinsdag 02 februari 2016 @ 21:19:
Toch wel een actief topic bedankt voor de antwoorden! Zelf de modules omschrijven naar iets met Ajax gaat hem niet worden denk ik, maar die Authcache ziet er wel goed uit!

Het is me gister gelukt om m'n site persoonlijk te ddossen door simpelweg F5 voor een minuut ingedrukt te houden En dat op een 1 core, 1GB hosting van digital ocean. Er is dus nog wat optimalisatie nodig voordat 1000 ingelogde users zich op hetzelfde tijdstip kunnen gaan inschrijven. Ik was aanvankelijk erg verbaasd dat shared hosting geen 1000 man aankon, maar Drupal is misschien toch wel wat zwaarder dan ik dacht.

op dit moment zijn de stats volgens devel: Executed 147 queries in 25.91 ms. Queries exceeding 5 ms are highlighted. Page execution time was 272.54 ms. Memory used at: devel_boot()=0.75 MB, devel_shutdown()=13.71 MB, PHP peak=15 MB.

Volgens mij is dat wel acceptabel?

Op zich nette cijfers! Wat is de totale rendertijd van PHP (dus niet alleen de queries).

En dat je je eigen site DoS'ed kan ook erg aan je configuratie van Apache/Nginx liggen, maar verwacht niet teveel van zo'n Digital Ocean bakje, zeker niet als je (bijna) niks kan cachen.

[Menesis]

Ik weet niet hoe ik de totale rendertijd kan tonen, maar als ik de view los bekijk staat er:
Query build time 23.13 ms
Query execute time 1.34 ms
View render time 67.7 ms

maar dat wordt wat meer naarmate er meer inschrijvingen zijn. Ik geloof dat we max op 450 queries zaten.

Is Digital Ocean niet zo krachtig? Ik doe het via Cloudways: had ik beter voor amazon of google kunnen kiezen? Daar krijg je een stuk minder voor je geld als je puur naar de specs kijkt. We hebben max 50€ per maand over voor hosting..

[Voor 10% gewijzigd door Menesis op 02-02-2016 21:46]

[Pizzalucht]

Menesis schreef op dinsdag 02 februari 2016 @ 21:46:
Ik weet niet hoe ik de totale rendertijd kan tonen, maar als ik de view los bekijk staat er:
Query build time 23.13 ms
Query execute time 1.34 ms
View render time 67.7 ms

maar dat wordt wat meer naarmate er meer inschrijvingen zijn. Ik geloof dat we max op 450 queries zaten.

Is Digital Ocean niet zo krachtig? Ik doe het via Cloudways: had ik beter voor amazon of google kunnen kiezen? Daar krijg je een stuk minder voor je geld als je puur naar de specs kijkt. We hebben max 50€ per maand over voor hosting..

Kan je dan niet veel beter ergens een dedicated server ergens pakken? Krijg je sowieso meer waar voor je geld, moet je waarschijnlijk wel iets meer zelf configureren/doen.
Bijvoorbeeld: https://www.soyoustart.com/nl/essential-servers/ (als het niet uit maakt dat de server in Frankrijk staat)

Wat bedoel je precies met 1000 inschrijvingen/man tegelijk? 1000 req/s tegelijk, 1000 open sessies tegelijk (van hoeveel requests/s ga je dan uit)?
Wat is het precies het plan? Je kan het misschien wel op die DigitalOcean voor elkaar krijgen als je duidelijk hebt hoeveel requests je krijgt zodat je daarop kan benchmarken.

[Barryvdh]

1000 bezoekers tegelijk is best veel nog, als je niks optimaliseren.

Met Digital Ocean kan je wel makkelijk schalen. Dus bijv. dag een groot pakket, daarna weer terug schalen.
En statische pagina's kan je iig goed cachen, evt met Boost.

[Menesis]

ik heb helaas geen harde cijfers, maar het scenario is als volgt:

• festival met 3000 bezoekers
• om een bepaald tijstip, zeg 12.00 uur gaat de site "open", vanaf dan kan men zich inschrijven voor workshops.
• van de 3000 bezoekers zijn er zo'n 500 fanatiekelingen die continue ziten te refreshen tot het 12.00 is. waarom? omdat er te weinig plekken zijn voor sommige workshops.

die fanatiekelingen zijn ingelogd en refreshen een page met ongeveer 400 queries. De pagina is dynamisch en verandert telkens als iemand zich inschrijft, maar de pagina is wel hetzelfde voor elke gebruiker.
Om teleurstellingen te voorkomen denk ik dat de pagina toch wel elke 30 seconden globaal gerefreshed moet worden.

toen de site vorige keer vastliep ging men alleen maar vaker op F5 drukken dus dat was einde oefening totdat men afdroop (na een half uur). En toen had de webmaster het natuurlijk gedaan

[Pizzalucht]

Barryvdh schreef op dinsdag 02 februari 2016 @ 22:39:
1000 bezoekers tegelijk is best veel nog, als je niks optimaliseren.

Met Digital Ocean kan je wel makkelijk schalen. Dus bijv. dag een groot pakket, daarna weer terug schalen.
En statische pagina's kan je iig goed cachen, evt met Boost.

Schalen met Digital Ocean is wel makkelijk, maar je moet je server wel uitzetten het kan best lang duren.

[Barryvdh]

Menesis schreef op dinsdag 02 februari 2016 @ 22:39:
ik heb helaas geen harde cijfers, maar het scenario is als volgt:

• festival met 3000 bezoekers
• om een bepaald tijstip, zeg 12.00 uur gaat de site "open", vanaf dan kan men zich inschrijven voor workshops.
• van de 3000 bezoekers zijn er zo'n 500 fanatiekelingen die continue ziten te refreshen tot het 12.00 is. waarom? omdat er te weinig plekken zijn voor sommige workshops.

die fanatiekelingen zijn ingelogd en refreshen een page met ongeveer 400 queries. De pagina is dynamisch en verandert telkens als iemand zich inschrijft, maar de pagina is wel hetzelfde voor elke gebruiker.
Om teleurstellingen te voorkomen denk ik dat de pagina toch wel elke 30 seconden globaal gerefreshed moet worden.

toen de site vorige keer vastliep ging men alleen maar vaker op F5 drukken dus dat was einde oefening totdat men afdroop (na een half uur). En toen had de webmaster het natuurlijk gedaan

Tot 12 uur is het wel statisch dan toch? Dus dat kan je cachen.

Pizzalucht schreef op dinsdag 02 februari 2016 @ 22:40:
[...]


Schalen met Digital Ocean is wel makkelijk, maar je moet je server wel uitzetten het kan best lang duren.

Tja, laatste keer dat ik dat deed, duurde het minuut of 10. Maar als je dat snachts doet, is dat meestal niet zo'n probleem toch?

[Pizzalucht]

Barryvdh schreef op dinsdag 02 februari 2016 @ 22:56:
[...]

Tot 12 uur is het wel statisch dan toch? Dus dat kan je cachen.
[...]

Tja, laatste keer dat ik dat deed, duurde het minuut of 10. Maar als je dat snachts doet, is dat meestal niet zo'n probleem toch?

Volgens mij heel erg afhankelijk van hoe groot je disk is. Bij mij heeft het ook wel eens langer dan een uur geduurd. Maar inderdaad, als je het 's nachts doet is het niet zo erg. Probeer alleen maar te zeggen dat de flexibiliteit wat mooier lijkt dan het is.

[kwaakvaak_v2]

Menesis schreef op dinsdag 02 februari 2016 @ 21:46:
Ik weet niet hoe ik de totale rendertijd kan tonen, maar als ik de view los bekijk staat er:
Query build time 23.13 ms
Query execute time 1.34 ms
View render time 67.7 ms

maar dat wordt wat meer naarmate er meer inschrijvingen zijn. Ik geloof dat we max op 450 queries zaten.

Is Digital Ocean niet zo krachtig? Ik doe het via Cloudways: had ik beter voor amazon of google kunnen kiezen? Daar krijg je een stuk minder voor je geld als je puur naar de specs kijkt. We hebben max 50€ per maand over voor hosting..

Lees ik het nu goed, geen cache op die view? Als de resultaten soort van fixed zijn, zou je op zijn minst de query results kunnen cachen.



Rendered output cache ik meestal op pagina niveau voor anonieme gebruikers, het heeft volgens mij niet veel nut om de HTML output twee keer in je cache tabellen te zetten.

Wat ook redelijk veel kan schelen is je rendered cache naar memcached te verplaatsen, of als je het aan durft met de filecache module. Die slaat de cache serialized op in files, wat soms gunstiger kan zijn voor de grotere caches zoals pagina's (of als je simpelweg geen memcache/redis/apcu tot je beschikking hebt.

En last but not least, geen idee of je het aan kan passen maar mijn ervaring is dat Drupal net iets beter draait met php in FPM mode dan in mod_php onder apache 2.4.

[Barryvdh]

kwaakvaak_v2 schreef op woensdag 03 februari 2016 @ 10:40:
[...]


Lees ik het nu goed, geen cache op die view? Als de resultaten soort van fixed zijn, zou je op zijn minst de query results kunnen cachen.

[afbeelding]

Rendered output cache ik meestal op pagina niveau voor anonieme gebruikers, het heeft volgens mij niet veel nut om de HTML output twee keer in je cache tabellen te zetten.

Wat ook redelijk veel kan schelen is je rendered cache naar memcached te verplaatsen, of als je het aan durft met de filecache module. Die slaat de cache serialized op in files, wat soms gunstiger kan zijn voor de grotere caches zoals pagina's (of als je simpelweg geen memcache/redis/apcu tot je beschikking hebt.

En last but not least, geen idee of je het aan kan passen maar mijn ervaring is dat Drupal net iets beter draait met php in FPM mode dan in mod_php onder apache 2.4.

Maar op dat moment is het dus druk met inschrijvinen + wil hij up-to-date info tonen, dus kan je niet (lang) cachen. Al scheelt 1 minuut cachen natuurlijk wel als er veel mensen aan het F5'en zijn.
Als je de overige pagina's met Boost statisch cached, doen die iig ook geen queries.

[kwaakvaak_v2]

Met boost moet je wel opletten dat je de expire wel goed regelt, als je dat niet goed doet is de kans dat je behoorlijk lang naar stale content zit te kijken. Dan ben je haast beter af om je site via Fastly / Cloudflare of dergelijke dienst te laten lopen en er voor zorgen dat je HTTP headers goed zijn.

Voordeel van Fastly is dat het Varnish is, en je desnoods een block met het formulier via ESI kan laden

[Kozzmozz]

Kan iemand mij helpen hoe ik in de menubalk "HOME" kan veranderen in een home-icon?
https://drive.google.com/...YNmtMVXc/view?usp=sharing

[Creepy]

Je kan beter een nieuw topic openen (met iets meer informatie dan dat je nu geeft). Voor dit soort vragen is dit topic niet bedoelt.

[Menesis]

Ik heb een site die "node registrations" gebruikt met o.a. een field voor aantal ingeschreven mensen.
In Views wil ik een filter maken voor dit aantal mensen, maar het field is niet als filter beschikbaar, maar wel onder "fields".

Hoe kan ik een filter in Views maken van een field dat niet als filter beschikbaar is?

Edit: misschien duidelijker met een screenshot:

Ik wil voor het field Available Slots een filter maken voor als het aantal 0 slots is.

[Voor 25% gewijzigd door Menesis op 20-05-2017 20:43]

[kwaakvaak_v2]

Dan voeg je toch het filter toe? Staat niet voor niets een knopje toevoegen naast Filter criteria?

[Menesis]

kwaakvaak_v2 schreef op maandag 22 mei 2017 @ 10:43:
Dan voeg je toch het filter toe? Staat niet voor niets een knopje toevoegen naast Filter criteria?

Dat veld komt helaas niet voor in die lijst

[mike.stijlloos]

Dan lijkt het me dat het veld type, filters niet ondersteund.
Als het een veld is wat toegevoegd is door een contrib module, dan moet er wel ondersteuning voor views ingebouwd zijn/worden.

[Menesis]

mike.stijlloos schreef op vrijdag 26 mei 2017 @ 16:54:
Dan lijkt het me dat het veld type, filters niet ondersteund.
Als het een veld is wat toegevoegd is door een contrib module, dan moet er wel ondersteuning voor views ingebouwd zijn/worden.

Ah ok, dat is het dus. Maar de "kogel is al door de kerk" en de site is online gegaan.

Is BPU iets dat je met verschillende setup en sites kunt vergelijken?

Wat database stats:

[Marc3l]

mike.stijlloos schreef op vrijdag 26 mei 2017 @ 16:54:
Dan lijkt het me dat het veld type, filters niet ondersteund.
Als het een veld is wat toegevoegd is door een contrib module, dan moet er wel ondersteuning voor views ingebouwd zijn/worden.

zo niet dan kan je er zelf één maken, https://www.webomelette.c...tom-views-filter-drupal-8

[Zidane007nl]

Menesis schreef op zaterdag 20 mei 2017 @ 20:41:
Ik heb een site die "node registrations" gebruikt met o.a. een field voor aantal ingeschreven mensen.
In Views wil ik een filter maken voor dit aantal mensen, maar het field is niet als filter beschikbaar, maar wel onder "fields".

Hoe kan ik een filter in Views maken van een field dat niet als filter beschikbaar is?

Edit: misschien duidelijker met een screenshot:
[afbeelding]
Ik wil voor het field Available Slots een filter maken voor als het aantal 0 slots is.

Dan heb je waarschijnlijk de verkeerde module gekozen. Je hebt Node Registration en Entity Registration. Entity Registration heeft zo te zien meer features en ze zeggen dat ze View filters ondersteunen.

[Menesis]

Zidane007nl schreef op vrijdag 26 mei 2017 @ 23:29:
[...]

Dan heb je waarschijnlijk de verkeerde module gekozen. Je hebt Node Registration en Entity Registration. Entity Registration heeft zo te zien meer features en ze zeggen dat ze View filters ondersteunen.

Ah ok. Hmm kan het nu niet meer veranderen want de site is in productie nu en ik heb ook een eigen module voor node registrations geschreven. Op zich is node registration best prima out of the box, maar het is hier en daar niet helemaal af zo lijkt het. En het wordt niet echt meer geupdate helaas.
Voor volgens jaar eens naar entity registration kijken

Marc3l schreef op vrijdag 26 mei 2017 @ 18:59:
[...]

zo niet dan kan je er zelf één maken, https://www.webomelette.c...tom-views-filter-drupal-8

Site draait nog op Drupal 7. Op zou denk ik wel een custom PHP filter kunnen maken om het veld als filter te kunnen gebruiken. Misschien volgend jaar naar Drupal 8 porten dan

[Voor 20% gewijzigd door Menesis op 27-05-2017 11:14]

[Menesis]

hmm, beetje dood topic

Met dank aan dit topic had ik een paar jaar (!) terug een kleine module geschreven. Deze checkt of mensen zich niet al hebben ingeschreven voor een workshop aan de hand van taxonomy terms.
Maar nu lijkt dat het een erg beetje module is als er veel (1000+) registraties zijn, want hij itereert over alle inschrijvingen.

Is het mogelijk om alleen taxonomy term van de inschrijvingen van de user te bekijken? Echter staat die term niet in de inschrijving denk ik, maar in de node die erbij hoort.

code:

<?php

function limit_registrations_by_taxonomy_node_registration_access(){

    if(isset($node->field_type_clinic['und']['0']['tid'])){
        
        //load current taxonomy term
        $currentTaxId = $node->field_type_clinic['und']['0']['tid'];
        
        //get all the nodeid's that contain the taxonomy terms from the current page
        $nodesToCheck = taxonomy_select_nodes($currentTaxId,FALSE,FALSE);
            
        //loop over the taxonomy id's and check for registrations. Return FALSE if any registration is found.
        foreach ($nodesToCheck as &$value) {
            if(_node_registration_user_registered(node_load($value))){
                //user should not be able to register
                return FALSE;
            }
        }
    }
}

[Pizzalucht]

Menesis schreef op woensdag 13 juni 2018 @ 20:20:
hmm, beetje dood topic

Met dank aan dit topic had ik een paar jaar (!) terug een kleine module geschreven. Deze checkt of mensen zich niet al hebben ingeschreven voor een workshop aan de hand van taxonomy terms.
Maar nu lijkt dat het een erg beetje module is als er veel (1000+) registraties zijn, want hij itereert over alle inschrijvingen.

Is het mogelijk om alleen taxonomy term van de inschrijvingen van de user te bekijken? Echter staat die term niet in de inschrijving denk ik, maar in de node die erbij hoort.

code:

<?php

function limit_registrations_by_taxonomy_node_registration_access(){

    if(isset($node->field_type_clinic['und']['0']['tid'])){
        
        //load current taxonomy term
        $currentTaxId = $node->field_type_clinic['und']['0']['tid'];
        
        //get all the nodeid's that contain the taxonomy terms from the current page
        $nodesToCheck = taxonomy_select_nodes($currentTaxId,FALSE,FALSE);
            
        //loop over the taxonomy id's and check for registrations. Return FALSE if any registration is found.
        foreach ($nodesToCheck as &$value) {
            if(_node_registration_user_registered(node_load($value))){
                //user should not be able to register
                return FALSE;
            }
        }
    }
}

Aangezien node_registration gebruikt maakt van entities zou je iets van een EntityFieldQuery kunnen gebruiken.

code:

<?php
function limit_registrations_by_taxonomy_node_registration_access(){
    if(isset($node->field_type_clinic['und']['0']['tid'])){

        //load current taxonomy term
        $currentTaxId = $node->field_type_clinic['und']['0']['tid'];

        //get all the nodeid's that contain the taxonomy terms from the current page
        $nodesToCheck = taxonomy_select_nodes($currentTaxId,FALSE,FALSE);

        global $user;

        $query = new EntityFieldQuery();
        $query->entityCondition('entity_type', 'node_registration')
            ->propertyCondition('uid', $user->uid)
            ->propertyCondition('nid', $nodesToCheck, 'IN')
            ->propertyCondition('cancelled', 0);

        $result = $query->execute();
        if (isset($result['node_registration']) && count($result['node_registration']) > 0) {
            // User should not be able to register.
            return FALSE;
        }
    }
}

Let op: niet getest

[Wolf3D]

Hoewel het hier erg stil lijkt, toch nog even kijken of Drupal nog een beetje leeft onder mede-Tweakers :-)

Ik zoek een oplossing voor de volgende uitdaging:
Op een nieuwe Drupal 8 website wil ik een multi step formulier tonen, waarmee ik uiteindelijk op één contentpagina kom (een specifieke node), afhankelijk van wat ik heb gekozen in het formulier. Dus bijvoorbeeld:

Stap 1: kies een land (taxonomy term)
Stap 2: kies filter 2 (taxonomy term)
Stap 3: kies filter 3 (taxonomy term)
Stap 4: toon content (afhankelijk van gekozen filters)

De mogelijke oplossingen die ik in mijn hoofd had:

1. Webforms met multi step formulier. Uitdaging: hoe toon ik een node op de laatste stap afhankelijk van de gekozen opties in de eerste stappen.
2. Views met exposed filters. Uitdaging: hoe krijg ik de exposed filters verdeelt over meerdere pagina's.
3. Compleet custom code, hoewel ik dit natuurlijk liever wil voorkomen.

Bij oplossing 1 loop ik vast op het tonen van de juiste node bij stap 4. Via https://www.drupal.org/project/webform_node_element zou ik een node binnen een webform kunnen tonen, maar de vraag is hoe ik afhankelijk van wat ik gekozen heb de juiste node kan tonen, ipv statisch een node ID in te voeren.

Bij oplossing 2 loop ik vast op het multistep maken van de exposed filters van de view. Ik heb ook nog geen modules gevonden die daarbij kunnen helpen.

Er zijn natuurlijk altijd meerdere manieren om iets op te lossen binnen Drupal, maar ik zoek natuurlijk de meest logische. Ik had ook al zitten kijken of ik de submit URL van oplossing 1 via de GET methode naar een specifieke link te posten. Bijvoorbeeld naar /view/filter1/filter2/filter3/. En deze weer op te laten vangen door een view. Maar ook hier loop ik vast op het omzetten van de gekozen opties/filters naar een specifieke submit URL.

Heeft iemand hier wel eens een soortgelijke uitdaging opgelost of … tips / inspiratie?

[kden1m]

Iemand die mij een goede hosting kan aanraden specifiek gericht op Drupal? Pantheon.io schijnt erg goed te zijn. Nog andere opties?