Project

General

Profile

Bug #1018

Cache problemer på forsiden giver problemer med afpublicering og nye forsidekaruseller? MANGLER AFSLUTNING AF CODE REVIEW

Added by Niels Frandsen over 4 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Estimated time:
URL med eksempel:
Kategorier:
Inspiration - Forsiden, Inspiration - Karruseller

Description

Har oplevet at arrangementer, der har været afholdt ikke afpubliceres automatisk.
Nu oplever vi også at nyheder ikke afpubliceres. Når en artikel er sat til afpublicering virker det tilsyneladende kun, når man er logget ind - det virker såvel ved redaktørlogin, såvel som alm. brugerlogin. Når man logger ud igen er artiklen fortsat synlig. Det er absolut uhensigtsmæssigt!
Se eksempel vedhæftet.


Related issues

Related to DDB CMS - Bug #1022: Forsidekarrusel vises forskelligt ved ved ind og udlogningClosed2015-03-03
Related to DDB CMS - Bug #1653: Opdatér Memcache fra version 1.0 til 1.5Resolved (tag version)
Has duplicate DDB CMS - Bug #949: Arrangementer forsvinder ikke automatisk fra forsidenClosed2015-02-23

History

#1 Updated by Rolf Madsen over 4 years ago

  • Status changed from New to Open (waiting)
  • Target version set to DDB CMS 2015 2. opgradering

Bliver nyheder og arrangementer slet ikek afpublicerede eller går der bare noget tid før det sker?

#2 Updated by Niels Frandsen over 4 years ago

Har ikke haft mere end godt 1 døgns "tolerance" i overskridelse - før jeg manuelt har slettet artiklen.

#3 Updated by Louise Mohr over 4 years ago

Vi har oplevet lidt det samme her i Gladsaxe- vi havde sat en nyhed til at afpublicere lørdag og i dag mandag vises den stadig - men kun når man ikke er logget ind. Er man logget ind vises den ikke. Forsøger man så at tilgå siden uden at være logget ind, får man at vide at man ikke har adgang til siden - adgang nægtet. Efter lidt test viser det sig i hvert fald hos os, at det kun er på forsiden nyheden stadig vises. De andre steder (temaside og bibliotek) er den afpubliceret. Men det burde vel være muligt at have en nyhed forfremmet til forside, men at afpubliceringen stadig slår igennem?

#4 Updated by Rolf Madsen over 4 years ago

Min dialog med DBC tyder ikke på at de har ændret noget i caching af hjemmesiden, så det er noget vi skal have gravet mere i.

En foreløbig, og ved jeg godt utilstrækkelig løsning er at cleare caching for at afpublicere det indhold der ikke selv forsvinder fra forsiden.

Se http://platform.dandigbib.org/projects/ddb-cms/wiki/DDBCMSManual#Clear-cache for en vejledning til at cleare cachen.

#5 Updated by Simon Holt over 4 years ago

Hvis I bruger memcache på jeres servere, kan I prøve at eksperimentere med at slå det fra:

Jeg har haft store problemer med, at cachen ikke blev invalideret som den skulle på vejlebib.dk. Har eksperimenteret den del med at slå indstillinger til og fra. Efter jeg har slået modulet Memcache fra og fjernet dertilhørende indstillinger fra settings.php, har jeg ikke haft nogle problemer. Cachen invalideres som forventet efter indstillingen under 'admin/config/development/performance'.

#6 Updated by Jørgen Høst over 4 years ago

Vi oplever også problemet i Silkeborg. Se også Bug #949

#7 Updated by Rolf Madsen over 4 years ago

  • Has duplicate Bug #949: Arrangementer forsvinder ikke automatisk fra forsiden added

#8 Updated by Rolf Madsen over 4 years ago

  • Status changed from Open (waiting) to DBC (waiting)
  • Assignee set to Christian Vandel

#9 Updated by Rolf Madsen over 4 years ago

  • Subject changed from Afpublicering virker ikke/er ustabil? to Cache problemer på forsiden giver problemer med afpublicering og nye forsidekaruseller?

#10 Updated by Rolf Madsen over 4 years ago

  • Related to Bug #1022: Forsidekarrusel vises forskelligt ved ved ind og udlogning added

