Just for the record, this is very similar to pimcore/pimcore#4476, but we have never used any translations at all. It might not be a Data-hub issue at all. That said, after upgrading from 5.8.4 to 6.0 everything in Pimcore and Data-hub seems to be working fine, with the exception of actually running queries, which throws this error, either with the graphical interface or direct queries from simpler clients like Curl.

While that issue gave me some ideas where to look for the source of the error I can't find it.

There are also other related errors, like Monolog throws error 'info' severity is not supported, etc.

While trying to debug I noticed that locale_get_default() returned tr_TR, but System Settings said that en was the only and default Pimcore language (no fallback). And PHP Info's intl.default_locale reports en

Clearing all the caches and resetting the System Settings does not help. Any ideas what might have happened?

Stack trace:

Psr\Log\InvalidArgumentException:
Level "info" is not defined, use one of: 100, 200, 250, 300, 400, 500, 550, 600

  at vendor/monolog/monolog/src/Monolog/Logger.php:516
  at Monolog\Logger::getLevelName('info')
     (vendor/monolog/monolog/src/Monolog/Logger.php:298)
  at Monolog\Logger->addRecord('info', 'User Deprecated: The Symfony\\Bundle\\FrameworkBundle\\Templating\\Helper\\ActionsHelper class is deprecated since version 4.3 and will be removed in 5.0; use Twig instead.', array('exception' => object(ErrorException)))
     (vendor/monolog/monolog/src/Monolog/Logger.php:609)
  at Monolog\Logger->log('info', 'User Deprecated: The Symfony\\Bundle\\FrameworkBundle\\Templating\\Helper\\ActionsHelper class is deprecated since version 4.3 and will be removed in 5.0; use Twig instead.', array('exception' => object(ErrorException)))
     (vendor/symfony/symfony/src/Symfony/Component/Debug/ErrorHandler.php:503)
  at Symfony\Component\Debug\ErrorHandler->handleError(16384, 'The Symfony\\Bundle\\FrameworkBundle\\Templating\\Helper\\ActionsHelper class is deprecated since version 4.3 and will be removed in 5.0; use Twig instead.', '/var/www/pimcore/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Templating/Helper/ActionsHelper.php', 14, array('class' => 'Symfony\\Bundle\\FrameworkBundle\\Templating\\Helper\\ActionsHelper', 'e' => 22519, 'file' => '/var/www/pimcore/vendor/composer/../symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Templating/Helper/ActionsHelper.php'))
  at trigger_error('The Symfony\\Bundle\\FrameworkBundle\\Templating\\Helper\\ActionsHelper class is deprecated since version 4.3 and will be removed in 5.0; use Twig instead.', 16384)
     (vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Templating/Helper/ActionsHelper.php:14)
  at require('/var/www/pimcore/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Templating/Helper/ActionsHelper.php')
     (vendor/symfony/symfony/src/Symfony/Component/Debug/DebugClassLoader.php:156)
  at Symfony\Component\Debug\DebugClassLoader->loadClass('Symfony\\Bundle\\FrameworkBundle\\Templating\\Helper\\ActionsHelper')
  at spl_autoload_call('Symfony\\Bundle\\FrameworkBundle\\Templating\\Helper\\ActionsHelper')
     (var/cache/dev/ContainerWeY7xTr/appAppKernelDevDebugContainer.php:3197)
  at ContainerWeY7xTr\appAppKernelDevDebugContainer->getTemplating_Helper_ActionsService()
     (var/cache/dev/ContainerWeY7xTr/appAppKernelDevDebugContainer.php:1565)
  at ContainerWeY7xTr\appAppKernelDevDebugContainer->getPimcore_Templating_ActionRendererService()
     (var/cache/dev/ContainerWeY7xTr/getDocumentRendererService.php:9)
  at require('/var/www/pimcore/var/cache/dev/ContainerWeY7xTr/getDocumentRendererService.php')
     (var/cache/dev/ContainerWeY7xTr/appAppKernelDevDebugContainer.php:408)
  at ContainerWeY7xTr\appAppKernelDevDebugContainer->load('getDocumentRendererService.php')
     (var/cache/dev/ContainerWeY7xTr/getResponseExceptionListenerService.php:9)
  at require('/var/www/pimcore/var/cache/dev/ContainerWeY7xTr/getResponseExceptionListenerService.php')
     (var/cache/dev/ContainerWeY7xTr/appAppKernelDevDebugContainer.php:408)
  at ContainerWeY7xTr\appAppKernelDevDebugContainer->load('getResponseExceptionListenerService.php')
     (var/cache/dev/ContainerWeY7xTr/appAppKernelDevDebugContainer.php:1098)
  at ContainerWeY7xTr\appAppKernelDevDebugContainer->ContainerWeY7xTr\{closure}()
     (vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/EventDispatcher.php:275)
  at Symfony\Component\EventDispatcher\EventDispatcher->sortListeners('kernel.exception')
     (vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/EventDispatcher.php:92)
  at Symfony\Component\EventDispatcher\EventDispatcher->getListeners('kernel.exception')
     (vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/Debug/TraceableEventDispatcher.php:334)
  at Symfony\Component\EventDispatcher\Debug\TraceableEventDispatcher->preProcess('kernel.exception')
     (vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/Debug/TraceableEventDispatcher.php:162)
  at Symfony\Component\EventDispatcher\Debug\TraceableEventDispatcher->dispatch(object(ExceptionEvent), 'kernel.exception')
     (vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php:222)
  at Symfony\Component\HttpKernel\HttpKernel->handleException(object(InvalidArgumentException), object(Request), 1)
     (vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php:79)
  at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), 1, true)
     (vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Kernel.php:198)
  at Symfony\Component\HttpKernel\Kernel->handle(object(Request))
     (web/app.php:36)

