How do I upgrade
I'm a strong advocate for frequent updates and early experimentation. My approach is to swiftly address or create bugs reports. It ensure a rapid adaptation to changes and use the improvement of a new update versions. I prefer starting with a 'clean slate,' gradually integrating project customizations to ensure seamless alignment with new implementations, such as changes in underlying technologies like Bootstrap, Smarty, etc. This approach enables agile and efficient development, allowing for quicker adjustments and optimal utilization of the latest Tiki features and enhancements while it forces backup creation of the customer critical assets.
Assessing the Current Tiki Installation
Start by thoroughly evaluating the existing Tiki installation, the current Tiki version, its features and settings, and any customizations in use.
Review the server environment and make sure it meets the requirements for the target Tiki version.
Identify any known issues or limitations with the current version that need to be addressed in the upgrade.
Backup the Data:
Before making any changes, create a clone of the Tiki instance and I create a backup of the database, the theme, files of the Tiki File Galleries, the System parameters, the robot.txt and the languages extra files (if any). This step is crucial to ensure data integrity and recovery options..
Using a Git repository
In the summer of 2019 , the development of Tiki Wiki underwent a significant transformation as it officially shifted its code management to Git. This transition was complemented by the decision to utilize Gitlab for code management. During this pivotal period, I created a series of video tutorials aimed at assisting fellow developers in smoothly making the transition to this new development framework.
I've seamlessly integrated Git into my workflow, streamlining project management by establishing a Gitlab repository for each project. This approach simplifies project oversight and allows for a distinct set of 'ingredients' and dedicated access for each individual project. Once the project repository is established, I initiate a new project branch derived from the latest stable version of Tiki (or the specific version targeted). In doing so, I ensure that I'm working with fresh, unaltered files directly from the Tiki repository. When cloning a branch using Git, the default behavior is to include the entire history of that branch. Given Tiki's high level of activity, this could result in an exceptionally large instance. To maintain efficiency, particularly for customer projects, I opt to minimize this history by excluding it from the clone, keeping the project's data compact and manageable. This is how look my typical clone command (protected with my SSH key):
git clone --depth=1 --branch=domain_tiki25x git@gitlab.com:xxxx/xxxx.git public_html/
Test the Upgrade in a Staging Environment
To test the upgrade process and iron out any issues or conflicts that may arise I use a local or a dedicated remote server I have in hand.
This allow to test all custom code, themes, and extensions in the staging environment to ensure they work correctly with the new version as well as adapt code and design elements that may have changed or not behaving as previously.
The database
I create a new database specifically for the Tiki version I'm working with.
Import a backup of the existing database, which contains the content and parameters, into this newly created database. While this may seem like additional effort, it offers several advantages:
I don't make any changes to the previous Tiki installation, ensuring it can be rolled back to at any time.
I can experiment and make fixes on this cloned instance while keeping the production environment online without disruption.
I have backups of both files and databases.
Each Tiki version has its own dedicated environment, allowing my customer and me to thoroughly test, improve, and explore the newly added functionalities or options until we reach a consensus on the migration date. Once this is finalized, I proceed with the installation process as I would for a fresh Tiki install, continuing until I reach the database setup step.
Tiki new install
Local Host Setup
I create my new host on my local computer with the correct parameters, including folders, SSL, hostname, and PHP version.
And start the Tiki installation process including running the Composer packages setup.
Progressive Migration
During each stage of the installation, I identify settings that needs to be changed and files that needs to be transferred from the old version to the new version.
For example, if I encounter issues like insufficient memory during the setup, I correct or add the relevant parameter to fix it.
Any file additions or modifications are committed to the new Git branch to ensure that the fixes are saved for later deployment on the remote server. This also provides access to Git and Gitlab tools for version control, comparison, and reversion.
Database Connection
I configure the database connection and point Tiki to the new database, which is essentially a clone of the previous one.
Two options: Reinstall the database or Upgrade, I choose the Upgrade option and complete the Tiki installation process.
Custom files
Now it's time to begin copying the custom files. I make an effort to minimize customization and to preserve the core files clean, which simplifies backup and upgrades. Here are the key areas I focus on:
- Project Theme Directory: This includes custom CSS, templates, scripts, favicons, and other theme-related files. (Desktop and Mobile)
- Project Templates: This require special attention and allow more fixes and optimization of existing templates.
- Project Content Files: I review the Tiki File Gallery setup, optimize the parameters and copy the previous file gallery folder.
- Custom Language Files: I review any language files that have been customized for the project.
- Parameters Files: These are the Tiki system configuration files, which often contain project-specific settings.
- SEO Files: Files related to SEO, such as robot.txt or HTML validation files
Fixing errors and changes of behavior
As with any software upgrade, it's not uncommon to encounter errors or changes in behavior that may require attention. Here's a structured approach to identify, address, and resolve such issues:
After completing the Tiki upgrade, thoroughly testing Tiki instance will help to identify any errors or discrepancies in functionality. I review the error logs to seek and understand issues.
I Carefully compare the previous Tiki version with the new one and I pay special attention to any deprecated or changed settings that might affect functionality. I Conduct regression testing is necessary to verify that previously functional features are still working as expected. I Address issues one by one, applying incremental fixes and closely testing each resolution to confirm its effectiveness.
I usually keep tracking of changes and update modification using my articles (you are reading one of them 😉), the Tiki ticketing system and task management (that will be communicated to my customer). This documentation allow me to retrieve quickly the changes made to accommodate the new Tiki version. This is crucial for maintaining a clear reference for future maintenance and team members.
I commit back to Git all the changes and fixes and I log parameters changes.
Setting Up the Customer Instance on its Final Destination
I ensure that the target server is ready for the Tiki installation. This includes verifying the server's operating system, web server, PHP version, and database compatibility with the Tiki version I'm deploying.
I create a Git clone of my upgraded version of the project and copy all project files to the destination server. I run the Tiki install and set the necessary configurations parameters for the Tiki instance to connect to the database on the destination server. I check the database credentials and permissions are set up correctly. I port the configuration updates I made to the Tiki preferences. I review and update any configuration settings, particularly those related to server paths, URLs, and security, to match the production server's environment including SSL Certificate (if applicable):
Final Testing
I test Thoroughly test the new Tiki instance on the destination server. Verify that all customizations, features, and functionality work as expected in the live environment. Check for any last-minute issues and once I'm confident that the Tiki instance is ready for production, I proceed with the deployment in collaboration with my customer that will be required to test the new instance is running smoothly.
Monitoring and Post-Deployment Checks
I keep monitor the production instance several days after deployment to identify and address any issues that may arise in a live environment. Perform post-deployment checks to ensure optimal performance.
Upgrading Tiki, like any complex content management system, is a process that demands careful planning, meticulous execution, and unwavering commitment to delivering a seamless experience to my customers.
By staying committed to maintaining a lean codebase, using effective version control, and embracing an iterative approach, I keep the Tiki instances updated taking advantage of new features, security improvements, and performance enhancements without major disruptions to the project.
I hope this will help you with your Tiki upgrade and if you need help you can always hire me. 😉