Is there any way to identify a resource that's being previewed?

I'm cleaning up a snippet for a client in Evo 1.0.2. It was causing a parse error whenever I previewed it, and I've determined that it's because the snippet is looking for "id" in the query string. The site has FURLs turned on, which means the snippet is actually working fine, except during preview, which uses "id" to identify the resource.

I'd rather not change the name of the variable or the default "id" querystring parameter in preview (not even sure if this is possible like it is in Revo), because I think it would screw up some other site functionality. Is there an easy way to tell a previewed resource apart from a FURL resource, like maybe something in $_POST or session? If I can tell the difference, I think I can come up with some sort of exception in the snippet logic.

Should be able to use $_GET['id']

Manager actions are loaded with manager/index.php?a=xxx&id=yyy, where xxx is the action and yyy is the id of the item being worked on, whether it's a resource or an element. The actions can be located in the Manager's index.php file, which is mostly just a huge switch to include the various action files called for. [ed. note: sottwell last edited this post 14 years, 8 months ago.]

I may not have explained myself well, but that's the point -- I can't. The snippet is using $_GET['id'], but it's an ID that has nothing to do with the resource's ID (it's a row ID for a custom table). It's fine when I'm not choosing to preview, but it's a problem when I do, as that's the same param MODx uses in the URL in preview mode.

Ok, looking more closely at how it works, the preview just opens the page in a new window. It shouldn't behave any differently than opening the page in any other manner. If you have a snippet that gets the documentIdentifier, then that should be working.

[ed. note: sottwell last edited this post 14 years, 8 months ago.]

Actually, to be honest, I never use the page preview feature. I always open another tab, or even better another browser (where the page view won't be affected by my Manager login status), to the front-end and refresh or reload to view changes.

Ok, looking into the code, it looks to me like you'll have to upgrade to 1.0.5, or with 1.0.6 as soon as it's released in a few days, which would be a very good idea as this will also patch several rather unpleasant security vulnerabilities.

Here's how 1.0.2 generates the URL for the previewed resource:

and here's how 1.0.5 does it


You could also edit the manager/actions/mutate_content.dynamic.php file at line 538 and replace the onclick attribute with this:

Thanks, Susan. I think your last idea to tack an additional parameter onto the makeUrl function could work. I'll have to see if the client's even interested: it's sort of a non-issue on the live site, so he may not care.

The difference between 1.0.2 and 1.0.5 is that in 1.0.2 the preview's URL is hard-coded, while 1.0.5 uses makeUrl to generate the URL according to the site's configuration.

I always try to avoid common key names in these cases. For example, I'd use row_id in my snippet instead of id, to avoid this kind of potential conflict. This kind of problem crops up from time to time, and that's the obvious solution.

I agree -- I also try to avoid potentially conflicting params, but this was work on a legacy site that someone else coded. I could go through and change the param, but it means changing it in, I would think, quite a few places.

Honestly, that still might be the better option, or maybe just not even fixing this, since it's not really an issue on the live site. I was sort of looking for a theoretical discussion of what could be done if I had to, and that's exactly what you gave me. Thanks!