Support

Hello,

I am following up on the procedures/best practices that were provided in this ticket:

https://www.akeeba.com/support/akeebatickets/36260-best-practices-for-joomla-4-upgrade.html

As you are aware, we have discovered a variety of bugs and received software versions that addressed them and allowed us to proceed with our testing of Joomla 3.x/ATS 4.0.8 production ticket data to our new Joomla 4.2.3/ATS 5.1.1 development site. In our first few attempts, we have run into issues that hopefully you can provide insight on.

To summarize our progress:

(Successful) Production Site - Perform Akeeba Backup "All Configured Databases (Archive File)" excluding all tables except for #_ats_*

(Successful) Development Site - Fresh  Install and configure ATS 5.1.1 with new categories, fields/field groups, menu items, etc. 

(Successful) Development Site - Uninstall ATS 5.1.1

(Successful) Development Site - Install ATS 4.0.8 (patched version)

(Issues) Development Site - Restore Production Site ATS DB tables only

• Using the backend ATS Control Panel, I can see ticket data, but there are display errors 
• I have noticed also, that after restoring the DB using kickstart, the front login module generates a 404 error. I have confirmed that this items exists.

(Issues) Development Site - Update ATS 4.0.8 to ATS 5.1.1

• During this step, I do not uninstall 4.0.8 I just install 5.1.1
• From the backend ATS component I don’t see any data including
  • Tickets
  • Custom fields/field groups created in the fresh install and configuration phase
  • Customized email templates are reset to default
  • No categories exist
• Interestingly the dashboard does indicate our production statistics
• If I view the _ats_tickets table in php admin I DO see all of the restored ticket data
• If I view the _fields table in php admin the previously created fields are no longer present
• If I view the _categories table in php admin the previously created categories are no longer present

 

If it would be helpful I can provide a fresh copy of development site and a backup of our J3/ATS4.0.8 DB backup.

Any help or suggestions would be greatly appreciated. 

Thanks as always for the support!

Eric

Nicholas,

 

I have been doing multiple tests. In my testing it seems the issue is with the uninstall of 5.1.1 after setting up the new development server. When viewing the DB tables in phpMyAdmin, I see that immediately after the uninstall of ATS 5.1.1 the ATS categories, fields, field groups and mail templates are removed from the Joomla core tables:

_fields, _field_groups, etc. In addition the ATS created mail templates are removed from _mail_templates.

 

I believe that the ATS 5.1.1 uninstaller is removing the custom fields, categories, etc. and not the restore process of the production site's ATS Tickets tables.

 

Please advise if you have a suggested workaround or if it is possible that the ATS Uninstall program can be modified?

 

Thanks in advance for your support!

Eric

 

Nicholas,

For reference, I have included a couple of screen recordings:

 

DB Tables Before uninstall of ATS 5.1.1

https://watch.screencastify.com/v/eJKT9EiB39caGMzsHCAR

 

DB Tables After uninstall of ATS 5.1.1

https://watch.screencastify.com/v/OU5dk8OPOaBhhcJwLZhr

 

You will clearly see that after the uninstall of ATS 5.1.1 all previously created ATS categories, fields, field groups, mail templates are removed.

Please let me know if you need more information.

Thanks,

Eric

Nicolas,

I have been testing the process and have found a few modifications are required:

 

1.) Modify the ATS 5.1.1 Uninstall script still does not prevent the removal of the custom field values, categories and email templates

I have been successful using Akeeba Backup to backup the tables just prior to the removal of ATS 5.1.1

 

2.) When performing a DB tables only restore, I have found that Kickstart replaces the .htaccess file with it's own two line file. This is even if the DB backup excludes all files and during the kickstart restore process I select "no change" to configuration files.

Currently my workaround is to copy the default Joomla htaccess.txt file and rename. I am unsure if there is something I am doing wrong here but it would be one less manual step if Kickstart didn't change any of the configuration files

 

3.) Overall, the process is workable if one has Akeeba Backup.

 

For reference I have included my modified uninstall.sql script.

 

Thanks for your assistance and please let me know if you have any further suggestions to make the data migration easier, but at the present I am able to proceed with the entire site cutover process testing.

Eric

Nicholas,

I completely understand your constraints and appreciate all of the support you have given us. I am working on a checklist/document that will cover the data migration from J3/ATS4 to J4/ATS5. I can share this with you if you are interested after I have tested the process end to end and worked out all of the details. Perhaps other customers that are or will be migrating would find this helpful.

