Is there any way to exclude a folder while creating an xpi file using cfx xpi. The documentation doesnt provide any info on this.
I am asking this because in the directory created by cfx init i also have a directory as HTMLTestPages in which i have some test JavaScript since we cannot debug the add-on sdk JavaScript.
Every time i have to create an xpi file i have to remove the folder and again place it. furthermore, if we has this folder on svn this is more problematic.
searching on google shows this bug listed to exclude vim temporary files and in the comments they are also discussing excluding any files starting with .(period). So is there any way to check if this is working in add-on sdk 1.6.1?
The current Add-on SDK version will only add very specific subdirectories to the XPI package, namely data and lib. If your project also has a subdirectory foo or files at the top level with names that the SDK doesn't recognize - these will be simply ignored.
Now if your files are located inside a known subdirectory like data - in this case they will be included in the package. The Add-on SDK has hardcorded rules concerning files and directories that should be excluded, you can see them under python-lib/cuddlefish/util.py:
IGNORED_FILE_PREFIXES = ["."]
IGNORED_FILE_SUFFIXES = ["~", ".swp"]
IGNORED_DIRS = [".git", ".svn", ".hg"]
This means that file names starting with a period or ending with either ~ or .swp will be ignored. But as far as directories goes - only .git, .svn and .hg will be ignored (and this definitely works). If you want an additional directory to be ignored then the only way will be to edit python-lib/cuddlefish/util.py and add it to IGNORED_DIRS list (something that you will unfortunately have to repeat after each SDK update).
Related
Is it possible to change the permissions of files that get added to the DMG volume created by install4j (via Media->macOS single bundle archive->Installer options->DMG options and files->Additional Files in DMG->"+"-> Regular file)?
I am adding a separately uninstall.app (to uninstall pre-install4j versions of the Application) but the added executable file the uninstall.app runs ends up not being executable! (I have to add all of the files under uninstall.app individually)
I have a workaround which is to include the uninstall.app as a separate File set which gets embedded within the Application.app/Contents/Resources/app folder, and then creating a symbolic link in the DMG down to that, but I'd prefer to have the whole uninstall.app separated -- it can be run directly from the DMG.
Suggestion: Allow setting permissions of the additional files (or just preserve permissions). Also a recursive "copy folder into DMG" would be good, or alternatively allow copying of an already defined File set into the DMG?
Thanks for your suggestions, I have added them to our issue tracker.
Unfortunately, it is not possible to change the permissions as of install4j 8.0.
Update 2021-02-05
This will be available in install4j 9.0.
We have an internal discussion going here and we are somewhat torn on the best practice for using .gitignore on projects that contain a lot of files (like a CMS).
Method 1
Method 1 would be to purposefully .gitignore all files that come standard with your build. That would generally start like:
# ignore everything in the root except the "wp-content" directory.
!wp-content/
# ignore everything in the "wp-content" directory, except:
# "mu-plugins", "plugins", "themes" directory
wp-content/*
!wp-content/mu-plugins/
!wp-content/plugins/
!wp-content/themes/
# ignore these plugins
wp-content/plugins/hello.php
# ignore specific themes
wp-content/themes/twenty*/
# ignore node dependency directories
node_modules/
# ignore log files and databases
*.log
*.sql
*.sqlite
Some staff members like this approach since if you create something outside of the standard files, for example like a /build folder, then it would automatically be detected for inclusion. However, writing custom theming and plugins require you to add a few layers to this file to "step in" to the folders you want to keep, and generally, the file is a bit messier to read.
Method 2
Method 2 ignores everything, and then you whitelist what you want in the repo. That would look like
# Ignore everything, but all to descend into subdirectories
*
!*/
# root files
!/.gitignore
!/.htaccess.live
!/favicon.ico
!/robots.txt
# theme
!/wp-content/themes/mytheme/**
/wp-content/themes/mytheme/style.css # Ignore Compiled CSS
/wp-content/themes/mytheme/js # Ignore Compiled JS
# plugins
!/wp-content/plugins/my-plugin/**
# deployment resources
!/build/**
Some staff like this since it's cleaner, you have to purposefully add something (which makes accidental adds harder), and it also in effect shows you your .git folder structure.
What is the best practice? Which method do you enjoy and would you recommend doing one over the other?
The second method is the best practice, when it comes to exlude some folder contents of gitignore rules.
It better reflect the following rule:
It is not possible to re-include a file if a parent directory of that file is excluded.
To exclude files (or all files) from a subfolder of an ignored folder f, you would do:
f/**
!f/**/
!f/a/sub/folder/someFile.txt
Meaning: you need to whitelist folders first, before being able to exclude from gitignore files.
It is clearer, shorter (unless you have a large number of folder to whitelist)
What if it is a Joomla install with a large amount of directories and files?
Or what if a core upgrade adds new files or folders
Don't forget you can have multiple gitignore files, one per folder.
That means you can mix and match both approaches.
And you have:
http://gitignore.io/ (which does blacklist when it comes to Joomla application)
github/gitignore (same approach for Joomla)
The ideal .gitignore file, is the one that does not exist.
For some reason, you're deeply intermingling files you want to track via source control, with files you DON'T want to track.
This, I think, is the source of your sadness.
You are mixing git's intended purpose, which is versioning of programmer-edited files, with deployment, which is intended to get the files where they belong in the correct directories.
Your question is not clear, as to whether you think the Wordpress core files should be versioned. I'm assuming not, since that's how you've set up your .gitignore.
Your question is also not clear, as to whether you are deploying a web site, or shipping plugins as a product. Those are both different use cases, and they require different types of versioning. If this is a deployed web site, you SHOULD be versioning Wordpress along with everything else. If you are shipping a plugin or a theme, then you should have a test suite of plenty of different Wordpress versions to test against.
I think your source control system should be set up, solely to track just the plugins/* and/or themes/* files that go into your distribution. Zipping that folder should give you the plugin asset that your customers download.
To debug your plugins, there should be a deploy step in your IDE that copies each of those tracked files, into a Wordpress install at a location you choose. This permits you to more easily test against different Wordpress versions.
You're reducing workflow problems, to trying to choose a .gitignore. Fix the problem at the root by getting the workflow right.
My problem is that the portable version of visual studio code don't load my settings I had copied from the folder %APPDATA%/code/user.
I loaded the .zip data and extracted the folder. I added a data folder into the extracted folder of VS Code. It's in Visual Studio Code\data. In there i copied the folder "user" from %APPDATA%/code/ and renamed the user folder into "user-data". Then I started code and the usersettings are not loaded.
The command .\code.exe --user-directory .\data\user-data won't work.
Is this a bug or did I do something wrong?
In portable mode, the --user-directory command linte option is ignored.
From the documentation:
--user-data-dir <dir>
Specifies the directory that user data is kept in, useful when running as root. Has no effect in Portable Mode.
Instead, use the default location of user data for a portable install and copy your user data to that directory (from a previous comment it seems like you've already done so successfuly).
For anyone wishing to use a different user data directory when in portable mode, symlink-ing the user data folder should be a viable option if on a linux-like platform.
(Trivia: this was at first reported as bug, after which the documentation was updated, rather making it a feature.)
You can simply create a folder called data in the root folder with
VS Code.
After the startup, the files with standard settings will be
created in the data folder.
Then you can just copy the settings from the folder %AppData%\Code\User to the folder data\user-data\User.
To migrate already installed extensions, copy the contents of the %HomePath%\.vscode\extensions folder to the data\extensions folder.
I'm programming a client side applications using SharePoint Designer 2013.
I want to change to VSCODE since it supports a lot of extensions for some Javascript library like angular, jQuery. And because of the Chrome/Node.js debugger extension.
But when I try to start any Debugger, I got the error:
Unable to create 'launch.json' file inside the '.vscode' folder (Error: UNKNOWN: unknown error, mkdir '\\servername\DavWWWRoot\sitename\Style Library\.vscode').
I get this error because it's impossible to create a folder in SharePoint where the name starts with dot.
So there's a possibility to change the name of this folder or the file location to any directory in my local computer?
No, it's not possible to move/rename that folder. VS code is a tool that bases project management on folder content. So it is essential that the project settings reside in the folder being managed.
You can move the "extensions" folder, but unfortunately not the argv.json (so the ".vscode" will, at least be recreated on vscode launch)
https://github.com/microsoft/vscode/issues/17691#issuecomment-559234574
I hope that'll finally change sometime .
https://github.com/microsoft/vscode/issues/3884
https://github.com/OmniSharp/omnisharp-roslyn/issues/953
I want to deploy some front end assets to the local web root of a site using file replacement. I can't seem to get it to work with a relative path in the target location field though. Is it possible to do this though tds or should I use a post build event instead?
The reason these assets aren't included in a project is that they are part of a third party solution but we still want this tracked in source control to try to make the project setup easier.
Most developer machines will be set up the same way for this project with the same file structure but I think it's a little more flexible if I can make the target a relative path so I don't need to worry about differences like drive letters and such.
The folder structure is as follows:
repo
folderToCopy
sitecore
webroot
I have tried the following using ..'s based on what tds changed my source location to be while using the "Make selected Source Location relative" option (changed it from an absolute path to ..\folderToCopy\):
../../Sitecore/Website
/../../Sitecore/Website
..\..\Sitecore\Website
\..\..\Sitecore\Website
From my understanding, TDS does the file replacement based on the files published from the associated Website project.
You can then have relative replacements such as the following:
<Replacement Include=".\assets\folderToCopy\myFile.txt">
<TargetPath>.\assets\targetFolder\myFile.txt</TargetPath>
<IsFolder>False</IsFolder>
<IsRelative>True</IsRelative>
</Replacement>
I have not been able to successfully get TDS to use the file replacement with files that are in source control but not in the project.
My suggestion would be to set up a build event that will copy these files to the correct location, or to create a nuget feed for them and pull them in as nuget references.