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 ...
Very similar to Devin's answer.
I came up against this on Friday and I had to follow these steps to resolve this issue.
Nuke the vendor folder within the project. rm -rf vendor/
Nuke the composer.lock file within the project. rm composer.lock
Clear the composer cache composer clearcache within the project.
Rollback to composer v1 composer self-update --1
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.
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 ...
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.
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;...
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....
I managed to solve this by running:
rm -rf vendor/
At this point, the error still persisted when running composer update or composer dumpauto but then after running:
composer global clearcache
everything worked as per normal.
My guess is something got corrupted within in composers' global cache.
I am not sure if the first two steps are ...
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 ...
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 problem seems to be with parsing vendor/composer/installed.json
Once I deleted it - install went well. Even without deleting other files. This one is generated one. You can also simply remove whole vendor/composer directory.
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.
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 ...
Your index.php file should be found under the web directory. All of the other files and folders installed by composer are considered to be above the root which is recommended for security reasons.
Place all of your css, js, images, etc into the web folder and create your twig files in the templates folder and you shouldn't need to edit your index.php file, ...
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 ...