Hi, I tested the fix:
- Created View, gave it custom machine name.
- Created Viewfield, set "Always use default value" and "Set default value" to the view above.
- Export configs for field storage and field.
- Delete Viewfield.
- Clear cache.
- Import configs for field storage and field.
- All settings are there, Viewfield is displayed! 👍
Please merge!
valthebald → credited rnsrk → .
Try this. Adds a overview page by \Drupal\system\Controller\SystemController::systemAdminMenuBlockPage and assign the settings menu route to it.
This is a quite old one, you may ask in the https://chat.wiss-ki.eu/wisski/channels/town-square if anyone uses this in a project.
We do not use this kind of visualisation anymore, what Knurg means, is that if you like to have something like jit you need to develop something own.
I think in this example the disambiguation has no function and is there of legacy reasons. Disambiguation is used if you want to identify a entity via a property or entity reference routines to reuse it or link to an existing one.
If you have the field "birthplace" with the path "Person -> born -> Birth -> take place -> Place -> identified by -> Appellation" and one person is born in Chongqing and another person, too and you want to reuse the place entity called Chongqing you disambiguate in Place, then if you fill in the field birthplace "Chongqing" the entity is reused. If you want not only create new entities by one field, but have the whole form, you use Entity reference. But we have a mattermost by the way: https://chat.wiss-ki.eu If you have more support issues, you may want to join the channel https://chat.wiss-ki.eu/wisski/channels/how-to.
Did you follow these steps here: https://wiss-ki.eu/documentation/data-modeling/ontology-engineering/impo...
Hi could you please visit /admin/reports/dblog and provide the error messages with tracing information?
Done in README and add a licence-file, too.
We add primary keys to respective tables through the wisski_core/wisski_core.install patches 8010 to 8013.
Seems to work well Tom!
Mark you fixed that right?
We take the description issue to our backlog, but we fixed the deprecation warnings with the attached patch. Ether you apply the patch or pull the latest wisski dev version → .
Thanks, we discuss this. It's a little more complex, since you need a synchronisation between wisski pathbuilder options and drupal entity options.
Forget the patch, we wrote update routines, which handles to remove duplicate rows and create primary keys with commit b9336181e6906d657cc2a32d0be716c1810c9479.
I've made a patch, but we have to check it carefully, because it alters the database table definitions and add primary keys. I also removed the deprecated schema_uninstall and _install hooks, this may have site effects to older drupal versions, we have to check this for drupal 8, 9 and 10 WissKI Version to avoid crashing the database or mess up the tables! And I added ['allowed_classes' => FALSE] to the unserialize()-Method, because serialization without this option is marked as unsecure - but I'm not sure if this is the right option - so we may substitute with json_encode anyway.
Implementation in Sparql11EngineWithPB::retrieve failed, because it produced to much overhead. Functions used to add comments and labels should only used in WissKIPathForm.
First implementation with commit 041d7cd2
It may have to do with the modelling of the image inside the entity, because the image files are fetched and connected to another image entity. This may provoke conflicts with the target ids.
Perfect thank!
Removed all the version keys from sub modules with commit a6fbb84f.
Thanks a lot, WissKI has a lot of submodules, we have to search for version keys there, too before I can close the issue.