Jump to content
Esther E.
 Share


IC5: Updating your Applications

As we get closer to our first release, we'll be discussing how to update your custom applications to be compatible with IPS v5. We know this can seem like a daunting task, especially since not all changes will be immediately obvious, so we'll be walking through this step by step.

 

Updating Source Classes

  • Classnames should no longer start with an underscore.
  • All our source classes are now strictly typed, so any of your classes that extend pretty much anything (Content Items, Nodes, Active Record) will need to be updated with the correct method signatures and property types.
  • Almost all Content interfaces have been converted to traits (e.g. \IPS\Content\Pinnable, \IPS\Content\Lockable). Your content classes should have use statements instead of implements, and if you are overloading any trait methods, verify that it is properly declared.
    The following interfaces have not been moved to traits:
    \IPS\Content\Embeddable
    \IPS\Content\Filter
    \IPS\Node\Permissions
  • \IPS\Content\Searchable has been removed entirely and replaced with a SearchContent extension.
  • Recommended: We no longer use FQN in our code. This is not required for v5 compatibility, but a recommendation for best practice.

Could contain: Page, Text, File

Could contain: Text, Page, Chart, Plot

A few examples of the changes to the code base, showing strictly typed function signatures and using traits versus interfaces

Updating Extensions

  • All extensions now have an abstract class that should be extended. Most of these can be found under \IPS\Extensions. The abstract class is typically the same name as the extension type (e.g. EditorLocations extend EditorLocationsAbstract). Verify that your extensions use the correct abstract class and that all your method signatures and properties are declared correctly.
  • Remove deprecated extensions. See this blog entry for a complete list.
  • Convert your CreateMenu extensions to a UserMenu extension.
  • Convert your MemberSync extensions to a Listener.

 

Replacing Code Hooks

The following is a general list of the most common types of code hooks. Obviously, we cannot predict, nor support, all possibilities, but we have tried to cover the basics here.

  • Hooks on content classes should be replaced with Listeners or UI Extensions.
  • Hooks on the Dispatcher (e.g. for loading JS/CSS) should be converted to Loader Extensions.
  • Hooks on commerce items should be replaced with Listeners.
  • Hooks that add functionality (e.g. Commerce gateways, Login handlers) should be moved to the appropriate extensions.

 

Replacing Theme Hooks

As with code hooks, below is a list of common uses for theme hooks.

  • Theme hooks that add to the user dropdown menu should be moved to a UserMenu extension.
  • Theme hooks that add classes or attributes should be moved to UI Extensions.
  • Theme hooks that insert HTML should be moved to template hooks.

 

Please let us know in the comments if there is anything that we may have missed, or if something is unclear. We would like to make this transition as smooth as possible.

Comments

Recommended Comments

Hi,

Thanks for that...

What is the actual sequence for converting a V4 application to V5? Take the following as an outline...

  1. Starting with my V4 development system with IN_DEV
  2. Disable IN_DEV (as I cannot upgrade with it set)
  3. Install V5 (IPS database is converted, etc...)
  4. Presumably my application is disabled by the upgrade as it is not compatible?
  5. Enable IN_DEV
  6. What do I have to do so that I can re-enable the application and start testing file by file? I don't believe that updating all files before I can test anything is practical. In many cases I'll have to play around and test various alternatives before I find something that might work under V5.
  7. What happens to all the hooks? Do they just get deleted by the upgrade to V5? (Obviously, I could retrieve them from my other V4 development system and use them as the basis for working out what to do under V5.)
  8. What happens to the MemberSync extension(s)? Do they just get deleted by the upgrade - so I just retrieve the code from my other V4 development system and insert it into a Listener?
  9. Are all me database tables preserved by the upgrade?

Similarly, what happens to a customer/live system that runs my application and upgrades from V4 to V5?

  1. Starting with live system running my application on V4
  2. IPS is upgraded from V4 to V5.
  3. Presumably my application is disabled by the upgrade as it is not compatible?
  4. 'Customer' installs the V5 compatible version of my application -- is all now OK with no loss of data?

Thanks very much.

John

Link to comment
Share on other sites

On 12/14/2023 at 7:03 AM, BN_IT_Support said:

Hi,

Thanks for that...

What is the actual sequence for converting a V4 application to V5? Take the following as an outline...

  1. Starting with my V4 development system with IN_DEV
  2. Disable IN_DEV (as I cannot upgrade with it set)
  3. Install V5 (IPS database is converted, etc...)
  4. Presumably my application is disabled by the upgrade as it is not compatible?
  5. Enable IN_DEV
  6. What do I have to do so that I can re-enable the application and start testing file by file? I don't believe that updating all files before I can test anything is practical. In many cases I'll have to play around and test various alternatives before I find something that might work under V5.
  7. What happens to all the hooks? Do they just get deleted by the upgrade to V5? (Obviously, I could retrieve them from my other V4 development system and use them as the basis for working out what to do under V5.)
  8. What happens to the MemberSync extension(s)? Do they just get deleted by the upgrade - so I just retrieve the code from my other V4 development system and insert it into a Listener?
  9. Are all me database tables preserved by the upgrade?

Similarly, what happens to a customer/live system that runs my application and upgrades from V4 to V5?

  1. Starting with live system running my application on V4
  2. IPS is upgraded from V4 to V5.
  3. Presumably my application is disabled by the upgrade as it is not compatible?
  4. 'Customer' installs the V5 compatible version of my application -- is all now OK with no loss of data?

Thanks very much.

John

Bump. I would like to know, too 🙂

Link to comment
Share on other sites

Custom applications will remain untouched. That includes files and data. For development environments, you would upgrade to v5 and then start with updating your files. It was mentioned above that this might be impractical, but the reality is that every file must be modified regardless; at the very least, the class needs to be renamed to remove the underscore.

In a live environment, your application would be disabled and locked until a new version is uploaded. Note that we did this when upgrading to 4.5 as well.

Plugins will be deleted completely, as the entire table is dropped. Your local files should still be present, though. 

Link to comment
Share on other sites

1 hour ago, Esther E. said:

Plugins will be deleted completely, as the entire table is dropped. Your local files should still be present, though. 

Will plugins be "uninstalled" (deleting all settings, templates, etc) or is the table simply dropped in the upgrade step?

Link to comment
Share on other sites

2 minutes ago, teraßyte said:

Will plugins be "uninstalled" (deleting all settings, templates, etc) or is the table simply dropped in the upgrade step?

Just dropped.

Link to comment
Share on other sites

3 minutes ago, Esther E. said:

Just dropped.

I assume templates are wiped (since they're completely different?), but this will leave a lot of unused settings, tasks, widgets, etc, around in the database then. 🤨

Edited by teraßyte
Link to comment
Share on other sites

23 minutes ago, teraßyte said:

I assume templates are wiped (since they're completely different?), but this will leave a lot of unused settings, tasks, widgets, etc, around in the database then. 🤨

Yes, but the alternative would be to uninstall and have data loss. 

I figured the best solution is to leave everything in place so that when you create your application to replace the plugin, your installation can transfer those settings, etc to your app.

Link to comment
Share on other sites

56 minutes ago, Esther E. said:

Just dropped.

I assume any tables installed by the plugin will remain in place? And you are just speaking about the table listing the plugins? 

Link to comment
Share on other sites


×
×
  • Create New...