This is not really an issue! More like an 'announcement' or so. I'm working on PHP 8.0 compatibility.
GwynethLlewelyn opened this issue · comments
This is addressed mostly to the @dotproject-devops, but possibly of interest to many others who have been faithful to dotProject for so many years (decades, actually).
I have picked up dotProject again, after a hiatus of about a decade or so. Naturally enough, I wasn't expecting it to run on recent PHP versions; it was good enough for me that at least the GitHub repository has an entry from December 2020 (just a tiny fix, but a good sign that people are still working on it!), and that there are people still posting new issues — meaning that they're still using the code, outdated as it is.
Because I needed to deploy a project management system quickly, and one that worked with the old-fashioned 'waterfall' paradigm (these days, 'project management' seems more to be chatting on a channel as opposed to actually setting tasks and milestones and complete them...), I went back to old, faithful dotProject. And because I like to live dangerously, I've installed it on PHP 8.0.3, nor less.
Obviously, it doesn't work — nor was I expecting it to work, either. I could have tried it out with Docker, but, alas, I'm not such a Docker fan myself. Instead, I rolled up my sleeves and started to fix all the code to run on PHP 8 instead; a hundred commits later, and perhaps 200-300 lines of code later, I can at least install dotProject under 8.0.3 and even do 'many' things, i.e., it's not 'crippled' any more, and there are much fewer WSoDs. My work is far from being complete, but it's getting there; I'll be submitting a pull request as soon as I finish the last cleaning up (getting rid of all those each()s...).
At every file I open to change/correct/update the code, I wince at so many neglected aspects over the years... so much that could have changed!... Imagine, the whole ADODB code block was extremely useful back in the early 2000s, but today, we have PDO, which is not going away and it's built-in in PHP (that means: written in super-fast C). Such a huge effort to include the PECL DateTime module, making sure that inherited classes don't change anything crucial — a module that is still around in PECL, sure, but abandoned, replaced by all new and fancy date/time functions that come natively with PHP these days... and the list goes on an on. Ah well! For now, my focus will be to get dotProject to work on PHP 8 without throwing warnings/notices/WSoD, and then, time permitting, I'll take a look at what can be done with the remaining 'legacy burden' of code. At least it seems to have been reasonably kept up to date (I needed a newer DateTime PECL, and I'm considering bumping up Smarty to the latest & greatest — and possibly Quill too — but most of the 'legacy' code is reasonably recent).
I've seen that the web2Project — which started as a fork of dotProject — has sort of fizzled out after having it running under PHP 7.2. Keith stopped posting on the blog in 2012; the support forum is down; and although there still was an update in 2019, it seemed to have been abandoned. Which is a pity, because I can see that there are a few good ideas there that could be readily re-used (yay FOSS!). I might frown at replacing the core engine/router with Symfony, though; I understand the motivations behind it, but dotProject has its own engine/router, which works rather well, and there is really no point in starting from scratch with something new, even if — naturally enough — there could be benefits in using a 'industry-standard' engine/router (I'm not really very fond of Symfony myself, although Laravel is even worse, and I couldn't ever decide which platform/framework would be 'best' — all I can say is that dotProject works rather well 'as is'). For instance, it seems that web2Project has implemented a more standard and future-proof 'vendor' framework, allowing third-party components to be much easily replaced, using composer or similar tools. That's something worth thinking about. Again, I have many ideas, but probably no time to implement them all.
What I will attempt is to write a new theme! It's 2021, and, frankly, dotProject looks too much like 2005. I'm a bit rusty in writing Smarty templates and associated code, but I think I may come up with something better-looking than the current choices — definitely going Bootstrap and using crisp-sharp SVG icons, of course!
With dark theme support!
Anyway, I'm posting this 'announcement' here because I couldn't find any forums or mailing lists for dotProject. The website is also minimalistic — does anyone in the @dotproject-devops still maintain it? Is there any way to do something worthwhile with it, i.e. does it still run on top of Drupal or something? Or is it just one static HTML page? If so, what do you think about redirecting it to a GitHub site? That way, we could all contribute with documentation via PRs, without the mess of dealing with logins, passwords, where to host the project, etc. — and just have dotproject.net redirected to GitHub's pages (presumably something like dotproject.github.io?). Or do you prefer working on the Wiki pages instead? The principle is the same, it's just the look & feel that is different...
For what's worth, the pull request is now live, I'm just waiting for a review
... and for what's worth... it still has some issues
@GwynethLlewelyn thanks for all your hard work! It really is good to see some quality work going back into dotProject after its neglect - and may I say, most of the neglect is down to me not having as much time day-to-day to get back into it. I'll take a look at your pull request and let you know if I see any issues (but at this stage unless there is something terribly wrong I would think any progress is fine).
Thanks @ajdonnison — I have to say that this PR is a bit, uh, how shall I put it... outdated? lol
In other words, it really requires a bit more polishing. My current branch is far, far better, and I believe I have something close to 90% working functionality.
Now I'm working on a very simple dark theme (it's trickier than I thought), but, for now, I think that focusing on functionality over interface ought to be an 'improvement'...
... oh, I'm so stupid. GitHub is so much more clever than I thought. Guess what, it even keeps the PR up to date with my latest commits!! That shows how little I use GitHub for actual collaboration, as opposed to my usual one-person-only-repositories...
Anyway, there is soooooooooooooo much that needs improvement at one stage or the other. What I'd love to do is to get rid of a lot of redundancy here and there. For instance, there have been a gazillion methods implemented to deal with XSS. Most are relics from the far past and way too naïve; more recent code is based on the reasonably-up-to-date Drupal 6 code to filter out the worst of the worst. I've updated a lot of the code to use HTML Purifier instead, but I have not thoroughly tested it throughout the code (the main reason was making sure that at least the Rich Text Editor provided by the updated version of QuillJS would get 'clean' code).
I'm still scratching my head about why Smarty has been included in the lib directory, since, as far as I have dug into the code, I haven't seen it being used yet. A move towards using Smarty globally would go a long, long way to allow the interface to be much more detached from the code and start using modern frameworks on top of it, namely, Bootstrap (to mention the only one I've tinkered with).
But first, a much easier task for me: getting rid of blurred, ancient icons and replacing them with modern SVGs
About smarty - if memory serves, there was a branch in subversion that had converted the UI to use smarty in the long, distant past
About smarty - if memory serves, there was a branch in subversion that had converted the UI to use smarty in the long, distant past
Awwwww... that would be worth 'resurrecting'! The current old-school approach is really very, very tough to change without breaking everything. I'm adding a new theme (a dark one!), just to try out how hard it is to make these kinds of changes, and it's now obvious that there are really a lot of things that are simply injected from deep within the core, completely outside the scope of what 'themes' can change. Some very tiny issues could be ever-so-lightly rearranged, but, alas, moving everything to Smarty right now is next to impossible.
Thanks for for this good working, we try today first time.
When we click any options for example "write config" or "Install db & write config" Installlation not working but we have PHP 7.4 version installation. We use PHP 7.4 version config.php and databeses files. Can you check this ?
When we try to see gantt chart, if the project owner and the login user aren't same gantt chart doesn't display. Can you check this ? (We try PHP version 8 & 8.1)
Note : We use devel branch