Error after updating getResources

☆ A M B ☆
1,780 Posts

Frogabog Reply #11, 13 years, 8 months ago

Right, so I ran this in mod.class.php and the result at first, was this:

[2013-01-01 01:49:55] (ERROR @ /index.php) `0` is not a valid integer and may not be passed to makeUrl()
[2013-01-01 01:49:55] (ERROR @ /index.php) #0 /paas/c0440/www/core/components/discuss/model/discuss/discuss.class.php(169): modX->makeUrl('0')
#1 /paas/c0440/www/core/cache/includes/elements/modsnippet/50.include.cache.php(40): Discuss->initialize('web')
#2 /paas/c0440/www/core/model/modx/modscript.class.php(66): elements_modsnippet_50(Array)
#3 /paas/c0440/www/core/model/modx/modparser.class.php(484): modScript->process(NULL)
#4 /paas/c0440/www/core/model/modx/modparser.class.php(221): modParser->processTag(Array, true)
#5 /paas/c0440/www/core/model/modx/modresponse.class.php(83): modParser->processElementTags('', '[[!Discuss]]', true, false, '[[', ']]', Array, 10)
#6 /paas/c0440/www/core/model/modx/modrequest.class.php(144): modResponse->outputContent(Array)
#7 /paas/c0440/www/core/model/modx/modrequest.class.php(128): modRequest->prepareResponse()
#8 /paas/c0440/www/core/model/modx/modx.class.php(1312): modRequest->handleRequest()
#9 /paas/c0440/www/index.php(72): modX->handleRequest()
#10 {main}

There is no snippet or plugin with an ID of 50 although the Discuss snippets started at id 48 through 58 (or something like that). ID's 50 and 51 were not existent.

So, since loading up Discuss was just on a whim while developing a template at Cloud, I reinstalled Discuss, and then since it didn't give me any new snippets, I uninstalled it.

makeURL error remains, and the stack trace shows this now:

[2013-01-01 02:07:52] (ERROR @ /index.php) `id` is not a valid integer and may not be passed to makeUrl()
[2013-01-01 02:07:52] (ERROR @ /index.php) #0 /paas/c0440/www/core/model/modx/modparser.class.php(1271): modX->makeUrl('id', '', '', '-1', Array)
#1 /paas/c0440/www/core/model/modx/modparser.class.php(447): modLinkTag->process(NULL)
#2 /paas/c0440/www/core/model/modx/modparser.class.php(221): modParser->processTag(Array, false)
#3 /paas/c0440/www/core/model/modx/modparser.class.php(399): modParser->processElementTags('[[!getImageList...', '!getImageList? ...', false)
#4 /paas/c0440/www/core/model/modx/modparser.class.php(221): modParser->processTag(Array, false)
#5 /paas/c0440/www/core/model/modx/modchunk.class.php(118): modParser->processElementTags('[[$soBoxyBasicP...', ' <div class="ro...', false, false, '[[', ']]', Array, 10)
#6 /paas/c0440/www/core/model/modx/modparser.class.php(455): modChunk->process(NULL)
#7 /paas/c0440/www/core/model/modx/modparser.class.php(221): modParser->processTag(Array, false)
#8 /paas/c0440/www/core/model/modx/modtemplate.class.php(120): modParser->processElementTags('[[]]', '[[$soBoxyHeader...', false, false, '[[', ']]', Array, 10)
#9 /paas/c0440/www/core/model/modx/modresource.class.php(318): modTemplate->process()
#10 /paas/c0440/www/core/model/modx/modresponse.class.php(75): modResource->process()
#11 /paas/c0440/www/core/model/modx/modrequest.class.php(144): modResponse->outputContent(Array)
#12 /paas/c0440/www/core/model/modx/modrequest.class.php(128): modRequest->prepareResponse()
#13 /paas/c0440/www/core/model/modx/modx.class.php(1312): modRequest->handleRequest()
#14 /paas/c0440/www/index.php(72): modX->handleRequest()
#15 {main}

#3 refers to the getImageList call from a MIGX TV.
#5 refers to a static chunk between the head and footer chunks and an obscure div class=row element (this class appears more than once in the chunk so I can't say which it is)
#8 refers to the actual head chunk, also static. Nothing else in this line gives clue.

So, since others have posted here, I will too. My problem lies in the fact that image TV's do not work. No image output at all from the MIGX TV, but containers show. When I call a simple image TV in the template all I get is the image name, no path. If the image TV is set to default output, I see the image name in the output. If set to image, there's no output but I so get a href="imageName.jpg" in the source.

I don't know if it's related to the makeURL error or not.

MODX Cloud Dev environment.

Ideas?

Frogabog- MODX Websites in Portland Oregon
"Do yourself a favor and get a copy of "MODX - The Official Guide" by Bob Ray. Read it.
Having server issues? These guys have MODX Hosting perfected - SkyToaster

MODX Staff
10,725 Posts

opengeek Reply #12, 13 years, 8 months ago

Using the alias is not a valid way to create a link except in a one configuration of friendly URLs. And the error message is just informing you that you have an invalid tag in your content. Why would you want to get rid of it?

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

15 Posts

adi778 Reply #13, 13 years, 8 months ago

Quote from: opengeek at Jan 02, 2013, 09:24 AM

Using the alias is not a valid way to create a link except in a one configuration of friendly URLs.

I realize that it's not a solution but it's all I could do and if you have a better suggestion then I'd love to know it.