The intention should be quite clear: It should be possible to inject whatever I want to those operators.

https://github.com/pimcore/data-hub/tree/37f79ad6b027a83d26521290fa3b96c56288dd6a/src/Pimcore/Bundle/DataHubBundle/GraphQL/Query/Operator

We would like to continue improving this bundle, but to avoid doing duplicate work, could you tell us if any work has been done on either Structured: Field-Collections or Media: Image Gallery object data components?

The intention should be quite clear: It should be possible to inject whatever I want to those resolvers.

https://github.com/pimcore/data-hub/tree/db4379af8ac087b9f063437d3b388c86c4ba2442/src/Pimcore/Bundle/DataHubBundle/GraphQL/Resolver

Using

pimcore/pimcore v5.7.3
pimcore/data-hub dev-master 0d578c1 Pimcore Data Hub - Early Preview
, no matter how simple my configuration, the graphQL window opens without any content, just the commented out window.

When running tests, it might be possible that this doesn't work since the Kernel will be set later during the init of the test suite.

Move those EventHandlers to services directly.

https://github.com/pimcore/data-hub/blob/master/src/Pimcore/Bundle/DataHubBundle/PimcoreDataHubBundle.php#L40

$document->getElement

Summary

When querying for an Object with an image field the query returns null for the asset unless the Client Query also requests the ID of the object.

Expected

I expect to be able to get the mainImage Asset data even though I do not include id in the Client Query.

To reproduce

This works:

{
  getProductListing {
    edges {
      node {
        id
        mainImage {
          fullpath
        }
      }
    }
  }
}

But this does not:

{
  getProductListing {
    edges {
      node {
        mainImage {
          fullpath
        }
      }
    }
  }
}

When querying against a configuration that does not exists, this will throw a 500 Internal Server Error: Return value of Pimcore\Bundle\DataHubBundle\Configuration::getByName() must be an instance of Pimcore\Bundle\DataHubBundle\Configuration, null returned

Maybe return a 404 error instead?

With the update to Pimcore 6 the getChilds() methods and childs attributes (among some other) have changed to the more proper children. Doing the same here would be nice,

I'm preparing a PR.

Overall, remove the usage of the global container. This is considered to be an anti pattern and only is in Pimcore for special legacy reasons.

• Some of the calls are inside containers that could be replaced with action-arguments or $this->get calls. ($this->get will also break in Symfony 4 when the service is private, but its still more symfony like)
• Some others are in resolvers, types and operators. Those should be created using the Symfony Container and could be registered in some sort of Registry Class.

Pimcore will sooner or later upgrade to Symfony 4 and further remove legacy stuff. So, usage of that function should only be when there is absolutely no chance otherwise. I don't see that here.

These classes shouldn't even know that there is something like a container.

Don't get me wrong please, this bundle is great, it works amazingly good. But: New code should be created in a form that is not legacy, in a form that is maintainable, sticks to current patterns and doesn't rely on any legacy stuff.

Example: add field description only if in debug mode

@weisswurstkanone Do you have any internal progress on this? We are considering starting on this feature because we have a use case for it.

Issue:
Object of type A contains an advanced many to many-relation with object of type B.

You make a data-hub config for type A and you want to display some info of type B.

{
  getA (id: 1){
    id,
    b {
      ... on object_B {
        id
      }
    }
  }
}

This results in the error "type definition B not found". You get this error even without requesting any info of object B.

