[Solved] Login Cache issue

☆ A M B ☆
3,141 Posts

Mark Hamstra Reply #1, 16 years, 4 months ago

Fatal error: Call to a member function isAuthenticated() on a non-object in /usr/home/sigs4u/domains/signatures4u.net/public_html/core/cache/elements/modsnippet/6.include.cache.php on line 66

The specific line in the cache is:

$authenticated = $modx->user->isAuthenticated($modx->context->get('key'));

Which is the same as one of the first lines of code in the Login snippet (with ID 6):

$authenticated = $modx->user->isAuthenticated($modx->context->get('key'));

The code in the template with the call is:

			<div id="sidebar">
				[[!Login]]
			</div>

so it shouldn’t be caching it.. right?

When I change the call to [[Login]] the page does load and the form shows.. however, that way the snippet will be cached... wont that cause problems with users loggin in/out?
Edit: just tested - it does.

Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.

☆ A M B ☆
3,141 Posts

Mark Hamstra Reply #2, 16 years, 4 months ago

Duplicated the snippet... changed nothing... works like a charm.....

Odd?

Edit:
Never mind. Now this one broke also.

Any ideas why it is caching while I’m calling uncached? [[!Login]]

Another edit:
It’s only happening on the document I am trying to make member-only..... It uses the same template as all the other pages (which includes a [[!Login]] call). The only thing setting it apart is me trying to protect the page......

Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.

MODX Staff
10,725 Posts

opengeek Reply #3, 16 years, 3 months ago

Quote from: Mark at Jun 20, 2010, 12:53 PM

Any ideas why it is caching while I’m calling uncached? [[!Login]]

Are there tags in your tpl’s that might need to be uncached as well?

Quote from: Mark at Jun 20, 2010, 12:53 PM

Another edit:
It’s only happening on the document I am trying to make member-only..... It uses the same template as all the other pages (which includes a [[!Login]] call). The only thing setting it apart is me trying to protect the page......

Not sure I fully understand; did you make sure and clear the cache and flush sessions after adding/changing/removing any ACL entries to "protect" the page?

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

☆ A M B ☆
3,141 Posts

Mark Hamstra Reply #4, 16 years, 3 months ago

Quote from: OpenGeek at Jun 21, 2010, 12:10 PM

Quote from: Mark at Jun 20, 2010, 12:53 PM

Any ideas why it is caching while I’m calling uncached? [[!Login]]

Are there tags in your tpl’s that might need to be uncached as well?

On the whole website, there’s one call in the template (only have one at this stage) which is uncached, and there is one call on the "Login" page, which is also uncached. There’s no chunks with the login form or anything - honestly only that one (and I just checked all the resources and elements for them).

Quote from: OpenGeek at Jun 21, 2010, 12:10 PM

Quote from: Mark at Jun 20, 2010, 12:53 PM

Another edit:
It’s only happening on the document I am trying to make member-only..... It uses the same template as all the other pages (which includes a [[!Login]] call). The only thing setting it apart is me trying to protect the page......

Not sure I fully understand; did you make sure and clear the cache and flush sessions after adding/changing/removing any ACL entries to "protect" the page?

- Just cleared the site cache, flushed all permissions -> page still returns the cache error (immediatly, so not even after a first refresh).
^ that made me think it wasn’t uncached to begin with. Looking at what the console actually did, it is uncaching things like lexicons, context caches and mgr cache. It didn’t say it uncached the modSnippet elements... which, by looking at the ftp, it didn’t.

Although simply deleting the files wont work, that’s giving me an error within FileZilla

Commando: DELE 15.include.cache.php
Antwoord: 550 15.include.cache.php: Operation not permitted

Using the file manager within the manager, I am able of deleting the files, but trying to refresh then simply makes the file again and still gives the error.

Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.

☆ A M B ☆
3,141 Posts

Mark Hamstra Reply #5, 16 years, 3 months ago

On the specific page, there is also a custom snippet I made.

As that does nothing with authentification or w/e, I assumed it had nothing to do with it.

When I removed the snippet call, suddenly the problem disappeared (for now).

Thanks for your patience and your help Jason, sorry for my ignorance lipsrsealed

When making the snippet earlier, I wanted to access the $modx object, so I had added this (but then uncommented):

	//require_once 'config.core.php';
	//require_once MODX_CORE_PATH.'config/'.MODX_CONFIG_KEY.'.inc.php';
	//require_once MODX_CORE_PATH.'model/modx/modx.class.php';
	//$modx = new modX();
	//$modx->initialize('mgr');

Now that I know the problem came from this, I can imagine the login snippet used the $modx in the above snippet instead of the main one, and the problem came from that.

*hides in shame*

Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.

MODX Staff
10,725 Posts

opengeek Reply #6, 16 years, 3 months ago

Quote from: Mark at Jun 21, 2010, 02:30 PM

When making the snippet earlier, I wanted to access the $modx object, so I had added this (but then uncommented):
	//require_once 'config.core.php';
	//require_once MODX_CORE_PATH.'config/'.MODX_CONFIG_KEY.'.inc.php';
	//require_once MODX_CORE_PATH.'model/modx/modx.class.php';
	//$modx = new modX();
	//$modx->initialize('mgr');
Now that I know the problem came from this, I can imagine the login snippet used the $modx in the above snippet instead of the main one, and the problem came from that.

*hides in shame*

We forgive you, this time. laugh

But seriously, no shame necessary. Thanks for taking the time to explore Revolution and collaborate.

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