• Resolved kitchin

    (@kitchin)


    All the useless extra code that composer style development drops into directories like:

    • wp-statistics/vendor/geoip2/geoip2/tests/GeoIp2/Test/WebService
    • wp-statistics/vendor/symfony/event-dispatcher/Symfony/Component/EventDispatcher/Tests/Debug
    • wp-statistics/vendor/guzzle/guzzle/tests/Guzzle/Tests/TestData/services

    Can we wall of most of wp-statistics with .htaccess ? Can we delete some of these hundreds of useless files? Are they needed? Are they dangerous?

    I posted an answer at StackExchange about how to use the MaxMind GEO database with a very minimal composer footprint: https://stackoverflow.com/questions/21041463/get-a-localized-name-of-the-users-city-via-maxmind-geolite2-free Last time I checked it still worked.

    MaxMind’s file-based db is superior to the MySQL geo databases out there, I think. It’s easier to distribute. But the composer stuff is just utter cr*p in my opinion.

    https://www.ads-software.com/plugins/wp-statistics/

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Contributor Greg Ross

    (@gregross)

    I’m with you on the fact that there is a lot of file overhead in using composer to get the GeoIP library, but this is the recommended way to do it from the developers of the library.

    I’d rather spend time working on WP Statistics code than having to hack around with another library’s code to get it to work every time a new version comes out. Composer takes care of all that automatically.

    Thread Starter kitchin

    (@kitchin)

    Recommended by whom? Do they really recommend putting all that testing code on a live public-facing server? I imagine there is a composer config for deploying that culls it. But really, just look at my code linked above. Composer is not as mysterious as it seems. You only need about five files.

    You do not need the vendor directory at all, and that is where all the nonsense is. You are not branding it or doing complex code maintenance tasks, so you don’t need vendor. Took me a while to understand that!

    Plugin Contributor Greg Ross

    (@gregross)

    Straight from the GitHub page:

    We recommend installing this package with Composer.

    As I said, it’s a trade off. Customizing the process means we’re responsible if anything changes or goes wrong.

    Thread Starter kitchin

    (@kitchin)

    Nonsense.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Incredible amount of composer testing code: bad idea?’ is closed to new replies.