i have deployed spfx to sharepoint online. firsts I have run gulp bundle --ship and again gulp package-solution --ship. I have uploaded bundle file to site assets mentioned path in manifest file. package file I have uploaded to app catalog.
now if I have to modify existing code should I again run two commands and upload files back? I see bundle files generate file name with different version name.
That is correct from my experience.
The bundle files have a hash appended to them based on their contents, to differentiate between two versions of the script. This make it easier for browsers to get new versions when they are available. Waldek wrote a nice brief explanation about why they do this.
Note that when you upload the new package file, any pages with your web part(s) will immediately start pointing towards the new version of the bundle files. For best experience, I recommend uploading the bundle files first, then the package file, to avoid users experiencing any web part errors for that short duration if you uploaded them the other way around.
You can add "includeClientSideAssets": true" to your package-solution.json file, and you don't need to manually deploy your assets. You need just deploy .sppkg package and that's it.
You can even deploy it using o365 cli from cmd. In our env I created gulp task that first modify current version and then boundle and deploy it.
includeClientSideAssets attribute was introduced in the SPFx v1.4
Every time we modify / add any changes , we should run both gulp bundle --ship, gulp package-solution --ship commands and deploy the .sppkg package
Related
I'm following the installation docs for Backpack 4.1 for Laravel. The backpack:install Artisan command adds front-end assets to the /public/packages directory of my project. Usually, front-end package managers (NPM, Yarn, Bower, etc.) recommend not to add the actual package contents to a project's repository, and instead add a dependency lockfile that can be re-installed by a CI/CD pipeline. Backpack does this differently, as it pulls the front-end dependencies directly and there was no mention if one needs to add /public/packages to source control. Should I add these package assets to source control, or should I execute php artisan backpack:install in the CI/CD process instead?
Yes - you should include the public/packages directory in your source control. That’s what Backpack assumes you’ll do.
However, if you would rather NOT do that, you can create an alias to the directory in the package. You can find instructions on how to do that here, as method 3 - https://backpackforlaravel.com/articles/tips-and-tricks/once-in-a-while-re-publish-backpack-s-css-and-js-assets
There are several reasons why you might want to do commit the public assets to the source control:
You may not have write access to your production file system.
You may be deploying to more than one server, and want to avoid duplication of work.
You may be doing frequent deploys that do not include asset changes.
Generally, I think it is a good idea to put precompiled assets into source control unless you have a specific reason not to do so.
I'd like to completely remove an old Laravel application that I upload as a test version of my AWS Instance. I'd like to upload a newer fresh updated version of that application so I'd like to -safely- remove old one and upload the new one.
I'd like to avoid -if possible- deploy a new instance so I don't have to install and configure all once again.
Application path is var/www/.
Should I just simply delete with terminal all files within this path and upload the new one in this path? Or there is a better practice for this purpose?
Thanks all,
Fernando
The correct way of removing a Laravel project is just removing the directory that contains the desired project. So basically you could just remove the old project and deploy the new one and it should work!
you can delete your project with rm -rf your_project_path command
Trying to start from Timber but the solution won't load without a site on IIS Express existing. Further the contents of the downloaded zip file, while working, the solution does not come with a way to deploy to a new zip so I can create a new zip and deploy. There seem to be files in the zip that are not in the solution so I'm concerned I might not end up with same result just zipping up the files in the solution.
Trying to download the Skeleton but no links to actually download from the app store?
https://virtocommerce.com/skeleton-theme
Starting from the VirtoCommerce.Storefront project.
Copy the contents of the App_Data/Themes/Default folder to a "theme" directory in a new directory.
Create a git repo from the root that contains the "theme" folder.
Add a GitVersion.yml file to control the versioning.
Running in Azure using blob storage you can create a CI process to automatically upload your theme when changes are checked in.
Lastly login to the platform, navigate to the site you uploaded to and activate the new theme. This allows you to fall back if needed.
Zip File
You could also zip the contents of your repo up as well.
The zip file should have a folder in it like "ThemeName-0.0.0", within that folder should be the assets, config, layout, locales, snippets, social and templates folders.
Upload that in the store of your choice and activate.
I'll suggest to use default storefont theme as base theme for customization and educations.
I'm providing some helpful information for helping you to better understand some technical moments related to working with the VC themes:
How theme resources resolving process works:
How to develop custom theme and what technology stack for this use:
Local running pre-compiled platform with installed modules
Local storefront fork (pre-compiled or from source code if you need to future customization)
For case with single theme you might directly change default (global) theme which contains in storefront project App_Data/Themes/default or make separated GitHub repository which will contain only theme and static pages files (as we made for our main site virtocommerce.com theme) and link folder with theme to storefront App_Data/Themes/{store name}/Themes.
Edit theme files in Visual studio code or any other preferred IDE, all changes will be immediately reflected to the local storefront, thanks to the cache invalidation based on theme folder file changes watcher.
Deploy theme changes to staging or productions environment by using any of
convenient CI processes. We are use Jenkins server and Azure Deployment.
Change theme files from manager UI not recommended because you will lose history of changes. And you should use this way only for emergency fixes or for debugging purposes.
I am trying to install and understand ODE.
I set up Tomcat7 no problem
I set up ODE WAR distribution
I copied the examples folder as per instructions.
Then I ran it, and it failed.
Then I RTM some more and saw
The sendsoap executable can be found in the distribution bin directory. The urls should be updated according to the address defined in the WSDL file for the process service.
The executable script using the command line given fires an exception.
could not find or load main class org.apache.ode.tools.sendsoap.cline.HttpSoapSender
latest version.
If there is some update to URLs required there are no directions to do that anywhere in the install instructions. Given that new users do installs this has to be one of the most brain dead careless instruction sets I have read in years regardless of the fix. But can someone enlighten me?
Just to be clear, the startup screen on port 8080 comes up just fine.
The command line tools seem to have some class path issues. I'd suggest to use SoapUI instead, it provides a better UX as well.
Update: Quickstart to verify the installation:
For a simple test, just copy the helloworld2 example from the dist package to tomcat/webapps/ode/processes. The process should then appear in the web console. Copy the Axis2 WSDL URL of the helloworld process http://localhost:8080/ode/deployment/services/, which is most likely
http://localhost:8080/ode/processes/helloWorld?wsdl. Open SoapUI, start a new SOAP project, paste the WSDL URL into the "Initial WSDL" form and create the project. SoapUI will create sample request "Request 1" for the hello operation. Double click, play with the content and invoke the method using the green "play" button.
Due to a build problem the JAR files in the lib directory of the 1.3.6 WAR/JBI distributions don't work (Bug Report). Use the 1.3.5 distribution instead until this is fixed.
I am running Joomla 3.1.5. I have a custom component installed and I have made some minor changes to some of the files. How do I create an uploadable/installable zip file to install these changes to my production Joomla site?
Please disregard the discussion on templates in the comments above.
You don't need to rename your component it seems.
If you need to install on a single site:
on the prodution site, install the installer you first installed on
your development site
sync the files with a version control system
such as git / rsync / scp / sftp / ftp whichever you're most
comfortable with
If you need to install on multiple sites:
You need to repackage it, and add to the xml manifest any files/folders you added.
Simply explode the original zip installer somewhere on your drive, and figure out the folder structure (could be admin,site,media for example).
For each browse the custom_component_name.xml section and ensure it contains the files you added, if any.
Then copy the updated files over the folder structure, zip it, and upload it to production.
Once you do this the component will be registered in the other Joomla installation. You can also keep the copies aligned between the two servers with a code versioning system such as git.
If it's a component you plan on distributing, create a script to package it, look at the Joomla docs there's plenty of info, you could use a bash script, phing, ant, maven, choose one that suits you any will do the job