1. 11 Jun, 2015 3 commits
  2. 28 May, 2015 1 commit
    • azul's avatar
      bring back ErrorNotFound, drop per site i18n · 6f0b4b56
      azul authored
      ErrorNotFound is similar to ActiveRecord::RecordNotFound - but it allows
      specifying the type of thing that was not found for more detailed error
      For the translations we use cascading translations. So say a group was not
      found... we will lookup the following:
      For all of these %{thing} will be interpolated with a translation of :group.
      If there is no translation for the given class of things it will be an empty
      In order for the cascading translation to work we have do drop the support
      for site specific translations. Otherwise the lookup will start with a
      cascade from:
      and succeed when looking up 'not_found'.
      So it won't process the more detailed cascade correctly.
      Alternatively we could add the site scope last. But I think site specific
      translations are not something we will need any time soon and it adds a lot of
      complexity. Instance specific translations can easily be put in
      and overwrite the defaults.
  3. 21 May, 2015 2 commits
    • azul's avatar
      use custom subclass of AD::PublicExceptions · f657b301
      azul authored and azul's avatar azul committed
      For a 404 it will use our own controller and fall back to the standard pages in public.
      Everything else still uses the ActionDispatch::PublicExceptions. We still try to rescue
      everything else within the app anyway.
      In case there is a 500 (or 422) we do not rely on the ExceptionsController but use a plain
      file for now.
    • azul's avatar
      first take on using an exception app for 404s · 09523369
      azul authored and azul's avatar azul committed
  4. 19 May, 2015 1 commit
  5. 08 May, 2015 3 commits
  6. 06 May, 2015 3 commits
    • azul's avatar
      cleanup: remove all traces of MODS · 63f3ba3d
      azul authored
      We can bring them back in case we need them again at some point.
      Rails seems to have it's own mechanisms for allowing such things now such
      as the engine load order and overwriting model behaviour by including
      Concerns in config.to_prepare.
      I think this also does what we want in terms of reloading files in development
      and caching them in production.
    • azul's avatar
      use initializer method for page registration · 340d84ad
      azul authored
      Not sure which one i prefer. initializer method allows specifying the
      order more explicitly and could probably be combined into a
      register_page method to be included in all Page Engines
    • azul's avatar
  7. 22 Apr, 2015 2 commits
  8. 20 Jan, 2015 1 commit
  9. 09 Oct, 2014 1 commit
  10. 17 Sep, 2014 1 commit
  11. 09 Sep, 2014 1 commit
    • azul's avatar
      set config.secret_token · 01ad6721
      azul authored
      I had moved it into config.session_store[:secret] which was obviously wrong.
      Rails is demanding this or won't render meaningful pages.
      However the config setting in the session_store initializer used to be Cookie_secret.
      I have not found any documentation on cookie_secret. config/initializers/cookie_verfification_secret.rb states we do not want a cookie_verification_secret.
      The CHANGELOG for rails 3 states:
      Renamed config.cookie_secret to config.secret_token and pass it as env key.
      So I assume 'secret_token' is what we want.
  12. 04 Sep, 2014 1 commit
  13. 03 Sep, 2014 2 commits
  14. 24 May, 2013 1 commit
  15. 30 Mar, 2013 2 commits
  16. 19 Feb, 2013 1 commit
  17. 16 Feb, 2013 2 commits
  18. 13 Feb, 2013 3 commits
  19. 12 Feb, 2013 3 commits
  20. 11 Feb, 2013 1 commit