Extracting the IP class into a standalone "network" component · Issue #6494 · matomo-org/matomo · GitHub
Skip to content

Extracting the IP class into a standalone "network" component #6494

Closed
@mnapoli

Description

Related to #6487

What about moving the Piwik\IP class out of Piwik and into a standalone repository?

Most of this class is completely unrelated to Piwik, I've done a POC and it was fairly easy to move it out. The good thing with this is that we can take advantage of this to refactor it into a non-static class. And we can also add more unit tests as the new class will have no global state.

Piwik\IP would actually be kept where it is for backward compatibility, however the content of the class would be moved.

After a quick discussion with some of us we thought naming that new component network would be better than ip, it leaves us the opportunity to move additional classes in there later if applicable. Thoughts?

We also thought about moving Piwik\Url in the new component. But I disagree with that because Piwik\Url has actually much more to do with the current request than urls (i.e. it's mostly a wrapper over $_SERVER). I see that class replaceable with a Request class (either Symfony or our own or whatever, that's not the topic), and to me it belongs more in a HTTP/MVC component (like Symfony's HttpFoundation for example). For the few methods that are strictly related to URLs (i.e. manipulating string urls), 3rd party librairies already cover that (e.g. http://url.thephpleague.com/). So all in all, I don't think Url should be moved to the network component, at least not right now.

Metadata

Assignees

No one assigned

    Labels

    RFCIndicates the issue is a request for comments where the author is looking for feedback.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions