Five Things I don’t like about MODx Revolution

No one has mentioned a solution to the issue of per-user pages: the tree_root_id User Setting. It’s quick and easy and each user can only see his or her own page (and potentially it’s children).

Quote from: BobRay at Nov 08, 2010, 01:37 PM

No one has mentioned a solution to the issue of per-user pages: the tree_root_id User Setting. It’s quick and easy and each user can only see his or her own page (and potentially it’s children).

I wasn’t talking about backend access! We needed frontend access to a secure section of the website, where only one page would be available to one user...

3) Nested URL paths

It’s a simple thing, but it nags the hell out of me! Friendly urls are an integral part of MODx, which is nothing special. There is also an option for so-called “alias paths”. Activate this, and you should get permalinks that are based on the page hierarchy, e.g. “http://example.com/company/history.html”. So far, so good.

The internal link creating system, however, does only do “docrelative” permalinks. These permalinks typically do not start with a slash or the base URL, but look like this: “company/history.html”. If you use this link on a page that is not on the first level in hierarchy, it’s rendering a wrong link which leads nowhere. Yes, MODx literally generates wrong hyperlinks, when using “alias path”. And to be honest: Everybody should use “alias path”, because it’s useful for humans and search engines alike!

It would be so simple! If “alias path” is activated, put the base URL in front of every generated permalink. But instead, the official manual advices you to use the old and almost forgotten HTML <base> element on every page to fix the problem. Which has the side effect that you cannot use internal jumplinks anymore. This is embarrasing, but my forum post did not attract any reactions, which is funny. I can’t be the only one with this problem! (filed as a bug now, let’s see if it will be fixed soon.)

Quote from: BobRay at Nov 08, 2010, 01:37 PM

No one has mentioned a solution to the issue of per-user pages: the tree_root_id User Setting. It’s quick and easy and each user can only see his or her own page (and potentially it’s children).

I wasn’t talking about backend access! We needed frontend access to a secure section of the website, where only one page would be available to one user...

<?php
/* MemberPages Snippet */
/* First, reject any users who are not logged in */
if (!$isAuthenticated = $modx->user->hasSessionContext($modx->context->get('key')) ) {
    $modx->sendUnauthorizedPage(); /* could also redirect to the Register page here */
}
/* if it's not the user's page, send them to the Members page */
$tr = $modx->getOption('tree_root_id');
if ($tr != $modx->resource->get('id') ) {
    /* return "Wrong Page Tree Root:" . $tr . " Page ID: " . $modx->resource->get('id'); */
    $modx->sendRedirect($modx->MakeUrl(##)); /* replace ## with the ID of the "Sorry" page */
}
?>

@Bob
Thank you for taking the time to write the code.

Quote from: gerritvanaaken at Nov 07, 2010, 03:46 PM

It really is good to hear that most of my problems are well-known and being worked on! Keep up with that!

But still I have to drop a few lines on the alias path (sorry for being so annoying). MODx is not the only CMS with the ability of handling virtual folders...

Using relative paths to do the same thing is simpler and more efficient IMO. I’m sure it works different than other CMS’s, but it would complicate the system (and component development) enormously to have to calculate and manipulate server variables to some virtual folder path that doesn’t really exist on every request. And FWIW, you are welcome to prefix your links with

[[+base_path]]

or you can use

[[~7? &scheme=`abs`]]

to generate an "absolute" URL already prefixed with the base_path; similarly with the makeUrl() API method:

<?php
$url = $modx->makeUrl(7, '', '', 'abs');

[[+base_path]]

[[++base_url]]

We also appreciate Revolution very much.

Nevertheless Revo is not usable for us in commercial projects yet because there is no satisfactory way to produce single ssl-pages.

Our question: How much do we have to donate for getting a well working ssl-feature for single ssl-pages?

Letti

what problem do you exactly have with this solution from Marc posted in German board? (apart from the error page which could be sovled via htaccess 404 page-setting)