#11 Updated by Jørgen Høst over 4 years ago

Cachen er nu gået helt i stå. Vi tømmer dagligt cache for fjerne arrangementer fra gårsdagen. I weekenden er det især et problem med workflow. Se vores beskrivelse på Bug #949. Hvad siger dbc?

#12 Updated by Rolf Madsen over 4 years ago

Vi er meget opmærksomme på problemstillingen og har dels bedt DBC om at se hvad de kan gøre i driftsløsningen og vil derudover se på om der er noget der skal ændres i selve DDB CMS' kode.

#13 Updated by Christian Vandel over 4 years ago

Varnish cachen ryddes kun for ét sitenavn og ikke dets eventuelle aliases.

https://www.drupal.org/node/2185281 beskriver problematikken og har også et bud på en patch, som ser ud til at ville løse problemet.

Et midlertidigt workaround vil være at køre cron med sitets primære hostnavn udadtil, men det har nogle driftsmæssige komplikationer, da kørsel af cron indtil nu har været fuldautomatiseret i forhold til .ddbcms.dk-navnene.

#14 Updated by Rolf Madsen over 4 years ago

  • Priority changed from Normal to Urgent

#15 Updated by Gitte Barlach over 4 years ago

Hvilke alias´er er der tale om, har du en række konkrete eksempler?

Det vil give problemer hvis man har site aliaser (som IKKE er redirects) i alle de forskellige caching lag og i forhold til SEO.

#16 Updated by Christian Vandel over 4 years ago

Det konkrete problem handler alene om vedligeholdelsen af Varnish. Drupal cacher uafhængigt af domænenavne. I øvrigt laver vi redirects fra alle kundernes navne til det primære. Men der er et driftsmæssigt behov for at kunne tilgå sitet uafhængigt af det aktuelle primære navn og det bedste ville som sagt være hvis varnish-integrationen håndterede aliaser. Men workaraoundet vil blive implementeret snarest

#17 Updated by Jesper Kristensen over 4 years ago

Bare en side note: Jeg kan på ingen måde anbefale at slå memcached fra, da den giver et mega boost i preformance og den enest der sker er at caching data bliver gemt i databasen (hvilket giver et meget større load på serveren) fremfor i ram på serveren.

#18 Updated by Simon Holt over 4 years ago

Hej Jesper

Selvfølgelig giver det et performance boost. Men det er tilsyneladende det, der forhindrer vores caching i at fungere korrekt (det virker kun når jeg slår det fra). Det er sikkert noget med vores serverindstillinger, men det kunne jo være, at det var det samme der drillede her.

Vi bruger New Relic på vores server, og har dog ikke observeret nogen forandring i performance der.

#19 Updated by Rolf Madsen over 4 years ago

  • Target version changed from DDB CMS 2015 2. opgradering to DDB CMS 2015 3. opgradering

#20 Updated by Gitte Barlach over 4 years ago

Christian, kan du bekræfte at denne er løst?
Kan du eller andre på DBC vurdere om der endvidere skal ændres i selve DDB CMS' kode?

#21 Updated by Christian Vandel over 4 years ago

Jeg tror der er issue omkring invalidering af indholdet på forsiden i drupals page cache. Men derudover er det jo et trade off mellem performance og aktualitet, hvor længe data bør leve i diverse caches versus hvor opdateret de bør være.

t. er levetiden på page cachen på redaktør- og webmasterløsningerne sat til 6 timer. Den kan evt. sætttes ned til 1 time...

#22 Updated by Simon Holt over 4 years ago

EDIT:
I nedenstående undrer jeg mig over, hvorfor vi ikke bruger Purge-modulet til at cleare Varnish-cachede sider. Har eftefølgende fundet forklaringen og ville lige indsætte den her, hvis andre skulle undre sig over dette:

Varnish modulet har en intern purge funktion. Denne kommunikere med Varnish via admin porten over sockets. Det er ikke altid man har adgang til admin-port, så Purge-modulet tilbyder samme funktionalitet via et special-formateret HTTP-request til Varnish-serveren. Da vi HAR adgang til Varnish admin-port, behøver vi altså ikke at bruge Purge-modulet.

Se mere her: https://www.drupal.org/node/1686298
/EDIT

