In Craft 3:
You can download the latest Craft 3 release in zip or .tar.gz format by going to:
Or since Craft 3 is Composer based, you can modify your composer.json's craftcms/cms line to install the specific version you're looking for.
In Craft 2:
You can get the latest Craft 2 version ...
I solved the problem and am writing it down for future people encountering the same problem.
Add the following configuration to the your craft/config/general.php config file:
'omitScriptNameInUrls' => true
URLs will start to work fine.
Craft 2.6.2957 added support for PHP 7.1
There's a lot going on here, but 1st thing is 1st.
The vagrant box is running PHP 7.1
Craft 2 (and the current latest version of the Yii framework - 1.1.17) are not yet compatible with PHP 7.1.
When the next Yii 1 release is out that addresses the framework compatibility issues, we'll get Craft 2 up and ...
That's the setup we use here. It's ok, but local development runs slowly because the database is off-site - we'll be moving to an internal database server in the new year because of that.
Image transforms we just deal with by manually syncing the folders every now and then. I believe Andrew Welch has a script to help manage that - I've not tried it https://...
Product types are really all about data concerns - so if the data you're storing for your canines/equines (hereafter known as dogs and horses to save some typing ;) ) - is the same, then you're right you don't need more than one product type. So let's say you make one type of product Animal.
The most obvious tool for grouping that Craft provides is ...
Edit: Quick answer (as per RitterKnight's comment)... just add RewriteBase / to the top of your .htaccess file in the root of your public/public_html directory.
I am on the same type of shared GoDaddy server, and continued to experience the same issue regardless of wether 'omitScriptNameInUrls' was set to true. I would get an "Internal Server Error" on ...
Sounds like you just need to initially setup the client account with your colleague's email/password/name.
Have them do their testing and when you're ready to give it to your client, either just update the email/password/name or delete the client account and re-create it for your client.
This article might be of use to you: Setting up a New Craft CMS 3 Project
The DEPLOYMENT section talks about using Composer to install our dependencies, and not checking them into Git. That means a .gitignore that excludes vendor/
This isn't really a right or wrong situation, but rather that the advantages slightly outweigh the disadvantages, imo.
If you ...
Matt Wilcox alluded to it in his original comment, but something like Craft-Scripts will really help out with this workflow. You can read more here: Database & Asset Syncing Between Environments in Craft CMS
I've always ...
You have several options to solve this issue.
Import fields via plugin
You could create a plugin that handles all these function in it's installation callback so you would install the plugin and have all the things you need. But this requires basic knowledge in plugin development.
Advantage When Pixel and Tonic make any changes in their install process ...
Multisite is coming to Craft 3, so this only applies to v2 See here
I don't think there is an integrated way to do this and it might be worth reading this post:
Are there any intentions to release multisite support for Craft?
..we're pretty against adding it to Craft... at least in the way EE did it, where everything is stored on a per-site basis.
Currently not, but that's not a bad idea and probably worth adding to https://feedback.buildwithcraft.com.
During an auto-update, the file name of the patch file that is downloaded happens to be the MD5 sum of the file so the Craft client can verify the integrity of the downloaded file, but there isn't a mechanism like that in place currently for full Craft ...
Depends on your definition of "easy". :)
Probably the easiest way would be to do what you describe and import the full database. From there, you can write SQL to find all of the entries that you don't want to keep around from the craft_entries table. If you get the IDs for those, you can remove the equivalent rows from the craft_elements, and Craft's ...
This should be relatively simple to implement, although depending on how the page was designed may require reworking some of the existing page layout and css.
As far as craft is concerned the data could be stored in a few different ways; perhaps in a separate channel, table, or matrix field. Setting this up on the craft-side is trivial, and would not ...
You need to point your webserver to the public directory as stated in the docs here. So in your case that would mean setting your vhost to point to: User/me/www/Craft-2.3.2644/public.
In that public folder you will find an index.php file, which tells php where Craft can be found, by default (which yours is) that will be ../craft.
Good practice imo, it's what I do as well. Values come from the .env vars, and for things that are URLs or paths, I make aliases out of them to take advantage of what you're showing above.
This cannot cause any kind of issue like @web -- the only thing wrong with @web is that the host name is computed dynamically, potentially from untrusted browser data.
Running into the same issue here!
For the uploaded files I have solved it by creating a NFS share on all backends (15 servers). Not ideal but it's working for now. Maybe mounting the cpresources to NFS share would also do the job, but I haven't tested it.
I'd recommend you take a look at the excellent existing threads on this:
Git Workflow and Multi Environment - how to approach
What's the best practice for handling data migration and
organization across development environments?
as well as the official documentation on Multi-Environment Configs
Source: Correct way to set up development and production ...
Completely untested, but you may consider setting up each site as environment using Multi-Environment Config approach.
Then in each domain's site root directory you'll need to place .htaccess and index.php like this is done for Localized Sites
Then you can configure URLs for each site pages in routes.php config file (so you can use different templates for ...
I've looked all over for a solution to this but couldn't find anything. I don't know if you've already fixed your problem now, but in case you haven't or someone else has found this error and arrived here, a simple fix for it is to add the missing information into the project.yaml in config/project/.
For my local development build, I used the following:
Try to add your alias array within one of your environment array such as:
// Global settings
'*' => [
'aliases' => [
'@rootUrl' => getenv('ROOT_URL'),
// Dev environment settings
'dev' => [
// Staging environment settings
'staging' => [
Have you been through Craft's testing documentation? https://craftcms.com/docs/3.x/testing/
There's a pretty good walkthrough of the necessary steps there to test plugins: https://craftcms.com/docs/3.x/testing/testing-craft/setup.html
Or if you like more real-world examples, Commerce's tests are a good place to start: https://github.com/craftcms/commerce/...
The .dev connection gives me an error
Don't know if it'll solve all of your problems, but .dev is no longer a valid TLD you can use for local testing since Google made it public: https://domains.google/tld/dev/
Change it over to something like .test instead.