Then I’m stumped. One last thing to try is upping the PHP memory limit and max_execution_time and retest. I think the core problem is it’s timing out when doing batches of data.
Cheers.
Need to upgrade from 1.12 to 1.17
Neither memory limit nor max_execution_time are editable on my host (SiteGround).
- Edited
Tech support said they'd jack up the memory limit and execution time for me, so I'll try again, but now I'm concerned that I could get to the end of that process and still be faced with the "no input file specified" error that I'm seeing now on a clean install. I've double-checked the azure information twice, so I'm sure it comes down to the .htaccess file in the api folder, or possibly in other folders.
OK, max_execution_time is changed from 120 to 360 and PHP memory limit has been changed from 768M to 2048M.
I'm going to re-stage the database and files and try again.
100% if you get no input file specified then URL Rewriting is not working properly (either not enabled or not allowed in the main site config). It has nothing to do with the api/.htaccess file as many, many people use this with no issues. Unless you have some wacky api/.htaccess file that wasn’t shipped with the codebase.
Cheers.
- Edited
I'm beginning to think that 1.17.2 is simply incompatible with SiteGround webhost, and I may need to talk to the customer about migrating to some other product, after having used this for at least 15 years.
- Edited
I sent your reply to SiteGround tech support, and they replied with this:
Thank you for this update. I compared your .htaccess file located in the api folder with the one from the official OsTicket Git repository and I could not find any difference:
https://raw.githubusercontent.com/osTicket/osTicket/develop/api/.htaccess
It seems there is an issue with the .htaccess rules interpretation, because the http.php script is present. This is why I changed the PHP environment to our UltraFast PHP setup. Now the URL you posted in your initial post just redirects to the home page. Is it possible to provide with a username and password for your OsTicket application, so we can investigate this case further?
And, for the first time, I did not get "no input file", so it seems the problem is related to UltraFast PHP.
It should work just fine in siteground as long as it meets the pre-reqs.
We do provide support to help upgrade, etc. You can contact us from our website for more info.
Otherwise, you do what you gotta do.
Cheers.
Also, please post a screenshot of your OAuth2 config. (Censor any sensitive info)
Cheers.
Hi Kevin, I'm pretty sure the problem/answer on SiteGround is the UltraFast PHP option, which, when enabled, does allow the OAuth link to complete, and then the mailbox configuration is successful.
The problem, I've discovered, is that the v1.12 site doesn't work with that option turned on, and I still need to run it to copy information and settings out of it, so I need to find a way to disable that option for the /old folder where I've got the old install.
I did fill out the form on the website and mentioned that I would be willing to consider engaging paid support, but I don't think I got a response to that.
We weighed pros and cons with the customer, and we all agree that their investment with OST is a good one, and we really want to get this going again.
... so I need to find a way to disable that option for the /old folder where I've got the old install.
You'll have to contact your hosting provider for this part as this is outside the scope of the software.
... but I don't think I got a response to that.
You should eventually receive a response once the team gets to your ticket. We've had a huge influx of tickets recently since MS disabled basic auth (as you can imagine 
)
Cheers.
5 days later
I have a very similar issue and I tried the upgrade 3 times.
Twice from 15.2 and then I upgraded step by step to 16.5
But 17.2 fails every time with the same messages:
[core]: Upgrader Error
[CREATE TABLE `plugin_instance` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `plugin_id` int(11) unsigned NOT NULL, `flags` int(10) NOT NULL DEFAULT 0, `name` varchar(128) NOT NULL DEFAULT '', `config` text DEFAULT NULL, `notes` text DEFAULT NULL, `created` datetime NOT NULL, `updated` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `plugin_id` (`plugin_id`) ) DEFAULT CHARSET=utf8] Table 'plugin_instance' already exists
Log Date: Wed, 1. Feb 2023 21:34 IP Address:DB Error #1054
[SELECT A1.* FROM `email_account` A1 WHERE A1.`type` = 'smtp' AND A1.`type` = 'smtp' AND A1.`email_id` = 5] Unknown column 'A1.type' in 'where clause'<br /> <br /> ---- Backtrace ----<br /> #0 (root)/include/mysqli.php(207): osTicket->logDBError('DB Error #1054', '[SELECT A1.* FR...')<br /> #1 (root)/include/class.orm.php(3482): db_query('SELECT A1.* FRO...', true, true)<br /> #2 (root)/include/class.orm.php(3529): MySqlExecutor->execute()<br /> #3 (root)/include/class.orm.php(2010): MySqlExecutor->getArray()<br /> #4 (root)/include/class.orm.php(2054): ModelInstanceManager->{closure}()<br /> #5 (root)/include/class.orm.php(2033): CallbackSimpleIterator->next()<br /> #6 (root)/include/class.orm.php(2042): CallbackSimpleIterator->rewind()<br /> #7 (root)/include/class.orm.php(1713): CallbackSimpleIterator->valid()<br /> #8 (root)/include/class.orm.php(1723): CachedResultSet->fillTo(9223372036854775807)<br /> #9 (root)/include/class.orm.php(1337): CachedResultSet->asArray()<br /> #10 (root)/include/class.orm.php(1360): QuerySet->all()<br /> #11 (root)/include/class.orm.php(606): QuerySet->one()<br /> #12 (root)/include/class.orm.php(381): VerySimpleModel::lookup(Array)<br /> #13 (root)/include/class.orm.php(417): VerySimpleModel->get('smtp', NULL)<br /> #14 (root)/include/class.email.php(210): VerySimpleModel->__get('smtp')<br /> #15 (root)/include/class.mailer.php(35): Email->getSmtpAccount(false)<br /> #16 (root)/include/class.email.php(231): osTicket\Mail\Mailer->__construct(Object(Email))<br /> #17 (root)/include/class.email.php(245): Email->send('patrick.dimarti...', '[core]: Upgrade...', '[CREATE TABLE `...', NULL, Array)<br /> #18 (root)/include/class.upgrader.php(204): Email->sendAlert('patrick.dimarti...', '[core]: Upgrade...', '[CREATE TABLE `...')<br /> #19 (root)/include/class.setup.php(115): StreamUpgrader->onError('[CREATE TABLE `...')<br /> #20 (root)/include/class.setup.php(69): SetupWizard->abort('[CREATE TABLE `...', false)<br /> #21 (root)/include/class.setup.php(44): SetupWizard->load_sql('/**\n * @version...', '', true, false)<br /> #22 (root)/include/class.upgrader.php(379): SetupWizard->load_sql_file('/home/latincon/...', '')<br /> #23 (root)/include/class.upgrader.php(112): StreamUpgrader->upgrade()<br /> #24 (root)/include/ajax.upgrader.php(42): Upgrader->upgrade()<br /> #25 (root)/include/class.dispatcher.php(153): UpgraderAjaxAPI->upgrade()<br /> #26 (root)/include/class.dispatcher.php(40): UrlMatcher->dispatch('/upgrader', NULL)<br /> #27 (root)/scp/ajax.php(326): Dispatcher->resolve('/upgrader')<br /> #28 {main}
Log Date: Wed, 1. Feb 2023 21:34 IP Address: I am on a dedicated server and this looks more like a database issue to me than a php settings one.
I will just go back and stay at 16.5, but it may help to solve the puzzle.