Project

General

Profile

Actions

Bug #15009

closed

System>Update page menu uses incorrect internal URL

Added by Jon8RFC . 5 months ago. Updated 5 months ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
PHP Interpreter
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

v2.7.0

Going to System>Update leads to here:
http://192.168.168.1/pkg_mgr_install.php?id=firmware

Changing the submenu selected item from the default to the other menu item
(currently, "previous stable release (2.7.0)" and "latest stable release (2.7.1)")
lands on this URL:
http://192.168.168.1/pkg_mgr_install.php

Which then shows:

Unable to check for updates

In the "Retrieving" section.

Selecting the other menu item results in the same error.

Manually adding:

?id=firmware

To the URL permits either selected menu item to refresh properly.

Actions #1

Updated by Jim Pingle 5 months ago

  • Status changed from New to Not a Bug

When you change branches it does a POST and the parameter is set in the POST request so it is not visible in the URL in the browser, but if you watch the request in your browser's network debug panel you can see it's sending the correct values.

You altering the URL essentially just reloaded the page, which is often a requirement after changing the branch if the background tasks for fetching the metadata take longer than expected.

In other words, there is no bug here, you just took a roundabout method of refreshing the page after changing branches.

Actions #2

Updated by Jon8RFC . 5 months ago

Hmm. But refresh, ctrl+refresh, shift+refresh, ctrl+shift+refresh all yield the same result for me: Unable to check for updates

Here's a video, and you can see that using ?id=firmware ends up with a faster result of success, as does manually leaving the page and going back which has ?id=firmware appended:
https://youtu.be/w-BCqqK0BG0

I would think that's indicative of some type of user/connection-induced timeout issue not being at play, if the success is noticeably faster than the failure and successes only occur when the ?id=firmware is appended in this case.

The failures are reproducible in succession of refreshes, multiple times, so whatever would seem to be loading isn't actually loading, and leaving the page and going back will insert ?id=firmware into the URL, which then succeeds at the same approximate speed as when I manually input it. Refreshes fail, and the ?id=firmware is not in the URL.

Since this is an unusual issue, and I'm a magnet for random edge-case scenarios, I'll mention the seemingly-irrelevant situation that this was an original install of 2.6.0, using a backup from an old installation of 2.6.0 which was originally upgraded over time with each version between 2.3.x somewhere, through 2.6.0. This 2.6.0 system was then upgraded to 2.7.0.

Another system with an original installation of 2.7.0 doesn't have this issue, yet the URL doesn't show ?id=firmware when changing branches. Its success is at the same approximate speed as my success when manually using ?id=firmware, and both systems use a similar setup and use the same DNS servers in the same order. I'm using the same browsers for both systems when testing.

Odd, indeed. Would comparing the php pages and php configs be of use just to see what may possibly be different, to rule that out?

Actions #3

Updated by Jon8RFC . 5 months ago

Interestingly, a reboot resolved the issue. No changes made.

Actions

Also available in: Atom PDF