thanks for the update, I have updated the information on the github page : https://github.com/iForumModule/iforum/blob/master/README.md
One of these days I should test iForum thoroughly on PHP7 and release the 2.0 final
Ran some tests this morning - iForum 2.0 requires ImpressCMS 1.3+ and not 1.2+ as the readme states. I'll have to do this in stages
I'm thinking of updating the imBuilding templates to make them compatible with 1.4. While doing that, adding a skeleton to support fine-grained permissions might be a worthwile improvement.
I've been reexamining my choice of having separate modules for news (time sensitive posts), articles (long term posts), and blogs (mostly point-of-view posts, that could be short- or long-term posts) and haven't done much in the way of documenting a path forward, especially for modules that don't have a current compliant version.
The forum migration should be workable - iForum has the permissions structure I'm looking to maintain and works in ImpressCMS 1.2+. We also know it works on 1.3.
News will probably end up being blog posts, and articles will probably end up being wiki pages. I haven't fully decided, yetl
Hi @skenow , any news on this one? If the page on the wiki needs updating, feel free to do so based on your experience
I'll have a look if I can find the migration script we had for the imblogging module, I think it could be useful for moving over the original news to the new news module by @madfish.
The permissions in the IPF modules until now have been handled exclusively in the 'groups' section of the system module, and there is no permissions handling done anymore in the module itself. That is a part that would be missing right now.
I did a similar move more or less a year ago when we migrated the ImpressCMS site from multiple versions to 1.3. Some modules were no longer available in 1.3, so we had to reconfigure everything from scratch, and we also did a few SQL-based custom written migrations.
As far as I know, no module out there has 'import' functionality so you might need to write your converters on your own. Having a framework (à la Drupal Migrate) that offers a standard way of doing this would be a major positive point for a future version I believe.
Moving from CBB to iForum is easy : the table structure is the same, and the URL structure is the same. If you move the attachment files into the iForum upload folder, you should be OK.
I do use group permissions for news categories - not everyone can see every category of news. The same is true of the forum, as well. Being able to assign permissions based on group and category is pretty crucial in a lot of sites, IMO.
Modules that were built on the newer code base of ImpressCMS don't seem to have this feature - or am I wrong? I am also wondering about migrating data - do the modules account for the move from old code base to the new code base, or will I be working out my own data migration?
Also - has anyone gone from 1.2.x to the latest 1.3.x? Are there midpoints that are best handled in steps?
If you install from your own upload to the host, does it work?
What are you able to see from CPanel/WHM/Plesk? All the files/folders, database?
I am setting up some sites on my hosting account, and I'm basing them on a softaculous installation. However, I can't seem to get a working install in 1.3.11, I always get a blank page.
The ImpressCMS site is running on a Softaculous install that was upgraded from 1.3.10 to 1.3.11, so that works. But it looks like an install from scratch is problematic.
Can anyone test a softaculous install and let me know?
Thank you very much for the latest updates.
I upgraded that requirement as a sort of security help : PHP 5.6 is the only supported version of PHP 5.x at the moment. Supporting very old versions of PHP is not a good idea security-wise, so I bumped the version requirement to 5.5.
Having said that, I'll need to update the translation variable so that it talks about the correct version of PHP (we're way beyond PHP 5.2+ already).
I just tried to install ICMS 1.3.9 for a new site, I get the following error on step one of the installer:
PHP 5.6.0 minimum is required for ImpressCMS to function properly - your installation cannot continue. Please work with your hosting provider to upgrade your environment to a version of PHP that is newer than 5.2.0 (5.2.8 + is recommended) before attempting to install again.
Aaron Stuart just posted a very nice step-by-step article on WebSetNet about how to configure a Linux VPS from scratch in order to run ImpressCMS on it.
The article mentions it is written for Ubuntu 14.04, and if you want to do simple copy-paste of the commands you will need to get that OS on your VPS. However, if you're a bit at home in the Linux world, you should have no problem translating the commands to your specific tools and versions.
If you have this kind of setup routines that you have perfected throughout the years, please share!
There is a variant that is all git commands -
git archive -o filename.zip [commit hash new] $(git diff --name-only --diff-filter=ACMRT [commit hash old] [commit hash new])
It will create either a zip or a tar.gz archive, guessing which from the file extension. Or you can specify the type using -format=[type]
Here's an example for getting the files changed between the 1.3.8 Final release and the 1.3.9 RC release:
git archive -o impresscms-138-139rc.zip 8b451c0 $(git diff --name-only --diff-filter=ACMRT b182a01 8b451c0)
I run this when I'm in my git repository directory for ImpressCMS
Edited Dec 31, 2018 to be able to see the commands
Here's the first one - used it tonight to create the 'upgrade' package for 1.3.x to 1.3.8
Note: I use Ubuntu, so it won't work on a Windows machine!
Here's how the command breaks down -
Take a diff of the given commit to the older commit (including all subdirectories, not just the top directory).
Do not output the commit SHA1. Output only the names of the affected files instead of a full diff.
Only show files added, copied, modified, renamed or that had their type changed (eg. file → symlink) in this commit. This leaves out deleted files.
Send the output to a tar.gz file. You can also run without this to just get a list, or send to a text file.