I was wondering what the best way was to deploy shopify themes locally for testing before deploying. We recently started employing deploybot. We really like deploybot but we also would like a way to not wait five minutes to test our files in an alternate store.
How would I accomplish this?
It's tough to preview themes locally. Check out Themekit if you want a quick way to sync local theme files with a development shop: https://shopify.github.io/themekit/
Here's how to setup a local working environment:
https://www.shopify.com.au/partners/blog/95401862-3-simple-steps-for-setting-up-a-local-shopify-theme-development-environment
Install themekit:
curl -s https://shopify.github.io/themekit/scripts/install.py | sudo python
https://shopify.github.io/themekit/
Setup API credentials by creating a private app in your Shopify admin.
Apps > Create private app
Get your theme id.
visit name.myshopify.com/admin/themes.json to get a list of themes and ids
Create a config.yml file and populate it with the credentials. It should look somewhat like this:
development:
password: 16ef663594568325d64408ebcdeef528
theme_id: "123"
store: can-i-buy-a-feeling.myshopify.com
proxy: http://localhost:3000
ignore_files:
- "*.gif"
- "*.jpg"
- config/settings_data.json
Have themekit listen for any local changes and upload them to Shopify.
theme watch
However the store is still online. Because the Shopify framework is hosted on Shopify there is no localhost solution.
For anyone coming to this in 2018, we now have use of Slate.
https://shopify.github.io/slate/
For an idea of workflow, we have multiple devs working on the same theme and they can see their changes locally with Slate.
How we achieve this
We have a dev store that is a direct clone of our production store.
Each dev creates another theme on the dev store and branches off master locally. They then will ONLY use the theme id of the theme they just created to work with (updated in their config.yml)
Slate will watch changes and deploy to their preview theme and refresh their browser locally too.
Once the dev is happy with their changes, we merge back into master and deploy to the live (master) theme on our dev store.
Once it passes all the tests on our dev store, we push to a production store using slate.
EDIT - For creating new section files, template files, product templates etc
You won't be able to create these files and for them to be displayed locally without a small workaround.
For example, if you create a new product template ("product.my-product.liquid"), you'll need to Publish your preview theme first, then perform a "slate start" in terminal, select your new product template for whatever product you're using it on in Shopify, then re-publish your "master" theme.
You may need to do another "slate start" to get the new theme template displaying on the product locally, but it will work.
This is because Shopify only allows you to assign product templates to the current active theme.
You have a test shop. You are working on a theme. If you are doing it right, any changes you make to the theme, are automatically transferred to the test shop. So all you need to do is watch your browser, since you probably also have a watcher on that auto-reloading on changes.
Have been doing this for years, and I never wait 5 minutes for a deploy, as it takes mere seconds to deploy a change and see the results. Throw in some smart Git hooks and you've even got version control.
Related
Basically what I have is my frontend (Vue) and my backend (Node.js and etc.). By following a guide, I've built the frontend for production using npm run build. I got a bunch of files in a build folder I setup within a previous step. These files were then moved to a folder in the backend. It works, but it's more a demo than anything else, and the frontend and backend will have to be modified more as I continue.
I'm just wondering if and when I edit the fronted more (let's say, when I add a new page) am I supposed to go through this process again? So I'll modify the front end folder, build that, move files, etc.
Thanks.
Yes, definitely.
If we are in a development environment, we use npm run dev or yarn run which upholds the development environment running and updates the browser whenever any modifications inside the code happen. We don't use any final build in the development environment because we make code modifications so repeatedly that it would be a sore process to make a build after every modification and check the results using that build.
But, the production is distinct from the development environment. We deploy the only code which is bug-free, entirely working, and ready for users to use. Deploying to production means all changes have been made, and the final code is ready to be deployed. So, we make a final production build and deploy it to our server.
So, don't panic to deploy to production every time you make a small change in the code. First, complete your all changes, and test the changes in the development environment, if everything is working correctly then only create a final production build, and deploy it to the server.**
I hope this helps.
I have vue project which published on Digital Ocean. The main problem is when i make some changes on FileZilla it is not affect on website. How can i solve this issue?
This is not an issue per-se. This is just the way how modern web development works. Vue.js (but also Nuxt) is using a bundler right now (Webpack, Vite are the most common), hence to go to production it needs to be bundled each time you push something to it.
If you upload something via FTP or SSH and edit some source code, a bundle step will be required in order to get any changes on the actual webapp.
Backend languages may not need that, for example you could SSH into a server and change some .php file, if you F5 the page it will be updated in real time. But this is not how frontend JS code works, it needs to be optimised.
Another thing, sending code via SSH/FTP is not really a good workflow because it is not easily trackable, no version-controlled, will not trigger any build flags in case of an error etc...
The best approach is to have a git repo + some build step included in some CI.
A common platform for it is Netlify, you connect a Github repo, you tell which command to use to build the project and each time you push some code, it may do some checks/tests/optimizations/etc... via Github Actions before being released automatically to production (updated on your webapp).
This workflow have a lot of benefits as one may tell but is also de-facto, the official/regular approach for modern Web development on the frontend.
I am currently working on a project that is in SPA mode of Nuxt and I want to add a package called nuxt-password-protect. This is for security reasons when opening any environment such as dev and staging. I want to provide a password for every access to my staging or dev links. But I am quite confused if it is really necessary to change the mode to SSR/universal? I already changed my mode and it seems working when I also installed the package. Can someone expound some knowledge with this? I am new to nuxt and Vue.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed last year.
Improve this question
I want to design a wordpress development process like in following picture:
First I want to create a bitbucket repository for my Wordpress site. From this repository all our software developers should able to clone the site to their local machines for developing. For developing all developers should have one local database to test changes.
After a developer finished a task he should be able to push his changes to the repo. When a sprint is done I want to send all changes from the repo with Jenkins pipeline/job to the test environment. At this environment a tester should be able to test all new functions with a cloned database from the prod system (including the dev changes).
When all tests are successfully done I want be able to apply the database changes to the prod system (with a SQL script) and send all changes with an other Jekins pipeline/job to the prod system.
Do you think this can work? Whats with plugin updates? Can I setup environment variables for each system so the plugin updates can be just done on the dev machine?
I'm not sure if this could work because a plugin or plugin update creates a lot of new database changes and I think I need a tool who can display all changes like Sourcetree for git.
Is there someone who has expert knowledge with wordpress and this kind of development process and can share his experience with me?
Or do you think this process is not working with wordpress? If this is true it would be realy bad because I need a process like this.
Thanks a lot!
I don't really know Wordpress, but the process you describe is definitely possible (I've implemented similar solutions on Drupal and Adobe Experience Manager, for instance).
However...
It's hard.
In a CMS project, a change/new feature can include:
a code change (PHP, CSS, JavaScript)
a database structure change (e.g. a new table)
a database content change (e.g. a copy fix, or default/test content)
a configuration change
Working out which version should get what is really hard. You want a developer to commit a change, and have that change replicated on QA with test content - but once QA sign it off, you probably don't want to promote that test content to production. And config changes should probably flow between systems but with different values for each environment.
For managing the database changes, I've found a plug-in that monitors database changes; no idea how scriptable that is.
See WP Activity Log.
What I've done in the past in similar situations is write a script that creates the database definition for each change - so a developer can run that script, and commit it as part of their code change. It requires a lot of discipline, though - you can only modify the database structure by using the scripts.
The correct answer is yes you can do this. I know WordPress, Bit-bucket, GIT, SVN, Linux, Ubuntu exceptionally well. I have built a system very similar to what you describe and use it daily.
The problem stated is the CMS can get tricky. That is true, but you need to use the correct tools for the correct upgrades. So, WordPress ALREADY has versioning and revisions built into it. The DATABASE doesn't need to be involved at all
First off. The database doesn't need to be updated unless you are updating plugins. But for strict development no DB pushes are necessary. So have your developers check files in and out of Bit-bucket. When the lead developer approves the changes have him migrate / push to the MASTER BRANCH in your REPO. Inside of bit-bucket there is a tool called GIT HOOKS. You can trigger a php file on the server every time there is a push to the production branch. What the PHP file does is simply trigger the linux command GIT PULL which will update all the code on the server with what in on your PRODUCTION BRANCH. GIT PULL will also remove any files if files were removed etc. On the server you will have a "checked out" copy of the GIT repo and on linux the credentials after the first clone will be stored. Simply have your PHP file trigger a BASH script that does a GIT PULL. Done.
No matter how many developers you have there will always need to be a set of eyes that reviews the code changes and merges those into production. I.e. that is where the Lead Developer comes into play.
FYI. The only directories in your wordpress instance that needs to be in bitbucket is the THEME DIRECTORY and the PLUGINS directory. You DO NOT need to sync the entire WP install which is pretty large.
In the case that you would be building custom Plugins, again, it is just code that is stored in the plugins directory. If your custom plugins are built correctly and require the use of Databases then when they are activated they will immediately build the WP DB's that are needed. Likewise, correctly built plugin will also drop its own custom table when uninstalled.
You will need to sync the 2 below directories.
Plugins folder resides in: wp-content/plugins/
Themes Folder is wp-content/themes/SELECTED_THEME
Any additional questions just ask and I am here.
From my experience it is always better to allow each developer to have their own Branch and to setup the the Dev server a dedicated master branch for quality control. you can check out some documentation on how to set this up https://plixxer.com/docs/server-management/website-quality-control/
basically you want to have a live server and dev server. The live server should only ever pull from the REPO and and the Dev and coders can pull or Push from the repo. My team treats the dev server as a quality checking station. If the current live code is not up to our standards the entire dev is rolled back to what is live on the master branch. When code in the master succeeds our standards we pull from the master branch onto the live server. Each developer should have their own branch for testing on their local server. Let me know if you need some help on setting up a local environment with GIT.
You will want to make a distinction around "build" and another around "release". The workflow I understand is that developers call their local workstations "dev", and pull request their work to the develop branch (you may have already read through Gitflow). Then, using your choice of CI automation, you get the latest source into a build area and do that - build it. Check out Ansible. If you have BitBucket, maybe you also want to organize your sprint with the likes of Jira? Then you have pretty seemless integration of your sprint objectives with actual branches containing the relative work/source. Ansible can help you automate builds and releases to the point where you are doing daily builds, and running the unit tests across your builds in the various integration environments.
During builds, you would have different configuration files being factored in depending on the target environment. This is how to care for environment configuration. It is part of the build process, and ideally all configuration is possible through the build. For example, a connection string might be different across the environment if you are having different databases to isolate migration of schema changes. For example, in a Angular application you would execute ng b --prod to build production and this would bring in a production configuration file during build to change the connection string (for example).
More about configuration specific to environments... you can also include post deployment scripts that get deployed and executed after files are uploaded so that they will configure the environment as required.
Ask your questions below, and I will do my best to build this out into a comprehensive guide.
I'm going to work on a Shopify theme, and I want to figure out how to run/edit it locally. I'd like to be able to the following, if possible:
Pull all the Shopify theme code from the site to my local computer (ideally a single command line tool)
Make edits locally, and run them locally or in a staging environment
Push all the edits to the main Shopify site, again using a command line tool
Is this at all possible?
There are quite a few workflows you can use here.
1. Task runners
If you're using either Gulp or Grunt locally for development, there are libraries out there that will upload your files to the store through API credentials of a Private App that you have to create. Most work by uploading the files you change, using a watcher.
grunt-shopify
grunt-shopify-upload
gulp-shopify-upload (it's my favourite since I use Gulp but has a known issue that sometimes it stops uploading files and you have to restart it).
2. Official Shopify Theme Kit
Theme Kit is a cross-platform CLI tool that was built by Shopify Employees. It can run on windows/linux/OS X. You can read more about it on Shopify Blog or download it directly. The alternative previously mentioned of Desktop Theme Editor is deprecated and has been replaced by Theme Kit.
3. Third-party SaaS Applications
Instead of watching for changes, these will work with a continuos integration workflow, where your latest push on a certain branch gets uploaded to the theme you've selected.
Beanstalk. More specific information can be found on their landing page for Shopify, here.
DeployBot. Their help article on Shopify has some information on how to get started.
Both options are from the same company. Here's a comparison of both they've did on their blog.
4. Third-party libraries
There's also an alternative not officially supported by Shopify which is a TextMate Bundle in case you use that OSX editor.
There's an unofficial extended cli similar to theme kit but with further functionality called Quickshot, which I've just found out based on Matt's response and seems pretty awesome. Some of the features they highlight are:
Supports uploading to multiple Shopify stores and themes
Easy to use configuration wizard
Uploads/downloads in parallel greatly reducing transfer times
Supports autocompiling scss locally before uploading to Shopify
Supports autocompiling Babel/ES6 into modules which are easily used by - Requirejs and others
Can use with .gitignore files or a custom .quickshotignore file.
Can download/upload Shopify Blogs, Pages and Products! Easily transfer them between stores! Even the metafields! And edit them locally in your favorite editor.
Shopify recently released Slate, a new tool for theme development.
https://github.com/Shopify/slate
As of 2020, Shopify has stopped support Slate so you can now use Themekit - https://shopify.github.io/themekit/
2022 update
Currently it is not possible to run Shopify locally. There are only solutions, mentioned in other answers to edit files locally and upload it to Shopify. It makes the development hard.
I am working on a solution to emulate Shopify locally making development similar to WordPress, React or Angular. So you will see changes immediately, even without reloading the page and without the need to upload files to Shopify each time.
You can read more here: https://link.medium.com/6SGd1kcVdnb
Juan's answer is spot on.
There's one more I know of which I believe is a little more advanced than Themekit (which I use) called Quickshot: https://quickshot.readme.io/v2.1/docs
Shopify have built a tool for Mac that allows you to develop your theme locally, and sync with your store https://apps.shopify.com/desktop-theme-editor
I don't know of anything for windows/Linux etc.
If you're looking for completely offline development, it's unfortunately not possible at this time. While the Slate/ThemeKit CLIs lets you code in your favorite text editor, an internet connection is still required because it likes to keep everything in sync at all times.
Install the state package by running the following commands:
npm install -g #shopify/slate
slate theme theme-name