Allow Route Types to be defined

[digitalpoint]

It would be nice if we had a "xf_route_type" table that defined the types of routes (admin and public by default).

Have been trying to figure out the best way to have a sub-domain with a lot of different routes that are specific to just that sub-domain... Some examples (vBulletin based):

Our tools section: http://tools.digitalpoint.com/ 19 different tools, some of which are very complex (like our keyword tracker).

Digital Point Ads: http://advertising.digitalpoint.com/ Probably going to end up with about 10-15 routes depending on how I set it up within XF.

I imagine some will want to put the resource manager on it's own sub-domain when it's available, so it would need it's own index prefix for it's route.

Then you could just have an index.php file with a unique Dependency class for the sub-domain.

 

[xf_phantom]

How did you accomplish this at dp? new dependency object or via the event system

 

[Jeremy]

If I remember correctly, it was "very hackish" and not something he'd recommend doing.

 

[Jon W]

The new init_router_public code event listener makes this a bit easier.

 

[digitalpoint]

How did you accomplish this at dp? new dependency object or via the event system

It's seriously a cluster****. I just assume it's all going to break on a XF upgrade one day. It still works under 1.2, but literally everything about it is a giant hack and really will probably break if the underlying Zend Framework is updated.

Routes on sub-domains had to be hard-coded to those sub-domains... meaning you can't just move an addon to/from a sub-domain if you wanted without making a ton of internal changes to the addon.

The whole thing takes advantage of some Zend Framework code that is in there for IIS servers (I'm kind of exploiting that fact even though I don't use IIS).

I haven't yet looked at the new init_router_public listener, but hopefully it ends up being a better way to do it. We'll see...

 

[Paul B]

As per rule 1:

Please do not attempt to circumvent the censoring options we have set up.

http://xenforo.com/community/help/terms

 

[digitalpoint]

As per rule 1:

http://xenforo.com/community/help/terms

Self-censoring is considered circumventing the censoring options? Strange, but okay... {shrug}

Sounds kind of silly I know, but I honestly don't have any clue about how XF's censoring system works... so we should just write whatever and the system censors for us, or?

 

[Paul B]

Just type the word normally - if it is configured in the censor it will be replaced.

 

[digitalpoint]

Just type the word normally - if it is configured in the censor it will be replaced.

Ah, okay... never used the censoring stuff in XF, so honestly had no clue how it works.

Testing the cluster****.

Edit: looks the same to me... how did you even know the system didn't do it? haha

 

[Jeremy]

Ah, okay... never used the censoring stuff in XF, so honestly had no clue how it works.

Testing the cluster****.

Edit: looks the same to me... how did you even know the system didn't do it? haha

The f & k were there. The sensor is not set up to censor "uc".

 

[Paul B]

Edit: looks the same to me... how did you even know the system didn't do it? haha

The original content remains (click edit) - it is censored when the page is rendered

Very useful as it doesn't actually alter the content in the post table, meaning you can add/remove censored words whenever you like, without it permanently affecting post data.