You can just rename web/ to public_html/, or move all the files inside web/ into public_html/. (Don’t forget to move the .htaccess and .env files, if the latter.)
As long as the location of the public_html/ folder is in the same place as the web/ folder was, you don’t need to change anything else.
Craft Plugins require that a "type":"craft-plugin" property is defined in each composer.json file. Composer refers to this to help manage and install the plugin. Craft Modules do not currently have this support.
You can see all package types that Composer Installer supports here. There is still a way to achieve what you're trying to do though...
You'll need to remove every required packages besides the plugins you installed and craftcms/cms as well as vlucas/phpdotenv, clear your vendor folder and run composer update again.
For whatever reasons sometimes all required packages by Craft end up in your custom composer.json which causes these errors
I suggest you to take a look at all your plugins and ...
Have you tried running ./craft setup to double check if your setup is correct?
If ./craft setup completes successfully ./craft should find the existing installation and complete any required setup.
In my experience, this is usually related to a non-default /config/db.php or problematic .env file.
Note: Always do a backup before trying anything related ...
To find the culprit, you could run a composer show --tree to see which plugin is using the dependency.
So far, I found two plugins using it :
If you're using Solspace calendar, you should consider to upgrade to v3.
If you're using Rias Contact form extension, you can try to add ...
I was just confronted with this too. You most likely need to specify the unixSocket attribute for the MAMP Pro database. Take a look at my problem and solution at Craft CLI RC1 Connectivity Issues with MAMP Pro. Though if you're not able to get it working at all even manually I would definitely suggest resetting your root password in MAMP Pro as well.
The documentation posts this link:
Upgrading from Craft 2
Mijingo has a tutorial: Upgrading Craft 2 to Craft 3
There is a hangout on the topic on Straight Up Craft: Migrating a website with plugins from Craft 2 to Craft 3
At the time of this posting, I have not seen any good documentation on how Plugin Developers should approach migrating their plugins.
I'm not 100% sure what you're looking for, but Craft does use Composer to manage its own dependencies.
If you're referring to using Composer in your plugin, it's as simple as creating your composer.json file in your plugin's root folder and running composer update.
You can get this error message even if Craft installation is OK. If you work in MAMP environment and have this error message, check if your PHP and MySQL are available from command line (Terminal).
To check PHP, do following:
Open terminal and type: $ which php
If you see something like "/usr/bin/php" that means MAMP's PHP is not available from command ...
All Solspace plugins use some bit of the Carbon dependency so it's highly likely it might be something like Calendar and/or Freeform triggering this. As of last week, we've updated Freeform 2, Freeform 3 and Express Forms to use ^1.22.1|^2.19 for the requirement, and Calendar will receive the same update this week.
The issue is that Carbon 2 requires PHP 7....
From what I see in your screenshot, it looks like you stumbled upon a Craft 3 installation, in which case neither a Craft nor Public folder exist.
Craft 3 specific
The public folder is now called web, so that's where you should point your MAMP documentroot (or whatever that's called in MAMP). The Craft code is now located in composer's vendor folder, that ...
No, running composer update will not – by itself – result in any changes to your database.
When you run composer update, all that happens is that Composer downloads updated versions for all your installed packages (i.e. Craft, plugins and other dependencies), before writing a manifest of your currently installed packages to the composer.lock file. Full stop;...
From looking at your plugin's composer.json file, I think you've got the package name wrong – instead of
composer require kgrote/siteutilities
you'll probably want
composer require kgrote/site-utilities
I.e. the plugin folder's name doesn't matter – it's the name entry in your plugin's composer.json file that determines the package name.
The reason seems to be that either the PHP version of the MacOS Catalina update or a version installed via brew do not come bundled with the ext-zip extension.
You can verify that by calling php -m in the Terminal. You will get a list of all modules and it will not contain the word zip
Even if it contains the word zip it does not necessarily mean that ...
The article I wrote So You Wanna Make a Craft 3 Plugin? may help you in terms of figuring out how to properly set up a "host" website to run your plugin development from.
TL;DR your repo shouldn't point to your site's vendor directory, it should point to wherever that plugin exists on your local dev environment.
Craft 3 knows about available plugins via the vendor/craftcms/plugins.php file, which stores info about all Composer packages that were installed with type: craft-plugin in composer.json.
If that file doesn’t exist or is just returning an empty array, then make sure that the craftcms/plugin-installer Composer package is installed, and try re-requiring each ...
You are running PHP 5.6.30 on the command line (read the error message), which you can also verify with php -v.
To swap the PHP, you should add the path to your preferred PHP executable to your shell’s configuration file (e.g. ~/.bash_profile, ~/.bashrc, ~/.zshrc).
Another option is to ignore the ...
error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
Your local OpenSSL setup is trying to connect with an older, insecure TLS 1.0 protocol, which Github (and a lot of other sites) no longer support.
If you update it to use TLS 1.2, the error will go away.
If you're on something like MAMP/WAMP, etc. then updating to the latest ...
I found the real root cause. A internal business plugin which I migrated from Craft 2 to Craft 3 had a composer.json file which required composer/installers and that little bugger was mucking up the whole thing.
So if you find that in your composer.lock file for Craft 3, go in deep and find it!
If you have a caret icon infront of your version number, for example
These version numbers in composer.json will not change when you update.
The caret icon tells Composer it has free reign to update this package, but not to the next major version number. ^3.0.0 can update to 3.1.0, 3.2.0, 3.2.1 etc, but won't update to 4.0.0. As ...
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 ...
Incase helps any other designer come devs who haven't a full grasp on dev/CL workflow, these steps worked for me – with thanks to craft support/community:
in terminal, run exactly this: PATH="/Applications/MAMP/bin/php/php7.0.15/bin:$PATH"
composer create-project craftcms/craft PATH -s beta --ignore-platform-reqs
PATH being your absolute path to your ...
nystudio107 just released a nice guide yesterday for setting up a Craft 3 site via composer. No mention of Mamp Pro, but I don't think that should really be a problem if you're already used to using it, as you would just make sure your hosts file is pointing to the /web/index.php file. The article does a great job of explaining what a lot of the terminal ...
I had the same problem following that video, i assume the ReleaseCandidate upgrade differs from the beta upgrade. Following the instructions from the craftcms github repo worked for me. https://docs.craftcms.com/v3/upgrade.html
[SOLVED] By upping wait_timeout from 10 to 100 in my.cnf - seems to have fixed the issue.
Initial google searches for "Error while sending QUERY packet" led me to increase max_allowed_packet size, but this didn't fix the problem alone.
Note, I'm not sure if both timeout and packet size need to be increased or just timeout nevertheless I have increased ...