Læste lige følgende artikel, der beskriver teknikken brugt i ding_varnish, der gør det muligt at cache nogle sider for autentificerede brugere:

http://www.joshwaihi.com/content/authenticated-page-caching-varnish-drupal

Har et par spørgsmål i forhold til implementationen i ding_varnish:

1. I bunden af artiklen under 'Cache hits instead of pages with Drupal messages' beskrives problemet med, at brugere kan få serveret cachede sider selv om dette ikke er hensigtsmæssigt. Her nævnes det, at dette skal afhjælpes med Expire og Purge modulerne samt hook_form_alter implementation:

"To get around this you'll need the expire and purge module installed as well as a hook_form_alter implementation that looks for destination parameters on form submissions and purges the those paths in varnish prior to being redirected to them."

Kan se vi bruger Expire modulet, men kan ikke finde Purge og den hook_form_alter() implementation det omtales. Nogen der kan kaste lys over dette og kan det eventuelt være det vi mangler, for at få caching systemet til at fungere korrekt?

2. I ovenstående eksempel sættes drupal_page_is_cacheable til TRUE i hook_init(). Dette gøres ikke i ding_varnish implementation. Hvordan kan Drupal så vide, at den skal cache siden? Kan godt se, at den sender headers til varnish senere i hook_page_build() der fortæller at den skal cache, men kan ikke se hvordan Drupal får at vide den skal cache siden. Nogen der ved, om der er nogen speciel grund til, at man ikke har brugt drupal_page_is_cacheable() her?

#23 Updated by Jørgen Nielsen over 4 years ago

  • Status changed from DBC (waiting) to Needs code review
  • Assignee changed from Christian Vandel to Kasper Garnæs

Det er ikke Varnish, der er synderen - Jeg kan se, at der ikke er hit i Varnish cache på forsidens html-kode for hverken Ballerup, Gladsaxe eller Silkeborg bibliotek.

Så det må være Drupals cache, der ikke bliver clear'et, når et arrangement eller en nyhed bliver afpubliceret (det er modulet Scheduler, der står for dét).

Men: man kan sætte en regel op i Rules modulet, hvor man clear'er cache på forsiden, når en node publiceres/afpubliceres med Scheduler. Her er et pull request på dét:

https://github.com/ding2/ding_frontpage/pull/7

Bemærk for i øvrigt, at der kan være op til en times forsinkelse på afpublicering: Hvis der ikke er andet der trigger en cache clear, så vil det ske når der bliver kørt cron - og det sker en gang i timen.

//Jørgen

#24 Updated by Simon Holt over 4 years ago

Hej Jørgen

Ser ud til at være en fin løsning med Rules og Cache Actions :)

Men hvorfor bliver Varnish cachen clearet ved afpublicering og ikke Drupal (som det er nu)?

#25 Updated by Kasper Garnæs about 4 years ago

  • Assignee changed from Kasper Garnæs to Jørgen Nielsen

Jeg har reviewet løsningen og oprindelig også godkendt den, da den løser det konkrete problem.

Simons kommentar vedr. Varnish fik mig dog til at genoverveje situationen. Varnish bliver clearet pga. Expire modulet der samler en række url'er, der skal fjernes fra cachen når noder bliver opdateret - bl.a. forsiden. Varnish modulet implementerer hooks stillet til rådighed af Expire og sørger for at denne bliver clearet. Expire - i den version vi benytter - understøtter ikke Drupals page cache out of the box. Dette kan dog klares ved en opdatering af modulet til 2.x eller et lille ekstra modul, Expire Cache Page.

Expire gennemgår mange forskellige url'er ift. cache clearing (taksonomier, referencer, menu'er etc.) og jeg tænker derfor at problemet reelt set er meget større end bare forsiden (hvor det dog er mest prominent).

Derfor foreslår jeg en af to ting:

1. Vi beholder den nuværende løsning foreslået af Jørgen og laver et nyt issue på brug af Expire modulet til clearing af page cache (inkl. opdatering til 2.x af Expire)
2. Vi erstatter den nuværende løsning med Expire 1.x med det samme og benytter Expire Page Cache.

#26 Updated by Simon Holt about 4 years ago