I found \Pimcore\Bundle\DataHubBundle\GraphQL\ClassTypeDefinitions::build to be partly responsible. In that method the classes are loaded alphabetically, first class A, then class B. However, class A has a reference to class B, so it executes \Pimcore\Bundle\DataHubBundle\GraphQL\ClassTypeDefinitions::get with "B" as parameter, but at that moment, class B isn't loaded yet, so it throws the error.

This is not the case with simple many-to-one fields. In that case, all the classes are loaded before the get() method gets executed.

This screenshot contains a real life example. Class "Dealer" (A) has a reference to "Order" (B). Dealer gets loaded in the build() foreach-loop, then jumps to the get() method to collect Order, which at that time isn't loaded yet, because the foreach-loop in build() is still processing "Dealer".

Hope this is clear :)

Today the only way(?) that we can use filtering is via Filter Listings, however, I would like to move these filters into Query variables, like this:

query news(published: Boolean, $first: Int, $filter: Filter) {
    ...
}
variables: {
    "published": true,
    "first": 5,
    "filter": What goes here?
}

However, I can't figure out how to do it and I have come to the conclusion that it is probably not possible with today's solution, is it because the dollar sign?

Steps to reproduce

1. Create a new Image Thumbnail
2. Define at least one breakpoint.
3. Run a client query against the thumbnail field.

Expected result

To either be able to get an entire <img srcset...> tag or an array with data objects representing the different image objects (which may include the different paths).

Actual result

I get the path to one of the thumbnails only.

• create objects

• update objects (support a few datatypes and operators)

• delete objects

• create/read/update/delete assets (at least data + filename)

• create/read/update/delete asset & object folders

... only data objects that are in folders.

e.g. see category listing in demo-advanced

Summary

The Link type data field on Objects does not work when it has data. If the field is empty on an object it will return null as expected, but if there is some link content (text+url) then the server will throw an UndefinedMethodException.

To reproduce

1. Create an object class.
2. Add the Other: Link data component.
3. Create an object of the class, but leave the link empty when saving.
4. Query for the object in GraphiQL, note the result.
5. Fill in some data in the object's link field and save it.
6. Run the query again, you should now get an error.

Attempted to call an undefined method named "resolveText" of class "Pimcore\Bundle\DataHubBundle\GraphQL\Resolver\Link"

Question

Did Geopoint and Link get mixed up? In that case I have a commit here 😄

There are no code comments or clear documentation I can find on the totalCount Schema.

For example, the query:

query categories($first: Int) {
  getCategoryListing(first: $first, published: false) {
    totalCount
    edges {
      node {
        fullpath
      }
    }
  }
}

with query variables:

{
  "first": 3
}

returns:

{
  "data": {
    "getCategoryListing": {
      "totalCount": 29,
      "edges": [
        {
          "node": {
            "fullpath": "/Categories/Hage"
          }
        },
        {
          "node": {
            "fullpath": "/Categories/Landbruk"
          }
        },
        {
          "node": {
            "fullpath": "/Categories/Maskiner"
          }
        }
      ]
    }
  }
}

The number 29 is correct so far as to the total number of Category objects, but not the number of returned objects. Is this the expected behaviour: To show the total query-able number of data objects. Or should it calculate the number of returned objects?

The description is a bit sparse at the moment:

https://github.com/pimcore/data-hub/blob/master/src/GraphQL/Query/QueryType.php#L188

First, thanks for this bundle it will be a great feature for pimcore !

Is it possible to add Access-Control-Allow-Origin in order to test on local frontend dev ?

maybe
preQuery + postQuery
preMutate + postMutate

see https://pimcore.com/docs/5.x/User_Documentation/DataObjects/Grid_Configuration_Operators/Operators/TranslateValue.html

When defining the Graph QL schema it is possible to add panels to the queyable fields, this has no detrimental effect (that I can find) but they should not be able to de added to the query definition.

The creates mutations are not working, this is due to a mistake in the class Pimcore\Bundle\DataHubBundle\GraphQL\Mutation\MutationType on line 186

replace :
call_user_func_array($resolver, [ $newInstance, $value, $args, $context, $info]);

By

call_user_func_array($resolver, [ $value, $args, $context, $info]);

Maybe a bug?

When I'm creating an image field in the Schema called mainImageThumbnail I noticed that it became mainimagethumbnail.

There is likely a good reason for this, but it is a bit odd when creationDate, and some other fields can retain their camelcasing.

"Main Image Thumbnail" → "main_image_thumbnail" works (I personally prefers snakes, but our coding style asks for camels, which is why I ask)

Key should already contain brickname.

Maybe a place to look at: