Changes between Version 6 and Version 10 of Ticket #590


Ignore:
Timestamp:
09/06/13 16:36:25 (3 years ago)
Author:
jim
Comment:

Actioned:

11.. OK so I've gone ahead and done H, set up ​http://www.transitionnetwork.org/403/permission-denied, tested (works fine after a tweak) and removed CustomError?. We can roll back if any issues arise by reinstalling CE and putting the contents of the two new pages back inside -- I don't foresee any issues now I've tested, and that's one pointless module gone.

We have a slightly slimmer site with less overheads! And less sessions/better caching! Merry Christmas!

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #590

    • Property Add Hours to Ticket changed from 1.0 to 0.65
    • Property Total Hours changed from 3.95 to 4.6

  • Ticket #590 – Description

    v6 v10  
    2424'''G) Enable ESI (Edge Side Includes) integration module, ensure Drupal renders only what it needs to ''' 3-8 hours, high reward, medium risk -- BOA packages the [https://drupal.org/project/esi ESI (Edge Side Includes integration) module], which makes NginX cache the whole page (as it does now), but also for user-logged in pages (which it does for 5 seconds since the page data changes). This means Drupal renders the ESI component (blocks, panels panes) that are have user-specific data in. Potential boost quickly, but will need time to tweak settings to get best from this across whole site. See [https://tech.transitionnetwork.org/trac/ticket/590#comment:4 comments in 4 & 5 below for discussion], should be done after proposal F, above. 
    2525 
    26 '''H) Remove CustomError module all together''' 1/2 hour, low risk, low reward -- We should take out the PHP code from the 403 section of CustomError and put it into a simple page entry. See comment 6 below as this has happened for 404s (which need no PHP). We can then remove the CustomError module all together, saving lots of sessions. I would go ahead and do this but since the 403 page has various displays depending on user type, I wanted to raise it here as it *may* have side effects. Or not... 
     26'''H) DONE: Remove CustomError module all together''' ~~1/2 hour, low risk, low reward -- We should take out the PHP code from the 403 section of CustomError and put it into a simple page entry. See comment 6 below as this has happened for 404s (which need no PHP). We can then remove the CustomError module all together, saving lots of sessions. I would go ahead and do this but since the 403 page has various displays depending on user type, I wanted to raise it here as it *may* have side effects. Or not...~~