I do have some other data related questions that it would be helpful to get your input on:

Migration of ATS Attachments

-Currently I am copying the ATS4 com_ats/attachments directory to the J4/ATS5 server

My observation is that ATS stores attachments as data blobs, which are linked in ATS Tickets DB. I assume that there should not be an issue displaying the attachments on the J4/ATS5 server assuming the com_attachments directory is the same on both servers?

 

Migration of ATS Inline Images

-On both the J3/ATS4 and J4/ATS5 server I am using JCE. On the J3/ATS4 server JCE is configured to store in /images. On the J4/ATS5 I have configured JCE profiles to store inline images in each user's own directory.

My assumption is that copying the images folder from J3/ATS4 to the J4/ATS5 server /images  folder will allow all of the migrated tickets to show the inline images with no broken links. Moving forward all new tickets on the J4/ATS5 server the inline images will be stored in the /images/user/<user_id> folder.

Once again I appreciate your help and support!

Eric

Nicholas,

I have finally been able to get a successful end to end user and data migration on our test server.

I have noticed that there is a significant (5-10 second) delay when submitting a ticket after restoration operation. This is compared to submitting a ticket on the fresh ATS5.1.1 initial setup and configuration operation. 

Speaking of....have you considered some sort of animation for end users when submitting a new ticket or post? We get duplicate tickets/posts from impatient users who aren't aware the form is processing.

Below is a the high level process I have used. In reviewing this there are some opportunities to improve the flow by better incorporating Akeeba backup profiles for the production site DB tables+attachments+inline images. Akeeba Backup makes the entire process "bearable". 

Not sure if this helps you but just in case you have other customers moving to J4 in the near future.

Thanks,

Eric

 

User Export/Import

• Production Site - Export users from Production Site
• Development Site - Import Users

• • Add ATS Support Staff users to appropriate Joomla Groups

• Development Site - Spot Check user ID's match Production Site

ATS Data Migration (Production Site)

• Backup CMS0 Production ATS DB tables
• Download Backup Archive to admin workstation
• Copy /images directory to temp directory on admin workstation using SFTP
• Copy /media/com_ats/attachments to temp directory on admin workstation using SFTP

ATS Data Migration (Development Site)

• Backup ATS 5.1.1 Core DB tables
• Copy and save .htaccess as .htaccess.bak
• Remove ATS 5.1.1
• Restore ATS 5.1.1 Core DB tables
• Install ATS 4.0.8
• Restore Production Site ATS DB tables
• Restore Production Site Attachments and Inline Images from temp directory on Admin workstation using SFTP

• • Copy /images to development site
  • Copy /media/com_ats/attachments to development site

• Modify production categories to match development categories (The below are the catid's of our particular Development and Production instances, your catid's will vary based on your development category setup

Issue the following SQL Statements on the development instance

• Tech Issue (97)   > Tech Support (17)

UPDATE `gna_ats_tickets` SET `catid` = '17' WHERE `gna_ats_tickets`.`catid` = 97

• General (115) > Tech Support (17)

UPDATE `gna_ats_tickets` SET `catid` = '17' WHERE `gna_ats_tickets`.`catid` = 115

• Event Media (118) > Event Support (18)

UPDATE `gna_ats_tickets` SET `catid` = '18' WHERE `gna_ats_tickets`.`catid` = 118

• Special Event Setup (119) > Event Support (18)

UPDATE `gna_ats_tickets` SET `catid` = '18' WHERE `gna_ats_tickets`.`catid` = 119

• Restore default .htaccess
• Install ATS 5.1.1
• Set ATS component permissions

• • Grant “Support Staff” to “Technology”
  • Grant Create, Edit Own Ticket, Edit Own Post, Create Private, Create Attachment to “Registered”

• Set ATS category permissions

• • Tech Support - Grant “Support Staff” to “Tech Support”
  • Makerspace Support - Grant “Support Staff” to “Makerspace Support”
  • Event Support - Grant “Support Staff” to “Event Support”

• Republish “Akeeba Tickets-Info” front-end module on New Ticket menu item
• Turn off InstaSearch option
• Verify front-end and back-end ATS functionality

• • Test Ticket Creation
  • Test Manager Notes
  • Test Email Templates