Jævnfør også denne nyligt rapporteret sag:

http://platform.dandigbib.org/issues/1321

der omtaler denne bug:

https://www.drupal.org/node/2340829

Kan se at vi er ramt af denne, når jeg kører "varnishlog | grep ban" i terminalen.
Edit: beklager, så lige at denne bug er blevet introduceret efter den oprindelige bug i denne sag. Men det betyder altså at Expire slet ikke virker lige nu?

Har også fundet flere issues med Memcache modulet, som måske kunne være interessant at kigge på:
https://www.drupal.org/node/1634506 - Temporary cache is not being flushed on cron run
https://www.drupal.org/node/1954348 - Memcache problemer med View cache. Foreslået løsning: $conf['cache_class_cache_views'] = 'DrupalDatabaseCache'

Desuden kan jeg at den version vi kører af memcache er version 1.0, som er over 3 år gammel:
https://www.drupal.org/node/1410218

Alene ved opgradering til 1.1 skulle der være en performancegevinst på 1-5% at hente.

#27 Updated by Gitte Barlach about 4 years ago

  • Status changed from Needs code review to 7

Hej Jørgen

Kan du give et estimat på løsning 2, som foreslået af Kasper:

2. Vi erstatter den nuværende løsning med Expire 1.x med det samme og benytter Expire Page Cache.

#28 Updated by Rolf Madsen about 4 years ago

  • Target version changed from DDB CMS 2015 3. opgradering to DDB CMS 2015 4. opgradering

#29 Updated by Jørgen Nielsen about 4 years ago

Ikke nogen stor opgave - der skal rettes lidt i ding_varnish og konfiguration i ding_base.
Men: der skal tages stilling til, om yderligere expire-indstillinger er relevante taksonomier, referencer, menu'er etc. - se #25).
Jeg laver et pull request med indstillinger på expire ved node insert/update/delete

#30 Updated by Jørgen Nielsen about 4 years ago

  • Status changed from 7 to Needs code review
  • Assignee changed from Jørgen Nielsen to Kasper Garnæs

#31 Updated by Simon Holt about 4 years ago

Synes ikke helt jeg kan finde Expire Cache Page modulet. Linket fører til en side med et deprecated modul, der ser ud til at være blevet lavet om til en patch? Er det den i vil bruge?

#32 Updated by Jørgen Nielsen about 4 years ago

Simon Holt skrev:
> Synes ikke helt jeg kan finde Expire Cache Page modulet. Linket fører til en side med et deprecated modul, der ser ud til at være blevet lavet om til en patch? Er det den i vil bruge?

Nej, planen er at opdatere expire modulet til version 2.0-beta2

//Jørgen

#33 Updated by Simon Holt about 4 years ago

Der ser ud til at være en mindre uhensigtsmæssighed i den version af Memcache drupal modul (7.x-1.0) vi bruger, der gør, at CACHE_TEMPORARY items i cachen aldrig vil blive invalideret i et cron-job (Sider caches som CACHE_TEMPORARY):

