3

So far, Craft 3 hasn’t had any “real” breakpoint releases in the way that Craft 1 and 2 had, yet – where you would have a real issue if you were to update past them before updating to them. Craft 1 and 2 had a handful of them, which we took as opportunities to clear out the migrations/ folder, and clean up some PHP code. If you were to (somehow) update past ...


2

We had something similar yesterday. Try the following 2 tweaks: 1.) Delete your storage/runtime folder and then try again 2.) If this does not help, verify the credentials in your .env file and make sure they use a DSN like: DB_DSN="mysql:host=<dbhost>;port=<dbport>;dbname=<dbname>;"


2

Due to some underlying changes in the Sprout application architecture, and the fact you're migrating a database from Craft 2, I believe you will need to upgrade to Craft 3.3 and related Sprout plugins compatible with Craft 3.3 before you update to Craft 3.4. Below is a list of the Craft 3.3 compatible versions of several of the Sprout plugins. ...


2

Found the issue with the awesome Craft support. There seems to be a server related issue where db tables change from TEXT to VARCHAR. So the solution is to change those fields back to TEXT directly in the db.


1

When updating from Craft 2 to Craft 3, you will need to make a handful of decisions on how to handle plugins that don't have a clear migration path. The answer may be different for each plugin, depending on various circumstances. Moving forward with dead plugins, you'll generally need to... Replace it with a completely different plugin, or Port some ...


1

For others finding this post: we never made it. We invested > 2 days and then decided to stay with postgresql for this project.


1

Figured it out, the format it expects is 'source' => 'group: <group UID>' So... protected function createCategoriesField() { // Get the group $group = (new \craft\db\Query()) ->select("id") ->from("fieldgroups") ->where(["name" => "common"]) ->one(); // Get ...


1

There used to be a bug in Craft 3.0 (fixed in 3.0.19) where, if an error occurred during an update, your composer.json file could be left in a weird state where it was directly requiring all of Craft’s dependencies (recursively). My guess is that this happened to you. Try opening your composer.json file and see if your require setting contains a whole bunch ...


1

Think if the de site is the default site and the sections are setup to propagate the entries to other sites with the same language (or within the same site group, if de and de-AT will be in the same site group), the entries should be copied to the new de-AT site.


1

Answer: So I looked in the craft core to see how the CP does it. Turns out we have to use this $gs = new \craft\elements\GlobalSet(); $gs->name = "Meta"; $gs->handle = "meta"; Craft::$app->getGlobals()->saveSet($gs); Hope this helps someone. Craft core reference https://github.com/craftcms/cms/blob/develop/src/controllers/...


1

The typical way to do this would be to use something like https://plugins.craftcms.com/feed-me, where you could setup a feed of the data you want to export, map it to the proper fields in Craft 3, then import the data from a feed.


1

It sounds like it's working as expected. When you add a new migration for your plugin, you're expected to update your plugin's Install.php migration with the new schema changes as well. You can see the relevant code here: https://github.com/craftcms/cms/blob/develop/src/base/Plugin.php#L149-L161


1

Update I was able to solve half of my Problem: Seems the Regex didn't like the "pure" slashes / in the URL between the parameters, once I escaped those, through backslashes like this: \/ it no longer gave me a yii\base\InvalidRouteException. The new Problem I have now is that it can't find the action I'm referring to, see below: // Path of File: ./src/...


Only top voted, non community-wiki answers of a minimum length are eligible