statamic
Root nav items don't return custom field data
Bug description
I don't seem to get any navigation blueprint data returned in Antlers for root items. It does seem to work for children (in my case).
tree:
-
id: c818add2-f657-474b-ae28-fa4cec914bc2
title: Follow
data:
contents: social_media
{{ nav:footer max_depth="2" select="contents|title|url" }}
{{ contents | dump }}
This dumps nothing. Only the Title and URL are available. The data also isn't available when I remove the select attribute. When I dump the whole nav I don't see the data:
How to reproduce
Create a nav with custom fields Add root items with custom fields filled in Request it in Antlers
Logs
No response
Environment
Environment
Laravel Version: 11.7.0
PHP Version: 8.2.19
Composer Version: 2.7.6
Environment: local
Debug Mode: ENABLED
Maintenance Mode: OFF
Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED
Drivers
Broadcasting: log
Cache: statamic
Database: sqlite
Logs: stack / single
Mail: smtp
Queue: sync
Session: file
Livewire
Livewire: v3.4.12
Statamic
Addons: 8
Sites: 1
Stache Watcher: Enabled
Static Caching: Disabled
Version: 5.1.0 PRO
Statamic Addons
jacksleight/statamic-bard-mutator: 2.3.1
jonassiewertsen/statamic-livewire: 3.3.1
rias/statamic-color-swatches: 2.3.0
stillat/relationships: 2.2.0
studio1902/statamic-peak-browser-appearance: 3.4.0
studio1902/statamic-peak-commands: 8.3.0
studio1902/statamic-peak-seo: 8.13.2
studio1902/statamic-peak-tools: 6.0.0
Installation
Starter Kit using via CLI
Additional details
Possibly related to #10055
Hi @josor001, thanks for the bug report. As far as I'm concerned, this fork of @mmitas777 does the version and dependency lifting, at least up to the Live Validation project, right? We only lack the lifting for the following projects, correct?
(Snippet taken from https://github.com/SeelabFhdo/lemma/blob/main/build/lemma-build-modules.txt)
# UI Components
de.fhdo.lemma.eclipse.ui.parent
de.fhdo.lemma.data.datadsl.ui
de.fhdo.lemma.data.datadsl.ui.tests
de.fhdo.lemma.technology.technologydsl.ui
de.fhdo.lemma.technology.technologydsl.ui.tests
de.fhdo.lemma.servicedsl.ui
de.fhdo.lemma.servicedsl.ui.tests
de.fhdo.lemma.technology.mappingdsl.ui
de.fhdo.lemma.technology.mappingdsl.ui.tests
de.fhdo.lemma.operationdsl.ui
de.fhdo.lemma.operationdsl.ui.tests
de.fhdo.lemma.model_processing.eclipse.launcher.parent
# Other Transformations
de.fhdo.lemma.data.avro.parent
de.fhdo.lemma.service.openapi.parent
# OCL
de.fhdo.lemma.ocl
# Model Processing Framework
de.fhdo.lemma.model_processing
de.fhdo.lemma.model_processing.utils
examples/model-processing
# Code Generators
code generators/de.fhdo.lemma.ddd
code generators/de.fhdo.lemma.msa
code generators/de.fhdo.lemma.model_processing.code_generation.java_base
code generators/de.fhdo.lemma.model_processing.code_generation.ddd
code generators/de.fhdo.lemma.model_processing.code_generation.springcloud
code generators/de.fhdo.lemma.model_processing.code_generation.springcloud.domain_events
code generators/de.fhdo.lemma.model_processing.code_generation.springcloud.cqrs
code generators/de.fhdo.lemma.model_processing.code_generation.springcloud.kafka
code generators/de.fhdo.lemma.model_processing.code_generation.deployment_base
code generators/de.fhdo.lemma.model_processing.code_generation.mariadb
code generators/de.fhdo.lemma.model_processing.code_generation.mongodb
code generators/de.fhdo.lemma.model_processing.code_generation.springcloud.zuul
code generators/de.fhdo.lemma.model_processing.code_generation.springcloud.eureka
# Analyzer
de.fhdo.lemma.analyzer.lib
de.fhdo.lemma.analyzer
Or were some of these also lifted already, @mmitas777?
In any case, I'm happy to take a first PR of https://github.com/mmitas777/lemma/tree/eclipse-version-upgrade, thanks!
If I remember correctly, he was stuck with the live validation part and wanted to finish his master thesis first (should be done in 2-3 weeks), i.e., we could hope that @mmitas777 solves the issue in the coming weeks ;-)
@frademacher Just as a quick clarification. Currently we have a somehow unofficial policy that all lemma eclipse plug-ins operate on the same eclipse and tycho versions. Would it be beneficial for the future to allow different eclipse and tycho versions in the lemma project? For example, I'm flirting with the idea to update the OpenAPI stuff again. During that step, I could also try to lift the tycho version etc. I'm not rly familiar with the hidden pitfalls of the whole eclipse build process, could it happen that the build gets unstable when we allow different versions?
Sure, no rush here :-) I also completely forgot about the Live Validation build problem. Maybe @mmitas777 could describe and document the problem in this issue so that I can have a deeper look at it and know where the concrete pitfalls lurk.
@josor001, sure go ahead. If a new Tycho version works for the OpenAPI plugin, then it should probably also work for all other plugins. However, it might be the case that the current Tycho version 4.0.3 now also concentrates on Java 17. In this case, we would probably require an update to all plugins on which OpenAPI depends. Feel free to perform those updates (on the required plugins and maybe using https://github.com/mmitas777/lemma/tree/eclipse-version-upgrade as "inspiration") and open a PR when this has been done. I'd then wait for the update PR of @mmitas777 (probably after the issues with the Live Validation plugin got fixed) and distill a single commit from both PRs, of course mentioning both of you as authors.
Update: I forgot to mention that the update of the OpenAPI plugin is highly appreciated, @josor001 :-)
Did some experiments today regarding a partial update of the tycho version. As it turns out, Tycho >=version 2.7 is somewhat incompatible with lesser tycho versions (<2.7) in the same build. Apparently, there is some bad metadata written to the local m2 repository that confuses tycho build with version <2.7. see bug report
This means that we have to lift all projects in one step. A pity :-(
Concerning the Eclipse version: If we do not want to keep the Java version at 11, we should settle for Eclipse 2022-06 which apparently is the LTS for Java11.
Hi there, @josor001 and @frademacher! I got the build problems on my ARM Mac (M1) during my master thesis researches. As far as I could test it, the LEMMA build has issues beginning at the first build module when using the Eclipse 2021-03 version. I tried to upgrade the Eclipse version to 2023-06 (maybe an update to the current 2023-09 version won't effect my current tests), the Java version to 17, Tycho to 4.0.2 and dependencies to current versions. I did the tests two months ago, so the versions might not be the newest anymore.
This went fine (see https://github.com/mmitas777/lemma/tree/eclipse-version-upgrade till the Live Validation project. Problem is that it uses maven as a dependent plugin in several files, which is not supported at Gradle 7.x anymore (i.e. see https://docs.gradle.org/current/userguide/upgrading_version_6.html#removal_of_the_legacy_maven_plugin). Gradle 8.x leads to more problems in this project and the following gradel build modules due to major syntax changes in the build file. As I don't know how to fix it without modifying the modules too much, I ask you, @frademacher, @josor001 and @pwizenty, for looking over your model processing, OpenAPI, Live Validation and Model Reconstruction projects.
@josor001, I also tried to use different tycho versions, even versions 2.3 and 2.6. Problem is that different tycho versions generally lead to dependency resolution problems (modules surprisingly not found, dependencies downloaded to other folders so that following module builds can't find the dependencies anymore,...).
Of course I could do a PR of my branch to the main LEMMA repo, but of course the version lifting is still in progress.
