Development Discussions

Re: embryonal multi-site support

My first approach will be very basic : one unified installation, with different configuration and database, based on domain name. Once this is working, I can contemplate more complex use-cases with module overrides and an overarching admin page to manage multiple domains.

The change

That one is quite easy to get working : I define separate instances of mainfile.php, with the domain name embedded, such as mainfile_www.domain1.com.php and mainfile_domain2.org.php. Each of those files contains a complete configuration of an ImpressCMS site. I then replace the content of mainfile.php to include the mainfile based on the server host.

This must be hardened and improved, but works well for an alpha version :

$mainfilename = "mainfile_". $SERVER[HTTP_HOST] . ".php";
include $mainfilename;

I was able to have 2 domains point to the same hosting instance, and this works great. The same ImpressCMS filebase, pointing to a different configuration file and database, based on the domain you use. There is only one fairly important part that's not working : I can't login with the domain I added. Probably a minor detail somewhere, so I'll figure it out soonish.

Improvements

At the moment there is no distinction between the different sites when it comes to storage of images, uploads and cache data. That needs to be improved as well before this can be considered beta. But all in all, with a single small change, I'm impressed that I got this far already.

Report
Topic


Re: Standup Reports

There are a few more issues to resolve before the next beta release - some of the system blocks won't display, and some of the system settings (WYSIWYG editor permissions, viewing debug) aren't applying properly. The fixes are pretty straightforward and I'm about ready to submit the pull request. In addition to these updates, I've been working on some other modules that will need some updates to be error free and compatible with 2.0.0 and PHP7/8. These are affecting me because I'm prepping to move several sites to a new host and PHP5.6 won't be an option there (and I'm not going to try to make it an option). While testing the modules and debugging some things, I have to make sure it is in the module and not in the core, which takes a bit longer. Here in the U.S. we're getting ready for Thanksgiving and we get rather busy with food, family, and friends. I hope you all are going to be able to have time with your family and friends, too.

Report
Topic


Re: logger documentation

From what I remember, the constant defines what file will be called to do the logging. All the logic exists in the path/file you define. This just serves as sort of a preload - if it's defined, include it.

Report


logger documentation

I wonder if someone still has the correct information for the setup of the basic logger, because the documentation page on https://www.impresscms.org/modules/simplywiki/index.php?page=Logging_Hook is broken.

Report


Re: Standup Reports

I just contributed 2 small fixes to make the next release more stable

Report


Re: Standup Reports

We had scheduled to do another release this weekend, and during testing for some of the things we targeted for this release (2.0.0 beta 2), we discovered some other things we need to address. They're pretty straightforward issues, so we should have them sorted out by next weekend.

Here's the list of issues we're working on.

Report


Re: Automatic database upgrade for non-module objects?

After looking at this a bit more, I have submitted changes that will look at these 2 tables every time the system module is updated. It might be good to do the same in 1.4.7.

Report


Re: Automatic database upgrade for non-module objects?

If it is feasable to make this automatic, it would be best.

Report


Re: Automatic database upgrade for non-module objects?

I had a good solid foundation for the solution - thanks to all the work others had done before me. I would like to test a few other things and then I'll create a pull request to add this in. What do you think about making this a default action of the system module update, rather than just a step?

Report


Re: Automatic database upgrade for non-module objects?

this looks like a very elegant and minimalistic change, kudos for that!

Taking the module upgrade route would also have been my choice.

Report


Re: Automatic database upgrade for non-module objects?

Well, some experimenting has gotten me the results I was looking for - with a pretty small change to icms_db_legacy_updater_Handler::upgradeObjectItem(). Here's how the first lines look -

  function upgradeObjectItem($dirname, $item) {
        $module_handler = icms_getModuleHandler($item, $dirname, null, true); // this is changed

        if (!$module_handler) { // added this branch
                $module_handler = icms::handler($dirname . '_' . $item);
        }
        if (!$module_handler) {
                return false;
        }

Then, in the system module's upgrade file I added at the end

    if (!$abortUpdate) $newDbVersion = 45;
    
    if ($dbVersion < $newDbVersion) {
        $icmsDatabaseUpdater->automaticUpgrade('icms_data', array('file', 'urllink'));
        /* Finish up this portion of the db update */
        if (!$abortUpdate) {
            $icmsDatabaseUpdater->updateModuleDBVersion($newDbVersion, 'system');
            echo sprintf(_DATABASEUPDATER_UPDATE_OK, icms_conv_nr2local($newDbVersion)) . '<br />';
        }
    }        

After upgrading the system module, I had the 2 tables I needed. Updates of other IPF modules still work.

Any unexpected risks? Another few sets of eyes on this would be fantastic!

Report


Re: Automatic database upgrade for non-module objects?

It would be a major undertaking to rework this and I was hoping there was something to leverage that I wasn't seeing. In order to get this done and the keep this release moving forward, there's a couple of ways to proceed.

1. Do what's been done in other releases and include the table structure manually in the upgrade script (see modules/system/include/update-13.php)

2. Replicate the icms_db_legacy_updater_Handler::upgradeObjectItem() method and modify the new method (or just embed it in the upgrade script) to not rely on the object being part of a module

3. Find a way to modify the icms_db_legacy_updater_Handler::upgradeObjectItem() method to allow for other objects like these in different locations (the library folder), or at least for these 2 objects and their tables.

If we can get it done and take a small step in the right direction to deal with all the other components, that would be ideal.

Report


Re: Automatic database upgrade for non-module objects?

The system module is a strange animal On the one side, it contains functionality that should be part of the IPF classes, on the other, it looks like a mini-core,with submodules that are similar to full-fledged modules, but not quite.

I discussed some time ago with Mekdrop that we should be downsizing the system module and spinning out some of those functionalities into separate modules (like comments, ratings, ...). That would solve some of those issues, but that's not for right away though.

Report


Automatic database upgrade for non-module objects?

I am working on migrating some modules and started with downloads. I discovered my site did not have icms_data_file and icms_data_urllink tables in the database because we never added them to the upgrade scripts when we added them to the installer (in version 1.3.0). The Downloads uses those tables and I'm working on adding them to the database and addressing this for anyone else who might be in the same situation.

If these were module tables, there is an automatic upgrade method that looks at the object and its variables and determines the name and structure for the tables and adds or applies any necessary changes. At this point, I haven't found similar methods for these objects - and there are quite a few. Avatars, comments, notifications, files, URLs, images and image categories, users, groups, group permissions, private messages, autotasks, blocks, ranks, templates, and probably a few more - I haven't gone through them all. They all seemed primed and ready for this approach - am I missing something?

Report


Re: Replacing Slack by Discord

yes, the new restrictions on Slack are pushing 'freeloaders' away, but I suspect that is the underlying reason Slack is now becoming tougher for non-paying users. The era of free money is over, and all these tech companies are now facing the harsh reality that someone needs to pay their bills. Reducing the bill by reducing the non-paying users is an easy step in that way.

Report


Re: Replacing Slack by Discord

Yeah. forums wouldn't work well for instantaneous conversations. Private messages or email also have some delays. For us - we're separated by a lot of time zones, so when I'm posting this, you're asleep. When I get home from work and can sit at the computer for a while, it's 7pm GMT-5. Just so we know people are listening, this was on my suggested posts today - https://www.wired.com/story/how-to-move-slack-archive-to-discord/

Report


Re: Replacing Slack by Discord

A temporary link is available here to test : https://discord.gg/uTu7cdchCd

The import is being throttled, so I'll resume the remaining channels tomorrow. The most important ones are already there

Report


Re: Replacing Slack by Discord

I don't know. Real-time chat has different discussions and needs than in a forum. The 'hey, how are you and how is the weather?' messages don't really go well on forums I think

Report


Re: Replacing Slack by Discord

Thank you, David! Recovering the data from Slack and organizing it will give us some more visibility into past conversations.

Even though we can't easily migrate the channels and conversations from Slack to iForum (currently), would it make sense for all new conversations to be maintained here?

Report


Re: Replacing Slack by Discord

We are 4 hours into the migration of the data (we're talking of a 6MB Slack export here) and we're still going strong. Currently busy importing the #devel channel from Slack.

Report



 Top