As designed Installation of Public Routes Conflict

Lawrence

Well-known member
When installing an add-on that has the same public route name as another add-on, the newly installed add-on takes over the public route and breaks the other add-on. For example, if you install an add-on that uses "resources" and you have the Resource Manager installed, resources will no longer be associated with the Resource Manager.

I'm sure this happens with admin routes too, but as most developers use a unique identifier with their routes on the admin side, it is not as apparent.

To get around this behavior I removed the public routes from an add-on I am currently working on, so they would not get exported and put them into the installer script to check if the routes were available or not. That almost worked, :) but when you install an add-on XF deletes all routes associated with that add-on (my install script installed them, then XF removed them) and then does the import from the XML file (if available).

The fix would be to either check for existing routes early in the installation process and warn admins that there is a conflict and ask to continue with the installation or not. Or, what I favor, is to not export any routes when exporting an add-on (and remove the XML importing of routes), and let the installation script handle it. If a developer creates an add-on that uses it's own route(s), then they most likely have an install script, and adding this check, then inserting their own routes if available, is fairly simple.
 
In case it helps, I saw a similar scenario with Xen Media Gallery vs XenMedio. Both add-ons used the route "media", initially.

If XF ever implement a solution to this, great, but until then it might be considered best practice to more or less make the routes unique to the add-on.

This is how the default route in Xen Media Gallery became "xengallery".

Personally I hated that the add-on was not available from the route "media" by default. The solution was to use Route Filters.

During install, my installer checks to see if a route already exists for xengallery => media. If it doesn't, then a new route filter is added.

Then, if a person still has XMG and XenMedio installed, they can just resolve the conflict by changing the route filter from media to something else.
 
While I can take the point, this is how all of the import structures work over all content types: last in wins.

If you want to do some specific conflict detection for your setup, you can do so in the installer if needed, but unless you block the install, there will always be a conflict.
 
This is where this might be useful, @Lawrence:

https://xenforo.com/community/threads/assign-route-filters-to-addons.53491/

The same effect can be achieved manually in the installer as I described above, but if we could distribute a route filter with an add-on, then it would enable the use of a completely unique route prefix which is changed out of the box to something more aesthetically pleasing. Conflicts will still happen, but easily fixable from Route Filters in the Admin CP.
 
If you want to do some specific conflict detection for your setup, you can do so in the installer if needed, but unless you block the install, there will always be a conflict.

This is what I'm doing for my current add-on, a check is in place for public routes, and if a duplicate is detected, the route isn't installed (I don't want to break other add-ons), and it informs the admin of the conflict after installation is complete. The admin can then uninstall the add-on that is using that route, and if they do, my add-on then will re-install the route for itself. If they decide to not uninstall the other add-on, no big deal, there are other routes they can choose to install and use. This approach for me works fine, as only what is needed is used.

@Chris D your post was made before I submitted this one. I use route filters for Pages. Using them for add-ons I'm not convinced, only because they may make it appear to the end user that there is one url for two different add-ons.
 
Last edited:
Back
Top Bottom