Install and Upgrade

Install and Upgrade 1.1.7 Patch Level 1

No permission to download
Hi all,

Is it just me getting the following in my error log twice a day, every day for at least the last few days (12:00 and 04:03)...

View attachment 278573

Happy to provide more info if needed... :)

Currently running 1.1.7 Patch Level 1

Cheers
Paul

@DragonByte Tech seems to have made a change at it's server, so all API connections for product update checks do get a 403 error since some time.

Seems @DragonByte Tech is no longer interested in using that feature.

To solve it, you have to uninstall the Dragonbyte connector, disabling it only does not help.
 
@DragonByte Tech seems to have made a change at it's server, so all API connections for product update checks do get a 403 error since some time.

Seems @DragonByte Tech is no longer interested in using that feature.

To solve it, you have to uninstall the Dragonbyte connector, disabling it only does not help.
This is not true, there are no API changes and the API endpoints do not trigger a 403. I've tested them all again just now and they all return data as expected.
 
i can understand him, becasue @ThemeHouse dont longer interessted in supporting this addon
I'm not sure where this idea has come from, the addon hasn't had updates as it hasn't needed any, not because we have no interest in maintaining it. The immediate bashing of ThemeHouse/Audentio every time an error pops up on an addon that hasn't been updated in a while is pretty tiresome.

Regarding this error, there is absolutely nothing we can do about it, with an update or in general. The issue is what it says in the message, the server failed to connect to a remote host as the connection timed out. We unfortunately cannot control cURL network request timeouts. The issue is either with the remote server, or something at network level with the hosting server - as @DragonByte Tech's server is apparently fully functioning, the issue is either with the OP's server, or is a temporary network issue. If it continues, it will need to be diagnosed with the hosting company running the server.
 
This is not true, there are no API changes and the API endpoints do not trigger a 403. I've tested them all again just now and they all return data as expected.

Regarding this error, there is absolutely nothing we can do about it, with an update or in general. The issue is what it says in the message, the server failed to connect to a remote host as the connection timed out. We unfortunately cannot control cURL network request timeouts. The issue is either with the remote server, or something at network level with the hosting server - as @DragonByte Tech's server is apparently fully functioning, the issue is either with the OP's server, or is a temporary network issue. If it continues, it will need to be diagnosed with the hosting company running the server.

We are using this add-on with several add-on provider profiles (including our own) and do not have any problems with any of them.

The only provider profile which generates errors in the errror log is @DragonByte Tech . It seems we are not the only one with problems.

We provided @DragonByte Tech with a detailled stack trace and are still getting errors. We have uninstalled the API profile for Dragonbyte add-ons for now and all works well.

@DragonByte Tech : If we can help in any way to get this solved, please let us know. From our point of view, the Install&Update add-on get's a 403 error when calling your server profile to get product updates or installable products. It started approx. 2 weeks ago.

@mattrogowski : Since we are our own hosting provider, we can say for sure that this is not a temporary problem and not a problem with our server or network (e.g. firewall).

Also, if you really still care about that add-on you could check the error routine in case of unreachability of a server to not block everything and just creating errors every time a cron job runs. There should be a much better problem handling.
 
Last edited:
@mattrogowski : Since we are our own hosting provider, we can say for sure that this is not a temporary problem and not a problem with our server or network (e.g. firewall).
A 403 error is different to the original error which was a network timeout issue. If a 403 is being returned then unless there's been a breaking change to the API that we don't know about, it would need to be triaged with @DragonByte Tech.
Also, if you really still care about that add-on you could check the error routine in case of unreachability of a server to not block everything and just creating errors every time a cron job runs. There should be a much better problem handling.
Well, no, not really. The whole point of an error being logged is to highlight something hasn't worked, if it logged errors less frequently than they're happening it would make it look like the issue is happening less frequently than it actually was so would make it harder to debug. Suppressing an error doesn't make it go away or fix what's actually wrong, and besides, the crons only run once every 24 hours anyway so it's hardly going to be spamming the error log. Nowhere in XF are errors throttled, they're logged as they happen, even if it's lots at a time, that's generally how error logs work. The solution is not to hide the error as if nothing is wrong, but to fix what's causing them, which in this case is triaging the issue with @DragonByte Tech as it's their service that's erroring. If there have been API breaking changes that need to be included in the handler in the addon, then those changes would be made.
 
Last edited:
We are using this add-on with several add-on provider profiles (including our own) and do not have any problems with any of them.

The only provider profile which generates errors in the errror log is @DragonByte Tech . It seems we are not the only one with problems.

