Anyone encountered the same issue? This happen once in a while, it seems failed to render using the page.tpl.php and show the login blocks which is supposed to be hidden. After clearing the cache, problem's gone. No changes done on the template, no node updates, no script updates. Nothing logged in Apache error logs and drupal watchdog.
# Hendry
Hendry wrote:
Anyone encountered the same issue? This happen once in a while, it seems failed to render using the page.tpl.php and show the login blocks which is supposed to be hidden. After clearing the cache, problem's gone. No changes done on the template, no node updates, no script updates. Nothing logged in Apache error logs and drupal watchdog.
Sounds like you made changes and the old versions of the pages were still in cache. It is par and somewhat expected. Do you have any other cache engine besides the one Drupal has running? Something as part of PHP or Apache? Just curious really. You exercised the correct fix by clearing the cache. But if you are experiencing the problem without changing anything or the problem returns then perhaps you have a different issue.
On Fri, May 7, 2010 at 7:32 PM, Earnie Boyd earnie@users.sourceforge.net wrote:
Sounds like you made changes and the old versions of the pages were still in cache. It is par and somewhat expected. Do you have any other cache engine besides the one Drupal has running? Something as part of PHP or Apache? Just curious really. You exercised the correct fix by clearing the cache. But if you are experiencing the problem without changing anything or the problem returns then perhaps you have a different issue.
Nothing has changed, it was just suddenly failed to render the page correctly and cached, if I'm logged in I didn't encounter this issue. I tried to reproduce by removing the theme .info file and it gives me the same output. I believe at that time nothing has been changed. And yes, this has happened twice.
# Hendry
Hendry wrote:
On Fri, May 7, 2010 at 7:32 PM, Earnie Boyd earnie@users.sourceforge.net wrote:
Sounds like you made changes and the old versions of the pages were still in cache. It is par and somewhat expected. Do you have any other cache engine besides the one Drupal has running? Something as part of PHP or Apache? Just curious really. You exercised the correct fix by clearing the cache. But if you are experiencing the problem without changing anything or the problem returns then perhaps you have a different issue.
Nothing has changed, it was just suddenly failed to render the page correctly and cached, if I'm logged in I didn't encounter this issue. I tried to reproduce by removing the theme .info file and it gives me the same output. I believe at that time nothing has been changed. And yes, this has happened twice.
You wouldn't see it for authenticated but do see it for anonymous because the page caches are only used for anonymous. Are you using Views module?
On Sat, May 8, 2010 at 8:54 PM, Earnie Boyd earnie@users.sourceforge.net wrote:
You wouldn't see it for authenticated but do see it for anonymous because the page caches are only used for anonymous. Are you using Views module?
I do understand cache only for anonymous, what I was trying to say that, it happened occasionally, well just twice until now, and no changes has been done to the contents and files. I do have Views module enabled.
# Hendry
Hendry wrote:
On Sat, May 8, 2010 at 8:54 PM, Earnie Boyd earnie@users.sourceforge.net wrote:
You wouldn't see it for authenticated but do see it for anonymous because the page caches are only used for anonymous. Are you using Views module?
I do understand cache only for anonymous, what I was trying to say that, it happened occasionally, well just twice until now, and no changes has been done to the contents and files. I do have Views module enabled.
Your issue is the second occurrence on the lists I've seen where Views has been enabled and the cached page data is being served longer that it should be. The first was phrased as a question about how long the cache is maintained. In realty the Drupal page cache is short lived. I'm not familiar with the Views code to know why it makes a difference.
On Sun, May 9, 2010 at 1:45 AM, Earnie Boyd earnie@users.sourceforge.net wrote:
Your issue is the second occurrence on the lists I've seen where Views has been enabled and the cached page data is being served longer that it should be. The first was phrased as a question about how long the cache is maintained. In realty the Drupal page cache is short lived. I'm not familiar with the Views code to know why it makes a difference.
Lifetime of the cached page is 3 hours, and when the issue arise, that page was just being cached. And when we go that particular page as authenticated user, the page was properly rendered.
You mean, there could be possibility Views module causing the problem? Is there any method or logging that can be enabled, without adding heavy load on server performance, for future investigations if the case happened again? I've trouble to reproduce this problem, and I can't just say that the Views module is being the suspect. Last time, Apache error logs and watchdog did not print out any error related to the issue.
# Hendry
Hendry wrote:
On Sun, May 9, 2010 at 1:45 AM, Earnie Boyd earnie@users.sourceforge.net wrote:
Your issue is the second occurrence on the lists I've seen where Views has been enabled and the cached page data is being served longer that it should be. The first was phrased as a question about how long the cache is maintained. In realty the Drupal page cache is short lived. I'm not familiar with the Views code to know why it makes a difference.
Lifetime of the cached page is 3 hours, and when the issue arise, that page was just being cached. And when we go that particular page as authenticated user, the page was properly rendered.
You mean, there could be possibility Views module causing the problem?
I have no way to know. I just made an observation that two incidents involving page cache where Views was being used.
Is there any method or logging that can be enabled, without adding heavy load on server performance, for future investigations if the case happened again? I've trouble to reproduce this problem, and I can't just say that the Views module is being the suspect. Last time, Apache error logs and watchdog did not print out any error related to the issue.
I would suggest that on the next occurrence that you dump your database and import it to a development machine. Then you can use the devel module to help debug the issue. You'll want to have the devel module already installed so that the page cache isn't emptied by default. Do not import the sessions table nor the system table, have them already setup and waiting. Mirror as much of production setup as you can including the web server URL by using the /etc/hosts of your development machine.
On Mon, May 10, 2010 at 3:26 AM, Earnie Boyd earnie@users.sourceforge.net wrote:
I would suggest that on the next occurrence that you dump your database and import it to a development machine. Then you can use the devel module to help debug the issue. You'll want to have the devel module already installed so that the page cache isn't emptied by default. Do not import the sessions table nor the system table, have them already setup and waiting. Mirror as much of production setup as you can including the web server URL by using the /etc/hosts of your development machine.
Thanks Earnie, will look into this, SOL
# Hendry
-
Earnie Boyd -
Hendry