IPB2 upgrades
Submitted
Jason H
, Sep 22 2011 01:10 PM | Last updated Sep 22 2011 01:10 PM
eh.. I forgot to think of this before.. If you upgrade from IPB2.. We've got it fixed now, apparently, so that it adds an upgrade_history entry up to IPB 3.1.4..
Problem is.. There's no core_applications entry.
That's something of a problem. No good way to handle it, either. If it's an upgrade from IPB2, we need to add it in.. BUT.. We can't if it's from 3.0.0 or higher.
Add the query in the 3.1.3 to 3.1.4 upgrade If it doesn't exist?
Problem is.. There's no core_applications entry.
That's something of a problem. No good way to handle it, either. If it's an upgrade from IPB2, we need to add it in.. BUT.. We can't if it's from 3.0.0 or higher.
Add the query in the 3.1.3 to 3.1.4 upgrade If it doesn't exist?
| Status: | Fixed |
| Version: | 3.2.1 |
| Fixed In: | 3.2.2 |
3 Comments
On the one hand, you're right - if core_applications entry isn't there you still can't upgrade it later, creating problems for those who accidentally forgot to upload calendar.
On the other hand, if you intentionally did not upload calendar because you don't wish to use it, automatically inserting a core_applications entry for it defeats the point.
Additionally, you can't use the application and it might be confusing for a user to see the application there in the ACP, but it is not functional and if enabled will cause errors.
I decided to go ahead and insert the core_applications entry, with the app disabled, as this will likely create less problems for techs and users who forgot that calendar is separated. For those intentionally not updating it, they can still delete the application from the ACP. We will have to evaluate if this has any negative impact/confusion/etc.
Removal is another story, but.. That should be rather few and far between.