I've not seen anything like that when it comes to changing page types. I guess if your page type has its own controller, then there might be something happening before the page is rendered which is no longer quite right, maybe a missing page attribute or something.

If you have cleared and disabled all caches settings, I'd make that a priority, as well as turning on debug settings in the dashboard to expose any errors that may be creeping in but you're not seeing.

If you view the source of the blank page, is there actually anything there?

Debug is on, the source is completely blank.

OK This is weird. I swear I turned all the cache off. However, now not only is some of the cache settings on, but I can;t turn them off! I set to off and hit save, and the following stay set to "On".

Block Cache, Theme CSS Cache. Compress LESS Output, and Overrides Cache.
???

What about server error logs? If nothing then maybe you've got a suppressed error somewhere. I had something similar just yesterday when a luser uploaded a huge jpg image and the code that generates thumbnails ran out of memory and crashed PHP - no warning, no error, just stopped halfway through a page.

If you know what template the page is using, try renaming it out of the way or substitute a page *template* that does very little - no areas or anything.

You could also try assigning a null page *type* and see if that helps. Using null should I guess ensure that any page type controller logic isn't run.

Thanks for trying to help.

The server logs don't have any errors other than a few
File does not exist: ..../404.shtml
File does not exist: ..../favicon.ico

Why would the Cache setting be stuck on "On"?
Don't you think that that is a good clue? As you said, maybe the cache being on is part of the problem, but why can;t I turn it off?

hi,
when you change your cache settings they are written to:

/application/config/generated_overrides/concrete.php

if you change the settings you should see them change in that file in the cache node:

'cache' => array(
'blocks' => false,
'assets' => false,
'theme_css' => false,
'overrides' => false,
'pages' => '0',
'full_page_lifetime' => 'default',
'full_page_lifetime_value' => null,
),

However, I'd expect if this file weren't writeable that you'd see some error messages.
Does the file change when you make the changes?

The debug settings are also held in this file if changed:

'debug' => array(
'detail' => 'debug',
'display_errors' => true,
),

@jero
OK, I tried your Null Page Type suggestion, and that did it! I have these Pages again.
So I tried switching the page type back, and the pages work fine now.

An important question... what caused this?

And I still have the cache settings issue...

@AndyJ
I already checked file permissions in those folders and everything is normal. I'll take a peak at the content of that file though

My guess is that as @AndyJ says, your cache settings may not be sticking possibly because your application/config folder isn't writeable. Rule #1 for Concrete5 is to turn off and clear all cache settings if anything weird happens.

So the permissions are set correctly (644) and I even tried giving 666 permissions (and back again too). No luck. They just keep reverting back to On (matching what's in the array

'cache' => array(
'blocks' => false,
'assets' => false,
'theme_css' => true,
'overrides' => true,
'pages' => '0',
'full_page_lifetime' => 'default',
'full_page_lifetime_value' => null,

644 is good, provided that the 6 relates to the user ID of your webserver/PHP process. 666 ought to work though. Also check that the application/config/generated_overrides folder is 755 - again the 7 should relate to the webserver/PHP user ID, i.e. the directory's owner should be the same as the webserver/php

Maybe you have a disk quota issue? That might prevent the file being updated if you're completely full.

I created a new Post/Topic just for this cache issue here
http://www.concrete5.org/index.php?cID=781867...