For years, I have worked with Tiki Wiki (TW). TW is a software platform that utilizes a wiki structure much like Media Wiki (MW) — MW is the framework upon which Wikipedia operates. In fact, going all the way back to version 2.x, myself and those in a close knit group have liaised with some of the developers there as we saw the incredible potential for the software. TW, as opposed to MW, is a granular permissions based wiki. What I mean by this is that MW has a core of code which was never intended to restrict or obscure access to data at a page based level. Other than Intellipedia, the US Intelligence Community’s version of Wikipedia, the ability to secure sensitive compartmented information (SCI) with a native MW core, is virtually impossible. With TW, the core itself, was originally designed for such. TW is 10+ years old, translated into 40+ languages, has 250+ code contributors (via CVS/SVN), 1,500+ built-in features and preferences, 1,000+ wiki pages of documentation, 1,000,000+ downloads, and 1,000,000+ lines of code, with a code commit every two hours (on average). For an Open Source piece of software, it is fair to say that it is one of the largest projects out there, today.
And while TW lauds the documentation, the reality is that a fair chunk of it is left wanting when it comes to laymen whom are not mid-level familiar with Linux – Terminal operations. In fairness, though, TW is a completely volunteer based project.
The installation of TW is fairly straight forward on any hosting provider — One Click to be specific. Updates, though, are virtually impossible without a deeper dive into the manual process or access and familiarity with terminal. On average, the update process, if farmed out, run about $120 USD. And for many, that represents well over an entire year of shared hosting. Granted, there are the bleeding, cutting edge versions which require frequent updates and Long Term Support (LTS) — LTS usually lasting more than a year or two — the issue is that it is still necessary to perform the security patches no matter which flavor you roll with. Installatron and Softaculous — usually one or the other is available through a reputable hosting provider — both install with the one click; however, both seem to have periodic issues with the auto-update procedure. Factoring this with the fact that the updates, themselves, are dependent upon transmission to the providers from TW, it blends a unique recipe not for the faint of heart. To these points, I have a love – hate relationship with TW. I love TW for all that I believe it is capable of doing — it includes features like a built in blog, forum, and wiki amongst dozens of other things. To the detriment, is the layman’s documentation which is what we are going to talk about today.
As a footnote here, the ability to get a hold of volunteers at TW is marginal. They have an IRC channel — kinda like a real time chat — but over the past 3 years, I have never had a question answered there. The MW community is far more robust. TW maintains a web presence with a Q&A kinda forum, but that, too, is found wanting if you have a timely need. And even many of the answers are both techie in nature as well as if the party forming the question doesn’t know how to express it properly, it generally goes by the wayside.
At the heart of upgrading and installing many of the needed Packages to expand features — such as pdf, editing of documents imported, etc. — is Composer. So, what in the hell is Composer? Glad you asked. Here is what the maintainers have to say,
Composer is a tool for dependency management in PHP. It allows you to declare the libraries your project depends on and it will manage (install/update) them for you. Composer is not a package manager in the same sense as Yum or Apt are. Yes, it deals with “packages” or libraries, but it manages them on a per-project basis, installing them in a directory (e.g.
vendor) inside your project. By default, it does not install anything globally. Thus, it is a dependency manager. It does however support a “global” project for convenience via the global command.
So, now that we know the program necessary to perform functions necessary in TW, we need to learn the how of those functions. There are several ways to interact with the server which stores your data. First, if you have hosting, you are probably familiar with cPanel. In essence, cPanel allows you to directly interact with the files stored, amongst other things. Basically, it is a graphical user interface (GUI) which allows you to do things without having to access the terminal using command line interfaces which dumbfound many laymen. Our challenge, though, is that in the case of Composer, we need to tell files to do something and this cannot be accomplished with cPanel. What we need is the ability to execute commands within a Secure Shell (SSH) — a cryptographic network protocol for operating network services securely over an unsecured network. Generally speaking, we call this activity SSH File Transfer Protocol (SFTP). There are a myriad of programs which do this — PuTTY for Windows and I use Snowflake for Linux – Ubuntu. Now that we know how to use the Composer, let’s dig in a bit.
In order to be able to use Snowflake — I will use it, but interchange any program as the features are all about the same — we need to get some information first. We need to know things like the host, the port, the username, and the password. These are entered and voila, you are inside of your server.
When I am inside of my server I see the following features and select Terminal from the left,
I now need to access the directory in which my website is stored. This will depend upon whom hosts you. For me, the directories are assigned by website name as I run an Enterprise level server. So, you would type cd anysite.com — cd is a command that means change directory. Thus far, these have been fairly straightforward things which could be researched and nothing revolutionary. The next part is where it took me months to figure out.
From the root of the directory generally, you need to type the following command: php composer.phar install and hit enter. It may ask you to update or approve some files, just type Y for yes. Now, because there are other other occasions that Composer is used, I also elected to install it in the temp folder — temporary folder. You will need to type cd temp and then install accordingly. From there, type cd .. — yes cd space two periods — which will return you to your main folder. Remember, if you DO NOT type the two periods and simply cd, it will return you to the main root of your server and not your website! So, we have Composer installed where it now needs to be. Next, we will discuss the Package installation process.
Here is what TW says about Packages and why you need to learn and use Composer,
Composer is used in the Tiki code development process to import and manage external software such as jQuery and Bootstrap. But some software cannot be packaged with Tiki due to an incompatible license, or shouldn’t necessarily be packaged with Tiki by default because of the software’s specialized nature or niche application. So it is a natural step for Tiki site administrators to be able to use Composer to install and manage external software specifically for their site after the site is installed.
In a nutshell, this is the long and convoluted argument about how software is licensed. In laymen’s terms, all that matters is that you have to install certain products of your own accord. So, let’s get to it. We are going to talk about TW 22.1 today. Composer has been around since TW 18, though. Most of the time, if you need a feature TW will intuitively move you to the Packages section. If you are curious about what all is available, simply go to the Control Panel and select Packages. Let’s say that you need to install media-alchemyst. This is a Package which allows for the transmutation of media such as manipulating pdf as an image or the sort. The package is identified as media-alchemyst/media-alchemyst ^0.5.4 in TW. Now, it should be noted that when the Package is needed, you need to copy and paste the package, like aforementioned. The problem is that when you paste it into Snowflake, you need to manipulate it a bit. Any Package that we are going to install via Composer, must be prefaced with php temp/composer.phar require –update-no-dev –prefer-dist in front of the Package name. And then we must add a colon in between the name and the version. Here is how media-alchemyst would be installed: php temp/composer.phar require –update-no-dev –prefer-dist media-alchemyst/media-alchemyst:^0.5.4 and everything is case, character, and space sensitive. Upon successful installation it will inform you what it did and offer a piece of code to inspect the files if you so choose.
Each hosting provider is going to be a bit different in what and how they allow you to access and execute command line code. I am with TMD Hosting and they have been nothing but phenomenal for over a decade plus now. I utilize the Cloud based servers; however, it is still considered shared hosting. To that point, though, they initially told me I could not execute the commands. Their command line terminal feature was available, but similar to Amazon’s Lightsail — which I maintain for another Client of mine — I just didn’t like it and opted to use Snowflake and had no issues.
Next week, we are going to discuss deploying the Tiki Wiki Upgrade command line program for updates. Their documentation is found wanting, to say the least, for laymen. It pre-supposes the fact that everyone is a mid-level coder, as I earlier discussed. My hat is off that they, at least, set up a feature called Manager. The issue that still presents is why systems are not able to make One Click Updates, like say WordPress. Regardless, we are going to get into the nuts and bolts of it and walk you through how to roll it out!