We provided @DragonByte Tech with a detailled stack trace and are still getting errors. We have uninstalled the API profile for Dragonbyte add-ons for now and all works well.

@DragonByte Tech : If we can help in any way to get this solved, please let us know. From our point of view, the Install&Update add-on get's a 403 error when calling your server profile to get product updates or installable products. It started approx. 2 weeks ago.

@mattrogowski : Since we are our own hosting provider, we can say for sure that this is not a temporary problem and not a problem with our server or network (e.g. firewall).

Also, if you really still care about that add-on you could check the error routine in case of unreachability of a server to not block everything and just creating errors every time a cron job runs. There should be a much better problem handling.
If you can DM me with your server's public IP address, I'll have a look to see if it might be getting blocked by our firewall.

We recently "elevated" our server from CentOS 7.9 to AlmaLinux 8, and during that process, it seems to have reset all of our ModSecurity rule configs. It's possible that an overzealous ModSecurity rule blocked your server.
 
Hi @ThemeHouse i got some errors from your addon, maybe it belongs also to @mazzly update addon. Is there a way to fix this?

Code:
Server error log
ErrorException: [E_WARNING] Undefined array key "installed" src/addons/ThemeHouse/InstallAndUpgrade/XF/Admin/View/AddOn/Listing.php:46
Generated by: McAtze Jan 7, 2023 at 10:57

Stack trace
#0 src/addons/ThemeHouse/InstallAndUpgrade/XF/Admin/View/AddOn/Listing.php(46): XF::handlePhpError(2, '[E_WARNING] Und...', '/var/www/vhosts...', 46)
#1 src/XF/Mvc/Renderer/AbstractRenderer.php(91): ThemeHouse\InstallAndUpgrade\XF\Admin\View\AddOn\Listing->renderHtml()
#2 src/XF/Mvc/Renderer/Json.php(83): XF\Mvc\Renderer\AbstractRenderer->renderViewObject('XF:AddOn\\Listin...', 'admin:aun_confi...', Array, 'html')
#3 src/XF/Mvc/Renderer/Json.php(70): XF\Mvc\Renderer\Json->renderHtmlFallback('XF:AddOn\\Listin...', 'admin:aun_confi...', Array)
#4 src/XF/Mvc/Dispatcher.php(460): XF\Mvc\Renderer\Json->renderView('XF:AddOn\\Listin...', 'admin:aun_confi...', Array)
#5 src/XF/Mvc/Dispatcher.php(442): XF\Mvc\Dispatcher->renderView(Object(XF\Mvc\Renderer\Json), Object(XF\Mvc\Reply\View))
#6 src/XF/Mvc/Dispatcher.php(402): XF\Mvc\Dispatcher->renderReply(Object(XF\Mvc\Renderer\Json), Object(XF\Mvc\Reply\View))
#7 src/XF/Mvc/Dispatcher.php(60): XF\Mvc\Dispatcher->render(Object(XF\Mvc\Reply\View), 'json')
#8 src/XF/App.php(2483): XF\Mvc\Dispatcher->run()
#9 src/XF.php(524): XF\App->run()
#10 admin.php(13): XF::runApp('XF\\Admin\\App')
#11 {main}

Request state
array(4) {
  ["url"] => string(181) "/admin.php?add-ons/ITM-ComAge/toggle-version-ignore&_xfRequestUri=%2Fadmin.php%3Fadd-ons%2F&_xfWithData=1&_xfToken=1673085419%2Cd7edb2840bd80a0aab9553d07adc7593&_xfResponseType=json"
  ["referrer"] => string(47) "https://www.xxxxx.com/admin.php?add-ons/"
  ["_GET"] => array(5) {
    ["add-ons/ITM-ComAge/toggle-version-ignore"] => string(0) ""
    ["_xfRequestUri"] => string(19) "/admin.php?add-ons/"
    ["_xfWithData"] => string(1) "1"
    ["_xfToken"] => string(43) "1673085419,d7edb2840bd80a0aab9553d07adc7593"
    ["_xfResponseType"] => string(4) "json"
  }
  ["_POST"] => array(0) {
  }
}
 
Not sure why you'd be getting that... ThemeHouse/InstallAndUpgrade/XF/Admin/View/AddOn/Listing.php is a View class specific to the addon, but it's called from core code:

Code:
return $this->view('XF:AddOn\Listing', 'addon_list', $viewParams);

The installed key is defined in $viewParams by core XF and has been for like 7+ years.

