1. 04 Jan, 2021 1 commit
  2. 22 Dec, 2020 1 commit
  3. 10 Nov, 2020 1 commit
  4. 11 Sep, 2020 1 commit
  5. 10 Mar, 2020 1 commit
  6. 25 Jan, 2020 1 commit
  7. 24 Sep, 2019 1 commit
  8. 16 Jul, 2019 1 commit
  9. 23 Apr, 2019 1 commit
  10. 14 Mar, 2019 1 commit
  11. 11 Dec, 2018 1 commit
  12. 27 Oct, 2018 1 commit
  13. 30 Sep, 2018 1 commit
  14. 13 Sep, 2018 1 commit
    • Christian Kuhn's avatar
      [BUGFIX] Adapt view related install tool details · b4008949
      Christian Kuhn authored and Benni Mack's avatar Benni Mack committed
      With the install tool move to modals, various details on CSS
      level broke: The modal HTML is on top level in backend and thus
      not within the content-iframe, so styles defined in install.css
      loaded in the iframe do not kick in. Since the standalone install
      tool does not use iframes, there are various differences on view
      level between standalone and embedded-in-backend version, usually
      with the embedded version looking more ugly than standalone.
      
      The install.css is not very different from backend.css anyway,
      so we resolve various details with the patch, kick install.css
      entirely and rely soley on backend.css, even for the installer.
      
      Details:
      * <hr> shows a border again in modals in embedded, broken since
        modal patch
      * image processing view has borders and other details again in
        embedded verision, broken since modal patch
      * removed 'fixed save button location' for 'all configuration' code.
        This broke with the modal patch, the code does not do anything
        useful at the moment. A solution needs a change of the modal js
        to render the buttons to modal-footer instead. This is too complex
        for this patch and may be done with another patch.
      * A couple of classes to easily limit styles to installer and
        maintenance parts
      * Remove left overs from old install-tool menu approach that
        have not been cleanup up, yet.
      
      Resolves: #86245
      Related: #84772
      Releases: master
      Change-Id: I4d21677331112a48f84b0cf48a574999128a15b7
      Reviewed-on: https://review.typo3.org/58269
      
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      b4008949
  15. 06 Jul, 2018 1 commit
  16. 03 Jul, 2018 1 commit
  17. 14 Jun, 2018 1 commit
    • Benni Mack's avatar
      [FEATURE] Enable SQLite in installation process · 0b00b424
      Benni Mack authored and Susanne Moog's avatar Susanne Moog committed
      The patch adds SQLite as new DBMS platform to the TYPO3
      instance installer if pdo_sqlite is available.
      
      * sqlite has no database name and user / password restriction
        but stores the database in a single file.
      
      * the filename contains a random string so it can't be easily
        guessed if the config directory is within web document root
        and the web server is configured to deliver .sqlite files.
      
      * the feature .rst file mentions possible security risks comes
        with having a database within document root and documents
        how to prevent those.
      
      * similar to mysql and postgres, an acceptance test verifies
        the system can be successfully installed using a blank
        installation and using the introduction package.
      
      * bamboo plan spec is adapted to execute the sqlite installer suite
      
      * testing-framework is raised to 3.8.1 supporting the ac test:
        composer update typo3/testing-framework
      
      Resolves: #85256
      Releases: master
      Change-Id: I91a8c98f868b5e29bee4ad7dedd3cc8c50346452
      Reviewed-on: https://review.typo3.org/55563
      
      
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <susanne.moog@typo3.org>
      Tested-by: Susanne Moog's avatarSusanne Moog <susanne.moog@typo3.org>
      0b00b424
  18. 27 Apr, 2018 1 commit
  19. 20 Nov, 2017 1 commit
  20. 19 Sep, 2017 1 commit
    • Christian Kuhn's avatar
      [TASK] Install tool: JS driven routing · 3896e163
      Christian Kuhn authored and Susanne Moog's avatar Susanne Moog committed
      The install tool suffered from three main issues since 6.2 rewrite:
      * The "step" installer was re-used for recovery and installation
      * The routing logic was server based and threw lots of redirects
        which lead to redirect loops
      * The Controller/Action class structure was weird and hard to
        understand
      
      The patch solves this with a rather huge rewrite:
      * There are two request handlers: One for the Installer, one for
        the install tool.
      * A simple list of controllers. One InstallerController for the
        step installer, the others for the main module points of the
        install tool and a Login and a Layout controller.
      * Single action code is moved into controllers.
      * Both tool and installer first load only a <head> section that
        contain JS references. All other calls are ajax based and the
        routing is done JS side.
      * Installer and install tool no longer share controller code
        or templates, the installer can potentially be fully extracted
        from ext:install in another step.
      * Installer.js is the "walk through installation" module of the
        installer.
      * Router.js is the routing module for the install tool, all tool
        ajax requests get specific urls from this module and hand over
        errors to the Router.
      * Error handling is handled on JS side: If for instance
        the login session expires and user clicks elsewhere, a 403
        response is returned which is handled by JS to route to login.
        This is also the place where a recovery can hook in later.
      * The silent configuration updater is executed again which was
        removed during one of the previous master patches.
      * The template structure is much easier.
      * Various card content which has been calculated when loading
        the card layout is moved to the ajax code for single card
        content. That increases the performance of the main module
        points and makes them pretty snappy.
      
      Change-Id: Ib40f40acba17bb47142c0da1bcfb389ab9b4b3a1
      Resolves: #82504
      Releases: master
      Reviewed-on: https://review.typo3.org/54128
      
      
      Tested-by: default avatarStefan Neufeind <typo3.neufeind@speedpartner.de>
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Mona Muzaffar's avatarMona Muzaffar <mona.muzaffar@gmx.de>
      Tested-by: Mona Muzaffar's avatarMona Muzaffar <mona.muzaffar@gmx.de>
      Tested-by: Susanne Moog's avatarSusanne Moog <susanne.moog@typo3.org>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <susanne.moog@typo3.org>
      3896e163