Contact_us

[heatherbell]

Anyone testing

Uploaded, go to admin>Layout>Contact Us gives;

Notice: Undefined index: Linker in //includes/languages/english/modules/pi/contact_us/cu_form.php on line 18

Fatal error: Uncaught Error: Call to a member function build() on null in //includes/languages/english/modules/pi/contact_us/cu_form.php:18 Stack trace:
#0 //includes/system/class_index.php(43): include()
#1 [internal function]: class_index->autoload('cu_form')
#2 [internal function]: spl_autoload_call('cu_form')
#3 //admin/modules_cu.php(28): class_exists('cu_form')
#4 {main} thrown in //includes/languages/english/modules/pi/contact_us/cu_form.php on line 18

[Kofod95]

Not at PC, but does $GLOBALS['Linker'] do the trick? Just to offer the help I can

//Daniel

[burt]

Try changing L5 of TPL file to;

echo sprintf(FORM_CONTACT_US_SUCCESS, $contact_us_href);

And change L18 of language file to;

define('FORM_CONTACT_US_SUCCESS', '<div class="alert alert-success"><b>Thank you.</b> Your enquiry has been sent to the Shopowner.<br><br>If you need to send us another mail, please <a class="alert-link" href="%s">click here</a>.</div>');

[heatherbell]

Try changing

Confirmed fixed, form tested and email received, all as expected.
Don't understand why the original line 18 with

Code: Select all

 href="' . $GLOBALS['Linker']->build('contact_us.php') . '"

didn't work, it looked like it should (which says a lot about my coding skill )

[ecartz]

Notice: Undefined index: Linker in //includes/languages/english/modules/pi/contact_us/cu_form.php on line 18

This says that $Linker hasn't been created yet. Presumably because the translation is loaded before Linker is created. You might also be able to work around this by replacing $GLOBALS['Linker'] with Guarantor::ensure_global('Linker'), but I think it's better to just do the printf.

[burt]

Great - so we now have a PI enabled contact_us that changes no core code. Hopefully some other PI modules get made - if anyone has any such PI modules to share, this is the thread...

Yet another good bonus for VIP members, eh?

[heatherbell]

The child modules were not going full width on small devices, that is, the same as the product_info PI, so change Line 7 in tpl_cm_cu_modular.php to be the same as https://github.com/CE-PhoenixCart/Phoen ... lar.php#L7
That is, adding in sm-
Missed that on my first test.
Took a bit of digging to find the cause but found it by comparing tpl_cm_pi_modular.php and tpl_cm_cu_modular.php
I have updated the zip in the previous post viewtopic.php?p=9709#p9709 with that change and edited the post to include the step of installing the new π Modular contact_us content_module
Perhaps somebody else can do another test on the CM Modular zip.

[heatherbell]

In core PI child module configuration, there is, for example, https://github.com/CE-PhoenixCart/Phoen ... hp#L53-L58

Code: Select all

        'PI_IMG_DISCLAIMER_CONTENT_WIDTH' => [
          'title' => 'Content Width',
          'value' => '12',
          'desc' => 'What width container should the content be shown in?',
          'set_func' => "Config::select_one(['12', '11', '10', '9', '8', '7', '6', '5', '4', '3', '2', '1'], ",
        ],

but in cu_text.php there is

Code: Select all

        'CU_TEXT_CONTENT_WIDTH' => [
          'title' => 'Content Width',
          'value' => 'col-12',
          'desc' => 'What width container should the content be shown in?',
        ],

When making a new CU PI child module, is it better to follow the core example or the CU?

[ecartz]

From a functionality standpoint, it doesn't really matter. So long as you enter a correct value, it makes no difference.

From a UX standpoint, it is probably better to use the set_func to restrict what you can select to correct values. Because you can get weird results if you enter a weird value.

Note that if you do use the set_func there, you also need to change how the width is used. Because PI_IMG prepends something like col-sm- to a number from 1 to 12. It doesn't look like the CU module does that.

[Kofod95]

One of the advantages of not using set_func is the possibility to control the breakpoint and even add multiple (col-6 col-sm-4 col-lg-3), but I agree with @ecartz, that set_func is better for UX, and commented on PRO-code not using set_func while testing it in December.

//Daniel