I'm not sure what URL you're on either... this doesn't look familiar:

Code:
["url"] => string(181) "/admin.php?add-ons/ITM-ComAge/toggle-version-ignore

I'm guessing ITM-ComAge/toggle-version-ignore is an addon identifier but that URL structure doesn't seem to be part of core XF.

Do you have any other addons that adjust the addons list in any way?

Edit: Just looked into it and if the installed key wasn't defined, your addons list wouldn't show a list of installed addons at all. What I imagine is wrong is that another addon is outputting a view using the XF:AddOn\Listing View class, but it's being used in a new page that is passing different values, so it causes an error - it should be specifying a unique View class name instead.
 
Last edited:
So yeah, it's another addon - the Addon Update Notifier addon you mentioned does this:

Code:
return $this->view('XF:AddOn\Listing', 'aun_confirm_ignore'
Code:
return $this->view('XF:AddOn\Listing', 'aun_report_url'

This is wrong, as the XF:AddOn\Listing View class is defined by core XF for use on the addon listing page and passes specific values through. The other Addon Update Notifier addon doesn't pass these values through, so the View class then breaks. Addon Update Notifier needs to be updated to define a custom View class name when returning its views. Maybe MaZ\AUN:ConfirmIgnore and MaZ\AUN:ReportUrl or something.
 
When I try to use Upgrade from URL I get this:

Code:
PHPHtmlParser\Exceptions\CircularException: Can not set itself as a child. in src/addons/ThemeHouse/InstallAndUpgrade/vendor/thesoftwarefanatics/php-html-parser/src/PHPHtmlParser/Dom/InnerNode.php at line 118
PHPHtmlParser\Dom\InnerNode->addChild() in src/addons/ThemeHouse/InstallAndUpgrade/vendor/thesoftwarefanatics/php-html-parser/src/PHPHtmlParser/Dom.php at line 454
PHPHtmlParser\Dom->parse() in src/addons/ThemeHouse/InstallAndUpgrade/vendor/thesoftwarefanatics/php-html-parser/src/PHPHtmlParser/Dom.php at line 189
PHPHtmlParser\Dom->loadStr() in src/addons/ThemeHouse/InstallAndUpgrade/vendor/thesoftwarefanatics/php-html-parser/src/PHPHtmlParser/Dom.php at line 132
PHPHtmlParser\Dom->load() in src/addons/ThemeHouse/InstallAndUpgrade/InstallAndUpgrade/XF2RM.php at line 203
ThemeHouse\InstallAndUpgrade\InstallAndUpgrade\XF2RM->isValidXFRMUrl() in src/addons/ThemeHouse/InstallAndUpgrade/InstallAndUpgrade/XF2RM.php at line 178
ThemeHouse\InstallAndUpgrade\InstallAndUpgrade\XF2RM->isValidAddOnUrl() in src/addons/ThemeHouse/InstallAndUpgrade/XF/Admin/Controller/AddOn.php at line 212
ThemeHouse\InstallAndUpgrade\XF\Admin\Controller\AddOn->ThemeHouse\InstallAndUpgrade\XF\Admin\Controller\{closure}() in src/addons/ThemeHouse/InstallAndUpgrade/ControllerPlugin/Profile.php at line 65
ThemeHouse\InstallAndUpgrade\ControllerPlugin\Profile->handleReply() in src/addons/ThemeHouse/InstallAndUpgrade/XF/Admin/Controller/AddOn.php at line 232
ThemeHouse\InstallAndUpgrade\XF\Admin\Controller\AddOn->actionThInstallUpgradeUrl() in src/XF/Mvc/Dispatcher.php at line 352
XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 259
XF\Mvc\Dispatcher->dispatchFromMatch() in src/XF/Mvc/Dispatcher.php at line 115
XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 57
XF\Mvc\Dispatcher->run() in src/XF/App.php at line 2487
XF\App->run() in src/XF.php at line 524
XF::runApp() in admin.php at line 13
 
I can see the issue now (I actually get a different error but still).

The cause is a 3rd party composer package that hasn't been updated since December 2018 which is unfortunate. We'll need to update it to either use a fork of the library or use a new one, so I'll have to come back to this next week. For now you'll just need to download the zip and upload it.
 
I can see the issue now (I actually get a different error but still).

The cause is a 3rd party composer package that hasn't been updated since December 2018 which is unfortunate. We'll need to update it to either use a fork of the library or use a new one, so I'll have to come back to this next week. For now you'll just need to download the zip and upload it.
Not being a pest, but are you working on this update?
 
Top Bottom