mrclay/Elgg-Url.php

I've amended this to no longer return GUIDs for paths like: /SOMETHING/group/123/all. This is a special case of a listing of elements within a group, and the getGuid() method is really designed to tell you if the GUID in the URL represents a particular entity. Group profile URLs will still return the GUID, but, e.g. group files, will not.

If you need to capture this GUID used as a container (via some a new method), I'm open to adding that.

This was updated again, and now detects container GUIDs (in a few cases) and no longer reports foo/add/1234 as a GUID, but rather a container.

there are some url which goes by username
http://ss.localhost/blog/owner/user1

i noticed that my plugin that uses this gist was totally failing to return any data from the analyze function.
debugging the issue i see that the regex being used here is broken:

if (!preg_match('~^(https?)\\://([^/]+)(/[^\\?]*)~', $url, $m))

if i test this using my handy regex tester tool (https://regex101.com/) i notice two apparent problems:

1. the pair of backslashes that follow the https? capturing group appear to serve no purpose and will cause the process to never return a url.
2. if i remove those backslashes and use a test url that doesn't have a path following the domain name, then nothing is returned.

if i remove the backslashes and use a url that does have a path (after the domain) then it appears to work ok.

why are those slashes in there? won't they always stop the code from working properly? (at all)

The regex tester is not PHP. In PHP the literal, '\\' represents the string \. And in PHP's PCRE patterns, an escape is actually needed before :. There may be a bug, but that's not it.

This class should go in its own project...