CMS Made Simple Forums

Ah yes, you need PHP 7.4 to run the most recent versions of CMSMSExt, MAMS, etc. Even CMSMS will require PHP 7.4 as a minimum in next release. We are trying to have everything ready for at least PHP 8.0 as fast as we can, if not PHP 8.1 right away. However at that point we'll have to motivate 3rd pa...

rooon wrote: ↑Wed Oct 12, 2022 9:32 am During installation of CMSMSExt (required for the MAMS module) there were errors.

Can you please elaborate? thx

I would use the form validation UDT option: Validation UDT. Set this for a form, and the UDT will receive all of the form's human-readable results. The UDT should do whatever validation it wants, and return an array with the first value being true or false (indication whether the form validates), an...

Don't forget to eval whenever the content is not originally parsed by Smarty.

Which version of FEU do you have installed? MAMS assumes FEU is 2.14.3.4, and it won't support FEU 3.x versions which are totally different and buggy. Also older versions than 2.14.3.4 may not have the required data structure for the import. Typically MAMS importer assumes FEU tables don't have mean...

That's exactly right!

As long as there is someone logged in in the backend, yes, there are a few debug_to_log calls that may still be active in the core and possibly in other 3rd party modules that will create entries for those specific users both in frontend and backend actions. The config entry only affects frontend ac...

At the moment the only working Forums module is JM_Forums, but it only works with FEU. There is a fork in the works that will integrate with MAMS and will import data from old JM_Forums. I don't have a release date yet as a few other projects took precedence but I expect to have a release in a month...

("Civilités" /{$civilit__s}) That would be Civilités = {$civilites} :) only the spaces are replaced by underscores, and diacritics are just removed or, if you will, replaced by their correspondent base character. Just as a note if the alias conflicts with the auto generated one, it won't ...

Actually {$fbrp__....} should work too, I just double checked... This mode of operation is not great. For languages ​​with accents, if there is a special character in the field name... I don't know what this implies in terms of development, but being able to access the field via $fld_x ​​would be mu...

try {$testform->required} or {$fld_29->required}... {$fbrp__....} was a typo from copy and pasting... my bad.

The standard form "Contact Form" seem's to perfectly works. It keeps data when submited with an error (requested or validation) and back to the form. I'm probably making a huge mistake in my template. I do not see... Or in the form settings? So, back to the basics: validate the rendered f...

A snippet from an old form I have, just changed the field variable to match yours: <div class="form-group {if $fb_form_has_validation_errors|default:false} {if $fbrp__37->valid}has-success{else}has-error{/if}{/if}"> <label for="{$fbrp__37->alias}">label here {if $fbrp__37->requir...

DIGI3 got it right although with a typo on one of the examples that might have mislead you... So objects have a syntax like $myfieldname->property_i_want_to_use. So $fbrp__28->required should work.

I suspect it may be something specific to your server PHP environment. I use UDTs all the time and, of course, make mistakes all the time. I work in many different server environments and never had the whole site down on account of an error on a UDT and not with one not being used in any page. Maybe...