Quote from: opengeek at Jan 02, 2013, 09:24 AM

And the error message is just informing you that you have an invalid tag in your content. Why would you want to get rid of it?

Maybe I'm fussy but having pages of error text produced for every single pageload just doesn't sit well with me. There might be more serious errors that get drowned out by that.

MODX Staff
10,725 Posts

opengeek Reply #14, 13 years, 8 months ago

I guess I'm confused. That's why you would review the error log and fix the problematic tags in your content. Why are we looking for ways to work around legitimate errors being reported? Isn't that what is expected of error logging?

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

15 Posts

adi778 Reply #15, 13 years, 8 months ago

Quote from: opengeek at Jan 02, 2013, 10:59 AM

I guess I'm confused. That's why you would review the error log and fix the problematic tags in your content. Why are we looking for ways to work around legitimate errors being reported? Isn't that what is expected of error logging?

But I thought they're false positives?! Because getResources uses a different tag for links to the aggregated resources. And, although makeUrl accepts those tags to build a working url, it still produces the error message.

So now I'm confused.
Either [[+id]] is a valid way to build a link or it isn't. If it's valid, then it shouldn't produce any errors. If it's not valid, then we need another way to do it and all I've come up with is the makeshift workaround I described above.

MODX Staff
10,725 Posts

opengeek Reply #16, 13 years, 8 months ago

Quote from: adi778 at Jan 02, 2013, 03:21 PM

Quote from: opengeek at Jan 02, 2013, 10:59 AM
I guess I'm confused. That's why you would review the error log and fix the problematic tags in your content. Why are we looking for ways to work around legitimate errors being reported? Isn't that what is expected of error logging?

But I thought they're false positives?! Because getResources uses a different tag for links to the aggregated resources. And, although makeUrl accepts those tags to build a working url, it still produces the error message.

So now I'm confused.
Either [[+id]] is a valid way to build a link or it isn't. If it's valid, then it shouldn't produce any errors. If it's not valid, then we need another way to do it and all I've come up with is the makeshift workaround I described above.

No, it is not a false positive. Any link tag that does not have a valid integer ID (or some other valid value for makeUrl) will trigger this error. IOW,

[[+id]]

has to have a value in order for this to work. IOW, using this placeholder syntax has to be done in getResources or some other Extra that sets those placeholders when it iterates over a collection of Resources. It should not be used in the content of a Resource itself for rendering that Resource as a web page, unless you are setting that placeholder to a specific value.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

15 Posts

adi778 Reply #17, 13 years, 8 months ago

Quote from: opengeek at Jan 03, 2013, 07:57 AM

using this placeholder syntax has to be done in getResources or some other Extra that sets those placeholders when it iterates over a collection of Resources.

I thought that's what I did:
Specifically, when calling getResources, I reference the TPL chunk which contains [[+id]]. It wouldn't accept anything else as far as I know. Perhaps makeUrl is trying to handle the document before getResources has finished aggregating its contents but that's just a layman's guess.

Quote from: opengeek at Jan 03, 2013, 07:57 AM

It should not be used in the content of a Resource itself for rendering that Resource as a web page, unless you are setting that placeholder to a specific value.

I'm pretty sure that I haven't done that and, as far as I know, it wouldn't work at all on top of triggering an error.

I certainly appreciate you taking the time to discuss this.

13 Posts

the.kobold Reply #18, 13 years, 8 months ago

Hi, seems I have comparable problem;
in the beginning of my webresource's template I call [[!getEnv]] snippet to set some enviromental placeholders, like child IDs (by setPlaceholder).
If I use the placeholder alone (e.g. [[!+c1_id]], the 1st child ID ) in the page content, it shows the right value ( ID of child ), but when put this to link like [[~[[!+c1_id]]]] I get empty link with the discoussed error msg in log.
Is it possibile, the link rendering sooner than the placeholder gets its value?

For my special reason I need to put this placeholder to 'content', can't place it to template or chunk.
Sorry if sound noob question but I'm beginner on MODX, + my english just a gamer one

P.S. environment is modx-2.2.6-pl, and friendly URL

MODX Staff
10,725 Posts

opengeek Reply #19, 13 years, 8 months ago

Quote from: the.kobold at Jan 04, 2013, 09:18 AM

Hi, seems I have comparable problem;
in the beginning of my webresource's template I call [[!getEnv]] snippet to set some enviromental placeholders, like child IDs (by setPlaceholder).
If I use the placeholder alone (e.g. [[!+c1_id]], the 1st child ID ) in the page content, it shows the right value ( ID of child ), but when put this to link like [[~[[!+c1_id]]]] I get empty link with the discoussed error msg in log.
Is it possibile, the link rendering sooner than the placeholder gets its value?

Yes, that's exactly what is happening. Add ! to the link tag so it does not get processed until getEnv is processed and the placeholder (e.g. c1_id) it is setting is available...

[[!~[[!+c1_id]]]]

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

13 Posts

the.kobold Reply #20, 13 years, 8 months ago

Quote from: opengeek at Jan 05, 2013, 07:30 AM

Quote from: the.kobold at Jan 04, 2013, 09:18 AM
Hi, seems ...
Is it possibile, the link rendering sooner than the placeholder gets its value?

Yes, that's exactly what is happening. Add ! to the link tag so it does not get processed until getEnv is processed and the placeholder (e.g. c1_id) it is setting is available...
[[!~[[!+c1_id]]]]

Ohh, thank you very much