-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flex collection is empty when defined in theme (Call to a member function render() on null) #177
Comments
I experimented a little. It seems to be related to the Grav version. If I downgrade the core to 1.7.40, it works again. From version 1.7.41 the error occurs. |
Is this plugin still alive? Nothing happens since Jul 9! |
Not enough information to do any debugging from. |
Okay, is there something I can do to help with this? :) |
You should provide as much information as possible. What did you do for this error to occur? What plugins do you have installed? what versions are they? what version of PHP? How can I recreate? Can you provide a simple setup i can unzip and test with (this should include custom templates, blueprints, configuration, etc). I need to be able to replicate the issue exactly or I can't help you. Cheers, |
@rhukster I added a new blueprint type and before grav version 1.7.41 it works without problems. Starting with this version, blueprint is no longer found in the frontend. 404 is thrown from template After a long research it seems that the path to the theme blueprint directory is only added to the locator if the flex object plugin has already tried to add the directory to the flex object for the respective type. However, since it cannot find the blueprint, the listing in the frontend with custom blueprint types does not work. Asking the locator about the blueprint path after theme initialization is finished, produces a positive result - but it is too late for the flex object when using Flex::getDirectory(). Mentioned also in getgrav/grav#3255 (comment). |
I found the reason. Because in Changing the following value back solves the problem: title: Account
form:
validation: loose
fields:
info:
type: userinfo
size: large
avatar:
type: file
size: large
destination: 'account://avatars'
multiple: false
random_name: true
multiavatar_only:
type: conditional
condition: config.system.accounts.avatar == 'multiavatar'
fields:
avatar_hash:
type: text
label: ''
placeholder: 'e.g. dceaadcfda491f4e45'
description: PLUGIN_ADMIN.AVATAR_HASH
size: large
content:
type: section
title: PLUGIN_ADMIN.ACCOUNT
underline: true
username:
type: text
size: large
label: PLUGIN_ADMIN.USERNAME
disabled: true
readonly: true
email:
type: email
size: large
label: PLUGIN_ADMIN.EMAIL
validate:
type: email
message: PLUGIN_ADMIN.EMAIL_VALIDATION_MESSAGE
required: true
password:
type: password
size: large
label: PLUGIN_ADMIN.PASSWORD
autocomplete: new-password
validate:
required: false
message: PLUGIN_ADMIN.PASSWORD_VALIDATION_MESSAGE
config-pattern@: system.pwd_regex
fullname:
type: text
size: large
label: PLUGIN_ADMIN.FULL_NAME
validate:
required: true
title:
type: text
size: large
label: PLUGIN_ADMIN.TITLE
language:
type: select
label: PLUGIN_ADMIN.LANGUAGE
size: medium
classes: fancy
data-options@: '\Grav\Plugin\Admin\Admin::adminLanguages'
default: 'en'
help: PLUGIN_ADMIN.LANGUAGE_HELP
content_editor:
type: select
label: PLUGIN_ADMIN.CONTENT_EDITOR
size: medium
classes: fancy
data-options@: 'Grav\Plugin\Admin\Admin::contentEditor'
default: 'default'
help: PLUGIN_ADMIN.CONTENT_EDITOR_HELP
twofa_check:
type: conditional
condition: config.plugins.admin.twofa_enabled
fields:
twofa:
title: PLUGIN_ADMIN.2FA_TITLE
type: section
underline: true
twofa_enabled:
type: toggle
label: PLUGIN_ADMIN.2FA_ENABLED
classes: twofa-toggle
highlight: 1
default: 0
options:
1: PLUGIN_ADMIN.YES
0: PLUGIN_ADMIN.NO
validate:
type: bool
twofa_secret:
type: 2fa_secret
outerclasses: 'twofa-secret'
markdown: true
label: PLUGIN_ADMIN.2FA_SECRET
sublabel: PLUGIN_ADMIN.2FA_SECRET_HELP
yubikey_id:
type: text
label: PLUGIN_ADMIN.YUBIKEY_ID
description: PLUGIN_ADMIN.YUBIKEY_HELP
size: small
maxlength: 12
security:
security@: admin.super
title: PLUGIN_ADMIN.ACCESS_LEVELS
type: section
underline: true
fields:
groups:
security@: admin.super
type: select
multiple: true
size: large
label: PLUGIN_ADMIN.GROUPS
- data-options@: 'Grav\Common\Flex\Types\UserGroups\UserGroupObject::groupNames'
+ data-options@: '\Grav\Common\User\Group::groupNames'
classes: fancy
help: PLUGIN_ADMIN.GROUPS_HELP
validate:
type: commalist
access:
security@: admin.super
type: permissions
check_authorize: true
label: PLUGIN_ADMIN.PERMISSIONS
ignore_empty: true
validate:
type: array
value_type: bool Also, I was able to dirty-fix it in the template: {% set flex = grav.get('flex_objects') %}
+ {# fixed bug https://github.com/trilbymedia/grav-plugin-flex-objects/issues/177 #}
+ {% do flex.addDirectoryType('projects', 'blueprints://flex-objects/projects.yaml') %}
{% set directory = flex.directory(type) %} |
I don't remember why i changed this now.. reveverted until I can work out why it was changed and what the proper fix would be. |
Can confirm it works again with grav v1.7.44. |
Hello together,
after updating to flex objects 1.3.5 I got the following error when opening pages with flex collections:
My blueprint is defined in theme and is listed in plugin settings and activated. The flex objects are shown in admin and can be maintained there without any problems.
In my template I want to render the collection layout:
But
grav.get('flex').collection('coaches')
is alwaysnull
. It works when moving the flex-objects to user directory.The text was updated successfully, but these errors were encountered: