aliasMap in FURL mode

After some checking in core code I understand that it should contain all possible URIs of published resources and if it doesn't contain it then error page is displayed. But it doesn't contain main (start) page - so how parameters from URL are supposed to be passed to starting page ? [ed. note: khyrlik last edited this post 14 years, 1 month ago.]

The site_start responds to the site_url. Though it can also be 301 redirected from the URI specified for it.

You may also set an alias for the start page. It will be accessible via http.://site_url/home_alias. The downside to this is that all of your children of the home page will use the alias of the start page. This will make URL params accessible.

Another option is that you can also modify your Snippet/Plugin to handle this automatically.

But still, how parameters are supposed to be passed to Resource which is site_start, when it's not available in aliasMap?

The cache is completely generated based on requested URLs. If you start with an empty cache, it will not have any documents until they are requested. The same applies to Snippets, Plugins, etc. This doesn't effect parameters in any way.

URL Parameters are not in any way based on the cache. The cache/alias map only refers to a URI that results in a direct request. Parameters are generally handled automatically, especially when you get a document from a direct URL.

Custom Aliasing is the technique of using a Plugin to return results that could not have been found using the MODx resolver. This is done with the statement $modx-sendForward(id). In these cases, you may also manipulate parameters based on the whatever URL structure you decide to apply. This is because it all goes into the $_REQUEST variable in PHP. You may add, change, or remove variables in the $_REQUEST array at will. This is all demonstrated pretty easily by the tutorials on Custom Aliasing that i have done. In fact, my AJAX Framework which takes a URL that fails and determines if it is valid request and therefore returns a result instead the 404 page. You can, in other words, send params to any page you want under whatever circumstances you desire.

It's very well put. But I am asking about something different. You see, this is part of handleRequest function of modRequest:

In this part if no alias is found we get error page. If we put parameters to resource which is our starting page they will be probably passed as sitename.com/parameter/parameter or whatever other format we use and we will end up with error page, cause there is no such thing in aliasMap table.

This is why many make a Plugin that handles specific custom aliasing and it applies to the information you have provided thus far. Anytime you add a URL parameter, an OnPageNotFound will fire. The Plugin is made to respond to the OnPageNotFound.

In the Plugin, you parse the $_REQUEST, $_GET or $POST (depending on need) and return the Resource you want. It is a fallback in case the system cannot find the Resource based on the URL (which it never will in the case of URL parameters).

It's some way to work this out but for me it more looks like hole in design when very basic situation would require writing extra code by every user. I am not here cause I enjoy bashing other people's work but to get sure it was really meant to be this way. This is part of core so it affects every site made in MODX.

This is part of core so it affects every site made in MODX.

You are correct, however, this is not MODx's issue. In order to be compatible, MODx must handle URLs according to the server parameters. Friendly URLs are simply one standard implementation of custom aliasing. The URL requested still fires Not Found to the server, MODx just interrupts it,

So are System Events and Plugins. URL Params are not handled by nearly any system automatically. They are all a part of the technique known as custom aliasing. Previously to custom aliasing, all params were sent with $_GET or $_POST (even $_PUT and $_DELETE are not fully implemented).

Additionally, MODx doesn't restrict a user's aliasing needs, so they can't force a conformation. This might conflict with server settings, .htaccess settings, etc. So they give you Plugins so that you can make a custom solution.

Here's an example: some poeple want "mobile.domain.tld/path" for their sites and others want "domain.tld/path/mobile". MODx does not make the decision, that's your call. What you consider basic, others may consider a hassle and vice versa. This is also why I write many tutorials on extendable Custom Aliasing (including with URL Params). [ed. note: fuzzicallogic last edited this post 14 years, 1 month ago.]

Ok, I realize that the user can work around this, but some are less experienced It requires a lot of work and knowledge for something that should just work OOTB for any simple site and not some my fancy eccentric object but for some basic ones including "standard" Extras.
This is kind of problematic clash when (for starting page) makeURL() generates URLs without Resource's alias (just this object's alias, not full URL) alias and Handling requires this alias to find and handle requests back.