Just updated Craft to latest 3.3.3 from 3.0 (non GraphQL). Enabled entries and categories in Public Schema. When I go to /admin/graphql the explorer it says:
NO SCHEMA AVAILABLE
and
{
"error": "Something went wrong when processing the GraphQL query."
}
I see that my public schema is selected in the list and its enabled.
If I just press play with no query it says:
{
"errors": [
{
"message": "Syntax Error: Unexpected <EOF>",
"category": "graphql",
"locations": [
{
"line": 1,
"column": 1
}
]
}
]
}
And yes, the documentation explorer is blank. I've tried other Craft setup and they worked fined with GraphQL, but I have only tried with 3.3.0.1.
In the console I have 2 errors
500 - Failed to load resource - /actions/graphql/api
However, when I downgrade to Craft Pro 3.3.0.1 I get totally different error and Admin locks up.
Call to undefined method craft\helpers\Stringy::langSpecificCharsArray()
in /source/vendor/craftcms/cms/src/helpers/Stringy.php (line 32)
30 public static function getLangSpecificCharsArray(string $language = 'en'): array
31 {
32 return static::langSpecificCharsArray($language);
33 }
source/vendor/craftcms/cms/src/helpers/StringHelper.php at line 135 – craft\helpers\Stringy::getLangSpecificCharsArray('en')
source/vendor/craftcms/cms/src/web/assets/cp/CpAsset.php at line 254 – craft\helpers\StringHelper::asciiCharMap(true, 'en')
From what I can tell in composer voku/stringy downgrades to 5.1.1 when installing Craft 3.3.3, why is that?
Removing voku/stringy (5.2.0)
Installing voku/stringy (5.1.1)
Hmm. The two problems together may give a hint here. As basis, I can say that where I'm running an even newer version of Craft/graphql via composer, it's working well, and so have older ones.
What I would suggest is to delete your /vendor folder entirely, and with this, /composer.lock.
Then do a composer install, and make sure the /vendor is uploaded to your server if that is on a development environment. This should align component versions directly, for the Craft version your current composer.json is naming.
Reasons:
At this point I don't know if this is an issue with Craft's own dependencies -- they'll have to work that out if so, but we can hope this gets you operating again for now.
I tried to clean composer cache, remove .lock and run composer update again. Always voku/stringy 5.1.1. So no change there.
If I try to do a manual update (5.2.0) for voku/stringy I get
Your requirements could not be resolved to an installable set of packages.
Problem 1
- craftcms/cms 3.3.3 requires voku/stringy ~5.1.0 -> no matching package found.
- craftcms/cms 3.3.3 requires voku/stringy ~5.1.0 -> no matching package found.
- craftcms/cms 3.3.3 requires voku/stringy ~5.1.0 -> no matching package found.
- Installation request for craftcms/cms == 3.3.3.0 -> satisfiable by craftcms/cms[3.3.3].
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting
see <https://getcomposer.org/doc/04-schema.md#minimum-stability> for more details.
Read <https://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.
I updated another site from 3.3.0.1 to 3.3.3 and the same thing happen to graphql. It might be PHP related on our server since its old and refusing to update some packages beacuse of the required php version.
Hmm, yes, I was going to suggest composer clearcache before you did the dump of composer.json and /vendor, but sounds like you did that.
I suspect you might be right about the Php version possibly not supporting the replacement version of Stringy...
Here's a recent thread where others were fighting with related issues. Maybe a hint also there: https://github.com/craftcms/cms/issues/4753
And, I just did a clear-cache, drop /vendor and composer.lock clean install of Craft 3.3.3, on another vm.
This went fine, and brought down voku/stringy 5.1.1
php version for this was 7.1.13, which is from Jan 2018, it says, though not sure that's actually involved as this dev source is on Win10
Composer itself says its version is 1.8.5, which is from April.
I just used composer self-update to bring it to 1.9.0
Maybe you should try that, as it might be as old there as the php?
Back from late exercise, and checking a couple of other things:
From what I can tell in composer voku/stringy downgrades to 5.1.1 when installing Craft 3.3.3, why is that?
Because Craft requires ~5.1.0 -- read composer doc, and you'll understand that locks to only minor versions, thus you and I get 5.1.1, which works fine . Latest is not always greatest, or tested...
You don't want to be requiring 5.2 manually, as this won't satisfy for Craft.
When I go to /admin/graphql the explorer it says: NO SCHEMA AVAILABLE
I think this is your real complaint. And the only way I can get it is by Disabling the schema in use, which here is also the Public Schema for the test. Even de-permitting all elements from it doesn't cause the message; only disabling.
So, I would suggest, once you return composer.json to workable:
Unless there is something we don't understand wrong, you should now have a working Schema, and no messages about it, just doc for the queryables.
Good fortune - late here, so off air now.
I've already done those steps. Like deactivate and enable, clear vendor and run composer again. Still same message, and same issue on 2 totally different craft installs.
But it might be something on our server so I'll see what I can do. I just dont understand why it downgraded one package and it failed after a craft update.
I just dont understand why it downgraded one package
Ah, well, I think I explained that, and that it's proper. Here's reading:
https://stackoverflow.com/questions/18979729/what-does-the-tilde-mean-in-my-composer-json-file
[GraphQL Schema] failed after a craft update
You've hinted your server software is out of date. Why not install and run the requirements checker?
https://github.com/craftcms/server-check
There's also a checklist on the CPUtilities>System Report page
If this doesn't suggest the problem, you should turn on devMode, clear logs, then bring up the CraftQL page to see the error. Then examine the logs for [error] and/or Stack trace.
You should also look at your browser console for any JavaScript indications.
This is normal troubleshooting. If you find something, you can then report a specific issue...
A fresh install of 3.3 on a virtual machine should also lead to some confidence.
@skramstad can, please, you create a new issue if you're having composer problems? Otherwise, it's really easy to mess up communication when talking about two different things on the same ticket.
Can you clear out your log files, reproduce the
{
"error": "Something went wrong when processing the GraphQL query."
}
error and then look at your log files?
@andris-sevcenko Ok, I had some help looking into this and it seems that superTable causes the following message.
Failed to validate the GQL Schema - Schema must contain unique named types but contains multiple types named "stMatrix_stMatrixImage_BlockType"
So if I'm not mistaking it might be a problem with the superTable plugin and my setup. My setup is matrix->superTable->matrix blocks. So that may cause this issue and multiple blocks.
I see someone else is experiencing this https://github.com/verbb/super-table/issues/300 so I'll leave it for now and wait for a superTable update.
Thanks!
@skramstad gotcha. I pinged @engram-design about this and we'll see if we can crush this.
This has been fixed in Craft itself. Up to @engram-design to implement in his plugin.
@andris-sevcenko https://github.com/verbb/super-table/issues/300 is still an open issue. Would you be able to provide some insight into what needs to be changed on the plugin side, so we can temporarily work around/supply a PR?
@ccchapman
https://github.com/verbb/super-table/blob/craft-3/src/gql/interfaces/elements/SuperTableBlock.php#L38
and
https://github.com/verbb/super-table/blob/craft-3/src/fields/SuperTableField.php#L787
Both need to return $value->getGqlTypeName() instead of the type itself.
And that's it.
@andris-sevcenko Thanks for the help, just been slammed, but will get it sorted ASAP
FYI, this should be fixed in Super Table 2.3.1
Most helpful comment
FYI, this should be fixed in Super Table 2.3.1