If i press save configuration on "admin/reports/updates/settings" the table with ignore settings get's hidden after a save. Clicking on the tab "admin/reports/updates/settings" for reloading, doesn't bring this ignore table back. Click on "admin/reports/updates" tab and again on "admin/reports/updates/settings" tab brings the table back...

CommentFileSizeAuthor
#15 237347-15.update_advanced_settings_table_cache.d6.patch919 bytesdww
#15 237347-15.update_status_settings_table_cache.d5.patch1.19 KBdww
#12 D6_update_advanced_table_not_shown_after_submit.patch771 byteshass
#2 Update_237347_1.png69.72 KBhass
#2 Update_237347_afterSave.png33.33 KBhass

Comments

dww’s picture

dww
we/he/they
commented
Category: bug » support
Status: Active » Postponed (maintainer needs more info)

As expected, I can't reproduce this at all with garland, a clean core install, and the latest update_advanced. Probably something is broken in your theme. You get to either a) figure out and solve your own problem, or b) provide enough information for someone else to reliably reproduce this.

hass’s picture

hass commented
Category: support » bug
Status: Postponed (maintainer needs more info) » Active
StatusFileSize
new Update_237347_afterSave.png33.33 KB
new Update_237347_1.png69.72 KB

I'm not aware of any problems on my box. I'm using PHP 5.2.4 on a local Windows, there are no known PHP limitations. See the attached screenshots with Garland. I don't know what the module does here and how this could ever happen.

dww’s picture

dww
we/he/they
commented
Category: bug » support
Status: Active » Postponed (maintainer needs more info)

Try clearing *all* of your caches, including the theme registry and menu caches. It looks like somehow after you save, update_advanced's theme override is no longer happening on that settings form.

Also, until you can prove it's a bug, please stop setting it back to that status.

hass’s picture

hass commented

I pressed "clear all caches" at admin/settings/performance. No change.

dww’s picture

dww
we/he/they
commented

That doesn't clear your theme registry cache. Use devel.module, or do it manually.

hass’s picture

hass commented

This should be save, but haven't helped, too.

TRUNCATE TABLE `cache`;
TRUNCATE TABLE `cache_block`;
TRUNCATE TABLE `cache_filter`;
TRUNCATE TABLE `cache_form`;
TRUNCATE TABLE `cache_menu`;
TRUNCATE TABLE `cache_page`;
TRUNCATE TABLE `cache_update`;
dww’s picture

dww
we/he/they
commented

Try with Garland. Try with a clean install with nothing but core and update_advanced. You've been around long enough to know basic trouble-shooting and debugging techniques. This doesn't happen with a clean core installation, so I'm not sure why I'm still spending time on this.

hass’s picture

hass commented

I'm little bit lost here... I've tested an upgrade from my D5 installation and now this is not working. I copied the module in a new test install an well - it works. But how could this ever possible that a theme hook is not executed!? I must solve this issue or i cannot upgrade. I hope you might have an good idea how to analyze and solve this issue. I have no idea why a core hook should not fire if this is not a bug in core...

EDIT: "clear all caches" at admin/settings/performance looks clearing the theme registry!

hass’s picture

hass commented
Category: bug » feature

After i changed this line to TRUE it works for me... i tried to follow this functions to figure out what could be wrong, but i have troubles to follow the idea and logic. Moving back to bug, as it looks like a bug and IF's without ELSE are every time a bad thing.

[update_advanced.settings.inc]

if ($available = update_get_available(FALSE)) {
hass’s picture

hass commented
Category: support » bug

This is from update_status module update_status_settings(). Looks the same like my "solution", however i don't know what this does.

if ($available = update_status_get_available(TRUE)) {
hass’s picture

hass commented
Category: feature » bug
Status: Postponed (maintainer needs more info) » Active
hass’s picture

hass commented
Status: Active » Needs review
StatusFileSize
new D6_update_advanced_table_not_shown_after_submit.patch771 bytes

Patch attached.

dww’s picture

dww
we/he/they
commented
Category: bug » support
Status: Needs review » Closed (won't fix)

That's not a good change. We don't want to re-fetch and recompute available update data for the settings page, we just want to get it out of the cache. I bet this was yet-another symptom of #220592: Core cache API breaks update.module: fetches data way too often, kills site performance, etc (now fixed).

dww’s picture

dww
we/he/they
commented
Category: support » bug
Status: Closed (won't fix) » Needs review

Ahh, nope. ;) I've now been able to reproduce this bug over at #162788: Include modules that aren't enabled. The problem is that if there's no cached available update data when the settings page form builder runs, it can't generate this table. So, now that I think about it, patch #12 might actually be in the right direction... So long as that doesn't clear the cache, it should work ok...

dww’s picture

dww
we/he/they
commented
StatusFileSize
new 237347-15.update_status_settings_table_cache.d5.patch1.19 KB
new 237347-15.update_advanced_settings_table_cache.d6.patch919 bytes

Nope, #12 is definitely wrong, since it forces a refresh of all available update data every time you visit the settings page. This is what we need, instead.

dww’s picture

dww
we/he/they
commented
Status: Needs review » Fixed

gah, I think I've been hacking too long today... my brain is shot. ;) #15 is definitely wrong. Now that I actually read update_get_available() carefully, I see that passing in $refresh as TRUE will only fetch data if there isn't any data in the cache, which is in fact what we want. ;) Committed #12 to HEAD after more careful testing and review of related code.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.