Fra clear() metoden i Memcache backend (7.x-1.0):

    // It is not possible to detect a cache_clear_all() call other than looking
    // at the backtrace unless http://drupal.org/node/81461 is added.
    $backtrace = debug_backtrace();
    if ($cid == MEMCACHE_CONTENT_CLEAR || (isset($backtrace[2]) && $backtrace[2]['function'] == 'cache_clear_all' && empty($backtrace[2]['args']))) {
      // Update the timestamp of the last global flushing of this bin.  When
      // retrieving data from this bin, we will compare the cache creation
      // time minus the cache_flush time to the cache_lifetime to determine
      // whether or not the cached item is still valid.
      $this->cache_content_flush = time();
      $this->variable_set('cache_content_flush_' . $this->bin, $this->cache_content_flush);
      if (variable_get('cache_lifetime', 0)) {
        // We store the time in the current user's session. We then simulate
        // that the cache was flushed for this user by not returning cached
        // data to this user that was cached before the timestamp.
        if (isset($_SESSION['cache_flush']) && is_array($_SESSION['cache_flush'])) {
          $cache_bins = $_SESSION['cache_flush'];
        }
        else {
          $cache_bins = array();
        }
        // Use time() rather than request time here for correctness.
        $cache_tables[$this->bin] = $this->cache_content_flush;
        $_SESSION['cache_flush'] = $cache_tables;
      }
    }
    if (empty($cid) || $wildcard === TRUE) {
      // system_cron() flushes all cache bins returned by hook_flush_caches()
      // with cache_clear_all(NULL, $bin); This is for garbage collection with
      // the database cache, but serves no purpose with memcache. So return
      // early here.
      if (!isset($cid)) {
        return;
      }

Som man kan se detecter den et kald til cache_clear_all() metoden ved at bruge debug_backtrace() (da det er et rekursivt kald). Men system_cron() kalder ikke cache_clear_all() uden paremetre, men prøver i stedet at invalidere flere bins med cache_clear_all(NULL, $table). Som kan se i ovenstående vil dette få clear() metoden til returne uden nogen form for invalidering.

Dette ser ud til at være rettet i senere versioner af Memcache. Fra clear() metoden i version 7.x-1.5:

    // It is not possible to detect a cache_clear_all() call other than looking
    // at the backtrace unless http://drupal.org/node/81461 is added.
    $backtrace = debug_backtrace();
    if ($cid == MEMCACHE_CONTENT_CLEAR || (isset($backtrace[2]) && $backtrace[2]['function'] == 'cache_clear_all' && empty($backtrace[2]['args']))) {
      // Update the timestamp of the last global flushing of this bin.  When
      // retrieving data from this bin, we will compare the cache creation
      // time minus the cache_flush time to the cache_lifetime to determine
      // whether or not the cached item is still valid.
      $this->cache_content_flush = time();
      $this->variable_set('cache_content_flush_' . $this->bin, $this->cache_content_flush);
      if (variable_get('cache_lifetime', 0)) {
        // We store the time in the current user's session. We then simulate
        // that the cache was flushed for this user by not returning cached
        // data to this user that was cached before the timestamp.
        if (isset($_SESSION['cache_flush']) && is_array($_SESSION['cache_flush'])) {
          $cache_bins = $_SESSION['cache_flush'];
        }
        else {
          $cache_bins = array();
        }
        // Use time() rather than request time here for correctness.
        $cache_tables[$this->bin] = $this->cache_content_flush;
        $_SESSION['cache_flush'] = $cache_tables;
      }
    }
    if (empty($cid) || $wildcard === TRUE) {
      // system_cron() flushes all cache bins returned by hook_flush_caches()
      // with cache_clear_all(NULL, $bin); The expected behaviour in this case
      // is to perform garbage collection on expired cache items (which is
      // irrelevant to memcache) but also to remove all CACHE_TEMPORARY items.
      // @see https://api.drupal.org/api/drupal/includes!cache.inc/function/cache_clear_all/7
      if (!isset($cid)) {
        // Update the timestamp of the last CACHE_TEMPORARY clear. All
        // temporary cache items created before this will be invalidated.
        $this->cache_temporary_flush = time();
        $this->variable_set("cache_temporary_flush_$this->bin", $this->cache_temporary_flush);
        // Return early here as we do not want to register a wildcard flush.
        return;
      }

Jeg har ikke selv haft tid til at gå i dybden med det og teste, men synes det passer meget godt med de problemer vi har i denne tråd?

Men det er måske bevidst at i kører med en ældre version af Memcache for at undgå at cachen bliver invalideret i cron-jobs?

#34 Updated by Anonymous about 4 years ago

I DDB CMS 2.2.0 er der sikkerhedsopdateringer til 9 moduler og almindelige opdateringer til 25 moduler. Så det er formentlig et spørgsmål om prioritering at modulerne generelt ikke bliver opdateret ved nye DDB CMS versioner, hvilket de nok burde...

#35 Updated by Simon Holt about 4 years ago

Fuldt forståeligt, at man ikke bare opdaterer moduler. Specielt med et modul af denne type, er der jo brug for grundig gennemtest.

Men udover rettelsen omtalt i mit tidligere indlæg, skulle der også være en del andre bug-fixes og performance forbedringer ved opgradering af Memcache modul. Se bare changelog for version 1.1 (nyeste er 1.5):

https://www.drupal.org/node/2279367

Desuden er den version vi bruger fra januar 2012. Altså over 3 år gammel:

https://www.drupal.org/node/1410218

Så måske ville det være en god ide, at kigge nærmere på en opgradering her.

#36 Updated by Simon Holt about 4 years ago

Et andet problem med den gamle version af Memcache er, at form cachen kommer ud af synkronisering med page cachen.

Da vi bruger DrupalDatabaseCache til form_cache men Memcache til page cache, bliver form cachen clearet på Cron-Jobs men ikke page cachen. Dette burde give problemer med forældede form-id'er i page cachen som egentlig ikke ligger i form cachen længere.

Se denne tråd for mere info:

https://www.drupal.org/node/1634506

#37 Updated by Tina Skjærbæk Søeborg about 4 years ago

På forsiden af vores hjemmeside har vi et modul fra inlead, der viser dagens åbningstider: ding_library_opening_hours (https://github.com/easyddb/ding_library_opening_hours)

Men det ser ud til at have cachingproblemer, som Rasmus Justesen fra DBC siger, måske er relateret til dette issue.

Når man ikke er logget ind, viser hvidovrebib.dk åbningstiderne fra den dag, cachen sidst blev tømt. hvidobre.ddbcms.dk viser derimod dagens åbningstider (altså det korrekte), når man ikke er logget ind.

Hvis man tømmer cachen, opdateres åbningstiderne på hvidovrebib.dk, men de opdateres kun statisk, så næste gang de skifter på hvidovre.ddbcms.dk, er hvidovrebib.dk igen bagud.

Vi har oplevet fejlen siden vi lagde forside modulet på for halvanden siden. Vi er på DDB CMS 2.2.0. Vi har oplevet problemer med modulet før, men jeg er i tvivl om det er de samme problemer.

Sagsnummeret i DBC er 23665.

#38 Updated by Simon Holt about 4 years ago

Cachen bliver på nuværende tidspunkt kun clearet når nogen gør noget aktivt:

- Ryd cachen manuelt via 'admin/config/development/performance'. Her bliver drupal_flush_all_caches() kaldt hvilket resulterer i at både Page cachen i Memcache og Varnish bliver purget. Effekten kan ses med det samme.

- En redaktør/webmaster/administrator opdaterer en node. Her bliver cacche_clear_all() kaldt. Dette vil ikke resultere i en Varnish purge, men Memcache bliver invalideret, da den bruger debug_backtrace til detektere cache_clear_all() kaldet. så effekten ses først næste gang Varnish kigger tilbage efter en ny side.
(Rettelse: Expire modulet purger nodens side, så ved den vil man selvfølgelig se effekten med det samme. Med Den planlagte opdatering af Expire modulet vil andre relaterede sider, hvor noden optræder, også blive purget, så der bliver en markant forbedring her)

Som forklaret i et tidligere indlæg, vil cachen aldrig blive clearet/invalideret automatisk på Cron-jobs med den version af Memcahe modulet vi benytter.

Der arbejdes på løsninger på dette. Bl.a. Jørgen løsning med CacheAction og Scheduler modulets events. Men dette hjælper selvfølgelig ikke med åbningstider.

#39 Updated by Jesper Kristensen about 4 years ago

  • Status changed from Needs code review to Ready for development
  • Assignee changed from Kasper Garnæs to Jørgen Nielsen

#40 Updated by Rolf Madsen about 4 years ago

  • Status changed from Ready for development to Needs code review

#41 Updated by Gitte Barlach about 4 years ago

  • Status changed from Needs code review to Ready for development
  • Assignee changed from Jørgen Nielsen to per johansen

Hej Per
Har du mulighed for at kigge på denne, da Jørgen vist stadig har ferie ?
Jeg tror ikke det tager lang tid.

#42 Updated by Rolf Madsen almost 4 years ago

bump

#43 Updated by Rolf Madsen almost 4 years ago

  • Subject changed from Cache problemer på forsiden giver problemer med afpublicering og nye forsidekaruseller? to Cache problemer på forsiden giver problemer med afpublicering og nye forsidekaruseller? MANGLER AFSLUTNING AF CODE REVIEW

#44 Updated by Gitte Barlach almost 4 years ago

Hej Per
Har du mulighed for at se på den enkelte kommentar fra code review´et ?
Det vil være dejligt at få den med

#45 Updated by per johansen almost 4 years ago

  • Status changed from Ready for development to Needs code review
  • Assignee changed from per johansen to Jesper Kristensen

#46 Updated by Gitte Barlach almost 4 years ago

  • Status changed from Needs code review to Reviewed - Needs info/rework
  • Assignee changed from Jesper Kristensen to per johansen

Fra Jesper:

Ikke helt sikker på at jeg forstår hvad det nye pull request har med de forrige at gøre. De to gamle er til varnish og det ny laver et nyt menu callback?

Skriv venligst hvordan de to PR's kan blive til et i et helt andet modul?

#47 Updated by Gitte Barlach almost 4 years ago

  • Target version changed from DDB CMS 2015 4. opgradering to DDB CMS 2016 1. opgradering

#48 Updated by per johansen almost 4 years ago

  • Assignee changed from per johansen to Jesper Kristensen

det sidste pull-request hører til Issue 1104 .. ikke denher

#49 Updated by Martin Cording almost 4 years ago

  • Status changed from Reviewed - Needs info/rework to Needs code review

Made a new PR for this change: https://github.com/ding2/ding2/pull/101.

You can close the other ones.

#50 Updated by Jesper Kristensen over 3 years ago

  • Status changed from Needs code review to Reviewed

Afventer næste release

#51 Updated by Kasper Garnæs over 3 years ago

  • Status changed from Reviewed to Needs code review

Build for https://github.com/ding2/ding2/pull/101 fejler. Det refererer til en version af Varnish modulet der ikke findes.

Det er ikke Varnish modulet, der skal opdateres men i stedet for Expire modulet. Dette er rettet følgende pull request: https://github.com/ding2/ding2/pull/138.

#52 Updated by Kasper Garnæs over 3 years ago

  • Status changed from Needs code review to Technical test

Reviewed af Jørgen og godkendt.

#53 Updated by Gitte Barlach over 3 years ago

Testet på vanilla-alma.
Sagen her indeholder mange kommentarer. Jeg har i min test forholdt mig til den initale usecase ift. publicering og afpublicering af nyheder/arrangementer:

Jeg logger ind som admin og opretter en nyhed sætter den til at blive publiceret 16.2.16 kl. 15:20, samt afpubliceret kl. 16:00
Jeg logger ud

Publicering:
Kl. 15:45 kan jeg ikke se nyheden på forsiden som anonym bruger før jeg genindlæser siden ved klik på f5
Efter at have set nyheden på forsiden går jeg nu hen på h.h.v. Hovedbibliotekets landingpage (/bibliotek/hovedbiblioteket) samt Hovedbibliotekets nyhedsoversigt (/bibliotek/hovedbiblioteket/nyheder) ; på disse oversigter kan jeg ikke se nyheden som anonym bruger; men jeg kan se den når jeg logger ind.
Jeg logger ud igen. på Hovedbibliotekets landingpage (/bibliotek/hovedbiblioteket) kan jeg nu også se nyheden som anonym bruger. Det kan jeg til gengæld ikke på (/bibliotek/hovedbiblioteket/nyheder) - heller ikke selv om jeg genindlæser siden ved klik på f5. Jeg kan få nyheden frem ved at skrive et ? til sidst i url´en

Afpublicering:
kl. 16:18 - nyheden er nu til syneladende afpubliceret når jeg som anonym bruger kigger på forsiden, samt /hovedbiblioteket/nyheder. Men den findes stadig på /bibliotek/hovedbiblioteket. Logger jeg ind kan jeg se nyheden på alle siderne.

#54 Updated by Simon Holt over 3 years ago

Tror ikke at Expire af sig selv kan finde ud af at clearer bibliotekssider (eller temasider) i Varnish, hvis en node, der optræder på en af disse sider opdateres eller der indsættes en ny node, som skal optræde på en af disse sider.

Vi skal nok have tilføjet siderne 'bibliotek/' og 'tema/' til expire_node_custom_pages variablen. Der ser ikke ud til at være tilføjet noget i denne variabel i PR

#55 Updated by Gitte Barlach over 3 years ago

  • Status changed from Technical test to Reviewed - Needs info/rework
  • Assignee changed from Jesper Kristensen to Laura Holm

#56 Updated by per johansen over 3 years ago

  • Status changed from Reviewed - Needs info/rework to Development
  • Assignee changed from Laura Holm to per johansen

den snupser jeg

#57 Updated by per johansen over 3 years ago

jeg afprøver lige nogle ting på vanilla-alma .. skal nok lade være med at ødelægge noget

#58 Updated by per johansen over 3 years ago

  • Assignee changed from per johansen to Kasper Garnæs

okay. Jeg har prøvet expire af på upgrade-alma, og kunne ikke på nogen måde få det til at virke - jeg vil gætte på at der er en bug et eller andet sted i expire.

Rules derimod kan jeg godt få til at virke, men @Kasper har revertet det commit som jørgen havde lavet for at cache invalide forsiden.

Jeg vil foreslå at vi laver cache håndtering med rules - hvad siger i??

#59 Updated by Rolf Madsen over 3 years ago

  • Kategorier Inspiration - Forsiden, Inspiration - Karruseller added

#60 Updated by Rolf Madsen about 3 years ago

  • Target version changed from DDB CMS 2016 1. opgradering to DDB CMS 2016 2. opgradering

#61 Updated by Kasper Garnæs almost 3 years ago

Jeg ser fortsat hellere at vi bliver ved med at benytte det modulsæt, vi allerede benytter til dette formål.

I forhold til at cleare cachen for forsiden ved opdatering af noder, så er det understøttet er Expire modulet. Det kræver følgende:

1. Expire skal være slået til expiration
2. Expire skal reagere på node actions
3. Expire skal cleare forside cachen ved node actions

Jeg ved ikke hvad/hvordan Per testede (der er gået 8 måneder), men jeg kan se at Jørgen i sin implementation har sørget for alle 3 ting (1, 2, 3.

Hvad der er mere problematisk er at den konfiguration muligvis ikke bliver brugt på sites'ne pt. Jeg kan se på bibliotek.kk.dk at det ikke er tilfældet.

Jeg har her været inde og reverte konfigurationen, så den står som i koden, herefter har jeg slået debugging i expire til og testet. Her kan se både se at Expire prøver at cleare cachen for forsiden ved oprettelse af nyhed og at cachen bliver clearet i praksis.

For at komme videre med denne foreslår jeg derfor at vi skriver en update hook der sørge for at reverte variable for Expire modulet.

#62 Updated by per johansen almost 3 years ago

  • Assignee changed from per johansen to Gitte Barlach

Denher er lidt svær at afprøve - man kan ikke oprette nyheder på vanilla .... pga workflow -tingen (se http://platform.dandigbib.org/issues/1894).

Jeg har revertet ding_base featuren på vanilla-alma. Der var rigtigt nok nogle af expire modulets indstillinger der var overskrevet.

Udover det er issuet 8 mdr. gammelt - måske vi skulle verificere det.

#63 Updated by Simon Holt almost 3 years ago

Har lavet et PR der manuelt sætter kritiske variabler for expire:

https://github.com/ding2/ding2/pull/393

Ville ikke reverte feature komponenten da den er en del af ding_base og der er mange strongarmede variabler.

#64 Updated by Rolf Madsen almost 3 years ago

  • Related to Bug #1653: Opdatér Memcache fra version 1.0 til 1.5 added

#65 Updated by Rolf Madsen almost 3 years ago

  • Status changed from Development to Needs code review

#66 Updated by Gitte Barlach almost 3 years ago

  • Assignee changed from Gitte Barlach to Kasper Garnæs

#67 Updated by Jesper Kristensen almost 3 years ago

  • Status changed from Needs code review to Technical test
  • Assignee changed from Kasper Garnæs to Gitte Barlach

Reviewed og afventer næste release

#68 Updated by Gitte Barlach almost 3 years ago

  • Status changed from Technical test to Reviewed

#69 Updated by Kasper Garnæs almost 3 years ago

  • Status changed from Reviewed to Technical test

Merged.

#70 Updated by Rolf Madsen over 1 year ago

  • Description updated (diff)
  • Status changed from Technical test to Resolved

Also available in: Atom PDF