for me your post is also somewhat opaque.
It helps others to answer questions when more information is provided than a complaint and written frustration.
So my usual first question: what are you actually trying to do?
A new page nodetype with its own layout?
A new layout variant for the same page type?
What is the exact problem you have?
How for did you come?
Are there errors or stuff is just not happening?
Do you have a code example we can look at?
ok yes, sorry, i am frustrated, you´re right
Currently I’m also learning View-JS and Laravel and they do have really good documentations.
But the NEOS-Doks are really not made for NESO-beginners. The videos also not.
So i played alot around and watched a bunch of videos, but I don’t understand a lot of shown things there. And it´s hard for me to explain my siuation in english at this point.
As I understood, I try to add a new page nodeType.
And NOW, I’m a big step further and it seems to work now:
It’s a lot of stuff for beginners I know. I do coaching/training for individuals and teams and initially they always struggle a bit, but after a few sessions they all really appreciate what Neos has to offer in those regards.
As our best practises are “alive” some of the docs and videos are already “old” and don’t reflect anymore what you might encounter in the code.
So the “constraints” are there to define what editors can later add to certain areas.
For example the generic page could have as childNode constraint something like “Constraint.Document.Page”.
And the same or other pages types now inherit from “Constraint.Document.Page”.
Now an editor can add those pagetypes as subpages to the generic page.
The same works for content etc. So this way the concept what nodetypes are allowed where is much more flexible and easier to maintain than how we did it in the past where you had to define each and every nodetype in the childnode constraint.
For that to work those “constraint” nodetypes don’t need anything besides being marked as “abstract”.
The abstract page type is meant to be inherited by other page types but also provides its own rendering that the other types can inherit from in Fusion. That makes it different from a mixin which doesn’t provide its own rendering in Fusion. So more or less a naming convention.
So in the HomePage you should see that in inherits from AbstractPage and probably one of the constraints (I never looked at the Skeleton distribution in detail).
Hope that already helps a bit.
Btw. you can also ask questions in German in the D-A-CH Slack channel or here in the matching category if that’s easier for you.
Me and others also provide (paid) training. That probably would speed things up a bit initially.
I’m currently collecting the most common topics/questions in my trainings to create some new documentation & videos as soon as private and project pressure allows again.