I want virtocommerce in my own local repository.
storefront is a solution that will configure it according to the following link:
Storefront Source Code Getting Started
And it works.
But I want to have a solution For platforms and modules,
Like the link below:
vc-integrations
But I need the platform and modules to be connected to the github for the latest changes.
I've studied the link below:
Source Code Getting Started
but I do not understand how should I configure for my goals (one solution for platfrom and modules and fork, clone ,upstream for all for get latest versions of them)
We've used to have a single repository and single solution for Virto Commerce Manager and modules (vc-integrations). It was difficult to maintain and release often. That's why the single repository was split into many "1 module per repository" pieces.
We consider that in most cases having only Virto Commerce Manager configured should be sufficient. What's your scenario? Check "Manual module installation from source code" section in Source Code Getting Started to get started.
Related
I am working on multiple projects, i.e. multiple repos on github and have more than 10 repositories with multiple people contributing to different repos on daily basis.
It was getting hard to manage various aspects of repos, so I decided to build a dashboard using github graphql api, to visualize and display
summary on one page.
I want to show status for each repo, if eslint passed or not. Currently I am in dilemma on how to run eslint on each repository progamatically, and report the errors and warnings on one page using some api,
I did setup a node-graphql project and getting various information from the repos. Not really sure how to approach for this particular feature.Any help or suggestion is deeply appreciated.
Thanks
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
Any suggestions of how to structure my solutions when developing custom Modules and frontend?
I.e. Should I just clone the repoy and add my modules and change web.config with transform files directly in the repo. Will a future pull working well then? any ideas for simple developing and simple upgrade?
Or is it wrong aproach. Should i use azure deploy script/ slot settings and call virto api to add virto modules...
ok i saw thar virto has updated its documentation
http://docs.virtocommerce.com/display/vc2devguide/Developing+a+custom+solution
I'd like to use external API within Yii2 application.
I couldn't find any tutorial about it.
I'd like to know how to do it in a decent way - do I have to build separate module to use this API or organize it in another way?
Any simple examples would be appreciated.
I'd like to build a tool, to use external API of other online application. To be straightforward - I'd like to import invoices etc. from external accounting system to my Yii2 application. This accounting system has API and I wonder how to use it properly inside Yii2 application.
The perfect solution for now would be to install ready module like "yii2-accountingsystemname-api", then I put some login and password for this system and I'm good to go - I can use it inside my application like:
getInvoices->all() etc.
After doing a bit of research I have found this guide that explains how to use third-Party code with the Yii2 application:
http://www.yiiframework.com/doc-2.0/guide-tutorial-yii-integration.html
This is a excerpt from that article:
Using Third-Party Libraries in Yii To use a third-party library in a
Yii application, you mainly need to make sure the classes in the
library are properly included or can be autoloaded.
Using Composer Packages Many third-party libraries are released in
terms of Composer packages. You can install such libraries by taking
the following two simple steps:
modify the composer.json file of your application and specify which
Composer packages you want to install. run composer install to install
the specified packages. The classes in the installed Composer packages
can be autoloaded using the Composer autoloader. Make sure the entry
script of your application contains the following lines to install the
Composer autoloader:
// install Composer autoloader
require(__DIR__ . '/../vendor/autoload.php');
// include Yii class file
require(__DIR__ . '/../vendor/yiisoft/yii2/Yii.php');
I suggest that you read the article because there is lots of other valuable information that may help you, and possibly better suit your needs than what I copied above.
Best of luck with your project!
I'm wondering how Software Development Team distribute their Standard IDE(s)?
E.g. developing with Eclipse, custom Code formatter, svn Resository, Copyright Header..
At the moment my Team has a standard zip File which is then distributed withhin the developers.
Problem:
If one file, a Plugin or the IDE itself changes, e.g. new Coding Guidlines, Upgrade Eclipse 3.5.1 the whole distribution has to be done again. Every developer needs to unzip the bundel again. Imagine your working with different Workspaces (Jetty, different Tomcamt Versions, WTP) due to Project History That doesn't scale
I know that there are some related Articels
A new version of Eclipse just came out. Is there anything I can do to avoid having to manually hunt down my plugins again?
Manage Your Eclipse Install With A Local Git Repository
And some comercial Programs.
Eclipse also has a new Update-Installer Approach
But I don't see the Killer App. How do your team solve this? Is there a best practice?
I guess best would be a Program letting you choose your current Project and then downloads the configured IDE from the Server and leting you know if Project Config Files are Updated
For eclipse look at Buckminster it targets exactly your target I suppose, didn't use it personally through.
At my previous company they wrote a custom update agent that pulled from a centrally configured server which was updated by the team leaders. It worked well, until people wanted to install their own plugins.
Basically, a developer wanted a plugin, fought in futility to get it included in the default (managed) repo, installed it himself, then updates broke on his machine when the team lead had a sudden stroke of common sense and included it.
They never did come up with a 'good' way to manage it. But, at least they didn't put us all on terminal servers with thin clients.