I just finished making the necessary changes in the profile module to make it run under PHP 7.3.
The profile module offers an extended user management profile, with the ability to add custom forms to the user profile, have a registration workflow in multiple steps, and allow social interactions between users in groups called 'tribes'.
I would like to merge this version into the ImpressCMS core 1.4.1 distribution in a few days, so please test and let me know if you encounter any issues.
It took me longer than expected to start working on it, but I finally did so. And the cleanup was easier than I would have thought : after just a few hours I can say that I have a beta release for iForum available that runs ImpressCMS 1.4 under PHP 7.2. If you are interested to test, the github release is here :https://github.com/iForumModule/iforum/releases/tag/v2.1-beta
I haven't touched the workings as of yet (I plan on doing that in iForum v3), simply ushered in a new era of PHP. Let me know if you find bugs on the Github issue tracker
At this point, the default is to allow all comments if the module has comments (in icms_version.php). Probably since the base assumption is that ImpressCMS and predecessor were community sites and that would be the most common choice.
Also, all notifications defined in icms_version.php will be enabled by default.
Neither of these are reading anything from the module at the time of install.
However - you could override those options after the module is installed with the install function for the module, which is called at the very end of the process.
How do i disable comments and notifications as default setting of a module preferences
and also set default permission of module when installing the module
is this possible? any example i can refer to ?
<p>I tested this in ImpressCMS 1.4.0 (the module-specific code by marcan) and it works, but the filename doesn't need to have the '.php' extension at the end.</p>
<p>What I'm liking about the router + MVC-type approach is that far less code has to run to deliver a page. eg. my current modules have Ye Olde Traditional handler classes for each object, and these are huge because they hold the code to handle all actions for their client objects.</p>
<p>With the strict MVC approach these monolithic handlers are getting chopped up into smaller model classes, each of which only deals with a specific page view (one or two different actions, as opposed to everything), and the router selects which one to load. So there's a lot less stuff to read for any given page load.</p>
<p>I have made some progress with 2.0 and routing -> https://github.com/MekDrop/impresscms/tree/use-league-router . However right now I haven't figure out how to register routes for modules. But I hope somehow I will solve this and than this functionality will come to icms.</p>
<p>I have already come across Tom Butler's articles (hard to forget him, with his exuberant hairstyle profile photo <img src="https://www.impresscms.org/uploads/smil3dbd4d6422f04.gif" alt="" /> ) and he has some very interesting points, yes. I admit I'm also no rockstar developer in PHP to be able to follow the entire reasoning in 1 go. Some kind of url routing would be interesting to have in ImpressCMS2 (2.0 or a later iteration), for a start.</p>
<p>I've been looking into the MVC pattern, and came across a programming blog that has some very interesting articles about MVC and a couple of its descendants - MVVM and MVVMC. Also has some cool stuff about how to build a front end controller to handle routing.</p>
<p>It took me a few reads to get my head around it. I thought I had been doing MVC, but it turns out not in a very strict sense. Anyway, I'm trying to build something using a front controller and the MVVMC pattern, which is basically MVC except the view gets split into two components (a view plus a 'viewmodel') to decouple the view from the model and allow each component to be substituted or re-used. Together with the front end controller/router it gives you a lot of flexibility.</p>
<p>Worth a read if you have time (see the section 'MVC Related Articles').</p>
<p>Good question. In a way, it depends largely on your user base. That's one of the great things about all those analytics packages, they can give you a good idea about how many percent of your users are on what type and version of browsers. Not only that, they can also give you information about the type of usage they make of your site.</p>
<p>When 4% of your use base is using IE11 and below, normally you would go ahead and upgrade your site, making sure that those users get a nice little message telling them that their browser will no longer work with the site the way it is supposed to, inviting them to use another browser.</p>
<p>Now if those 4% are your most active and productive users, you might want to reconsider...</p>
<p>The linebreaks issue might be a problem with the old default DHTML editor, we have had a problem with it in another thread. Using a HTML editir might fix that if you don't mind receiving HTML email. I think can change it easily as have looked at it before. I'm travelling but will look in a couple if days when I get back (and hopefully have a new laptop!).</p>
<p>HTMLPurifier problem seems strange. Pretty sure it uses UTF-8 by default, so there must still be mis-encoding being fed into it. Will have another look.</p>
<p>Hello Madfish,<br />
Thank you for your efforts. I think I found the problem. It is the HTMLPurifier. If I turn off the HTMLPurifier all umlauts are displayed correctly. But in some places the br tags are inserted again, which leads to ugly effects.<br />
<p><span style="font-size:8px">translated with Google </span></p>
<p>Remember how long we waited for IE6 to die and how much time/pain we went through trying to support it? All the cool new stuff we couldn't use for <em>years</em> because it would break IE6?</p>
<p>So I'm wondering, is it justified to throw IE users under a bus, or are people going to support it until it the bitter end?</p>
<p>I have not been able to find any problem with encoding in the description field. However, I have added:</p>
<li>An accept-charset=utf-8 attribute to the form (will only work on html5 though).</li>
<li>Specified utf-8 as the output encoding in mail().</li>
<p>I hope that fixes it, <a href="https://isengard.biz/library/modules/contact/contact-utf-8.zip">please test this version of the module</a>. </p>
<p>Hello Madfish,<br />
Thank you very much for your efforts. The module works great and helps me on. Where now the problem lies with the coding of the description_tarea lies one must observe.<br />
greeting optimistdd<br />
<span style="font-size:8px">translated with Google </span></p>
<p>Ok please <a href="https://isengard.biz/library/modules/contact/contact-checkbox.zip">download and test this version</a>:</p>
<li>Fixes encoding problem with umlauts in title (I cannot find any encoding problem with the message body).</li>
<p>I ended up having to build a manual template. It works but it is basically a hack and I do not feel happy with it. Anyway, if you want to change the look of the form work directly on the contact_message template.</p>
the regulation comes so far EU and replaces all national data protection laws and regulations also the data protection explanations become longer the more one has external things. It can be said that the privacy statement on some websites will be the page with the most text.
I heard yesterday that this was a bit too optimistic <img src="https://www.impresscms.org/uploads/smil3dbd4d6422f04.gif" alt="" /> , but given that the specific legal texts are still being written in Belgium, I'm not surprised by these kinds of changes.</p>
<p>I hope you and @Madfish are able to solve the encoding issue, those are always very hard to handle. PHP6 didn't happen in large part because they got lost in encoding issues.</p>