1

Immediately after upgrading my Joomla version from 3.9.1 to 3.9.4, I can no longer access certain Simple CRM submenus in the backend.

enter image description here

The Company Codes link works properly.
(http://localhost/jdem02/administrator/index.php?option=com_gscrm&view=Codes)

The following do not:

  • Simple CRM
    (http://localhost/jdem02/administrator/index.php?option=com_gscm)

  • User Management
    (http://localhost/jdem02/administrator/index.php?option=com_gscrm&view=Beads)

  • User Roles
    (http://localhost/jdem02/administrator/index.php?option=com_gscrm&view=Roles)

  • Currencies & Rates
    (http://localhost/jdem02/administrator/index.php?option=com_gscrm&view=Currencies)

They all generate the same error:

0 Call to a member function getModel() on null
C:\wamp64\www\jdem02\libraries\fof30\Form\Field\Numeric.php:25

So who moved my cheese?

How do I fix this?

p.s. I am not interested in lowering my Joomla version.

Update:

This is my administrator/components/com_gscrm/View directory structure:

enter image description here

Here is the Roles form.default.xml script:

<?xml version="1.0" encoding="UTF-8"?>
<form type="browse" 
    show_header="1" 
        show_filters="1" 
            show_pagination="1" 
                norows_placeholder="COM_GSCRM_COMMON_NORECORDS">
  <headerset>
    <header name="gscrm_role_id" type="RowSelect" label="COM_GSCRM_ROLES_GSCRM_ROLE_ID_LABEL" />
    <header name="role_id" label="COM_GSCRM_ROLES_GSCRM_ROLE_ID_LABEL" description="COM_GSCRM_ROLES_GSCRM_ROLE_ID_DESC"/>         
    <header name="title" type="Searchable" label="COM_GSCRM_ROLES_TITLE_LABEL"/>
    <header name="parent" label="COM_GSCRM_ROLES_PARENT_LABEL" sortable="true"/>
    <header name="child" label="COM_GSCRM_ROLES_CHILD_LABEL" sortable="true"/>
    <header name="code" type="Searchable" label="COM_GSCRM_ROLES_CODE_LABEL" sortable="true"/>
    <header name="enabled" type="Published" label="COM_GSCRM_ROLES_ENABLED_LABEL" sortable="true"/>
    <header name="access" type="AccessLevel" label="COM_GSCRM_ROLES_ACCESS_LABEL" sortable="true"/>
  </headerset>

  <fieldset name="items">
    <field name="gscrm_role_id" type="SelectRow"/>
    <field name="gscrm_role_id" id="role_id" type="text"/>

    <field name="title" type="Sortable" url="index.php?option=com_gscrm&amp;view=Role&amp;id=[ITEM:ID]&amp;[TOKEN]=1"/>

    <field name="parent" type="Numeric"/>
    <field name="child" type="Numeric"/>

    <field name="code" type="ViewTemplate" emptylabel="1" 
                        source="admin:com_gscrm/Beads/Code_name" 
    />  
    <field name="enabled" type="Actions"/>
    <field name="access" type="AccessLevel"/>
  </fieldset>
</form>
|improve this question
  • It looks like that the numeric form field in fof has some issue that has been noticed in the code: * Backwards compatibility field. DO NOT USE IN PHP 7.2 AND LATER. Here is the file: github.com/akeeba/fof/blob/development/fof/Form/Field/…. - I did not check this deeper but I think we look at the same file here. It also looks like that the Form object is null at this point in the code, thus the error is generated. – Zollie Apr 9 at 8:36
  • SimpleCRM will have to use number field instead of numeric, according to the above file, so they will have to update. This is what I see in that at a glance. – Zollie Apr 9 at 8:41
  • Here is what I find odd. While using php7.2.12 with Joomla3.9.1 -- no problem. While using php7.2.12 with Joomla3.9.4 -- four of five links go bonk. Where is the consistency? How is the Codes url magically working when all the rest fail? Does this indicate a db annormality? What might I investigate? and in which tables? – mickmackusa♦ Apr 9 at 10:08
  • More or less I see your point. The Codes url points to a view where you will not find a Form including numeric form field, the other 3 link points to views which includes a form with numeric form fields. That is causing the same error message on those 3 links and views. This is how I see it from what you shared. All of the problematic 3 views have to have an xml form file also where those numeric form fields are defined. Those form numeric fields should be changed to number type fields in those xmls. I cannot check this from here of course, but this is what I see from the given info. – Zollie Apr 9 at 12:23
  • I think you are onto it. In the morning, I'll investigate these files and check for something that looks like numeric form fields. If this turns out to be true, I'll offer new/specific details so that you can post an answer. Thank you. – mickmackusa♦ Apr 9 at 12:40
1

This question (problem) was successfully and quite quickly solved yesterday, working effectively together with @Mick on the solution. And this question is very well detailed, well described and it included the exact error message from Joomla, so it is a good example of a well-built question on SE.

The solution was relatively simple: we had to change the deprecated numeric type form field to number type form field in the XML files where these fields are defined in Joomla and in FOF too.

At form field definitions using type=”number” instead of type=”numeric” solved the problem quite straightforwardly.

Short description about the problem and solution:

The error message displayed two important things: 1. which file the error occurred in (at which line exactly) 2. And it also made obvious that the component is built with using FOF (Framework on Framework), with classes found in fof30 library in Joomla 3 .

When we open the particular file noticed in the error message, we find that file would be about constructing a form field and we can also see immediately that the field is deprecated with a message:

Backwards compatibility field. DO NOT USE IN PHP 7.2 AND LATER.

And with an added note: @deprecated 3.1

If you then check the fof30 library, you will find that the fof version number now is: 3.4.2.

Finally, we can also find a very helpful message in the file, thanks to the creator of FOF: “…Use the number field type instead.”

Thus in this numeric field class, the field fails to be constructed, but if you change the form field type to number in the corresponding XML files where the form and fields are built, then the problem should be solved. And it was so actually. One of the problematic XML file regarding the above explanation was also included by @Mick as an update of the question.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.