Upgrade to SilverStripe 4

[UndefinedOffset]

Upgraded to support SilverStripe 4.3+. Per @robbieaverill's recommendation in #133 I've removed the search functionality and related code from the module. I've also changed how the routing works to be registered with DevelopmentAdmin since I couldn't get the old routing to work at all without doing that. Perhaps it was something with how I set the after, not really sure either way having it registered with DevelopmentAdmin solves the routing.

As well exposing images for example from the documentation since the core now uses the public folder requires some more configuration on a per-case basis, meaning you must mark the folder path to be exposed like normal.

[UndefinedOffset]

I'm not really sure why Scrutinizer is not happy with composer, Travis seems to have installed properly. Though I'm working on the test failures ;)

[UndefinedOffset]

So the tests now pass locally because the module is not the root of the install but in the case of Travis it's the root which causes the DocumentationParserTest to fail in a couple spots. I'm torn as to whether adjust the tests or Travis (somehow).

[robbieaverill]

I had a quick look at the test failures, and they're not really great assertions anyway to be honest. I think we should get rid of the DOCSVIEWER_DIR constant and use module references e.g. silverstripe/docsviewer instead wherever possible. In the case of those assertions, you might also be able to break up the expected string into blocks and exclude the variable part of it (the DOCSVIEWER_DIR value).

[UndefinedOffset]

I agree about removing the DOCSVIEWER_DIR (same with the DOCSVIEWER_PATH) it's only used in the tests anyways but I will work towards removing it. As for solving the path failure issue in Travis, I think it's important that we do check the path re-mapping but it falls apart in Travis where the module is the root.

We could use regex to find the path with or without the vendor/silverstripe/docsviewer/ bit which would make Travis pass but also catch it when the module is properly installed. Not a great solution but it would work, ultimately I think the best route would be somehow having it properly installed into the vendor folder when Travis starts.

[UndefinedOffset]

In short the url remapping would either match Travis'es resources/tests/ or resources/vendor/silverstripe/docsviewer/tests/. So technically the remapping is correct in either scenario, if you needed to expose a folder in the root of the site then the path would be right.

[robbieaverill]

Great that you've got Travis passing. There's a conflict you'll need to resolve now as well. I'll just go and make sure that the master branch is ready for SilverStripe 4.x compat, then if you could rebase onto it that'd be awesome! Thanks again for the PR.

[robbieaverill]

BTW you may need to update the Scrutinizer configuration file. Here's a working example for the new Scrutinizer build engine (you may need to adjust src/code folder names):

checks:
    php: true

build:
    nodes:
        analysis:
            tests:
                override: [php-scrutinizer-run]

filter:
    paths: ["src/*", "tests/*"]

[UndefinedOffset]

Re-based, though Scrutinizer did not run at all based on this force push now? It was failing seemingly due to a composer issue.

[robbieaverill]

@UndefinedOffset yeah you'll need to update the Scrutinizer configuration to match the example I posted above. The config that's in this module already uses the old Scrutinizer build system which has an outdated version of Composer that isn't compatible with the recipe or vendor plugins that SilverStripe 4 uses. I've reopened the PR to see if it will re-trigger Scrutinizer, but doesn't look like it has.

[UndefinedOffset]

Well the updated config seems to have triggered Scrutinizer :) it looks like Travis failed :( because it lost connection to the DB during tests? Which is a new one lol...