I have been working with CodeIgniter since 2 years. But I have no idea about following highlighted files.
What are them?
What happens if I remove them?
.editorconfig -> here's the website. It's a configuration file to keep settings / code styles for certain IDE's.
.gitignore is a file used by git version control system which tell it which files should be IGNORED by git.
composer.json is a file used by Composer dependency manager (for PHP libraries), and that file lists library dependencies, versions, required php extensions and their versions which are needed for the code to run properly.
contributing.md isn't a special file, it's just a markdown-formatted file that contains instructions left there by the author. You can see that StackOverflow, Github and many other popular programming-related websites use markdown and display it as nicely formatted HTML after parsing.
You should really know what GIT and Composer are, so I suggest checking out the links I posted and implementing a bit of google-fu to get up to speed with current tech!
.editorconfig: This is a file to set coding style in IDE
.gitignore: This file is for git. You can tell GIT,that certain files are not allowed to be loaded into git.
composer.json: This file is for the libraries in php. It controls the loading and includes all dependencies.
contributing.md: Contains guidelines for contribution, for example, in an open-source project this file plays an important role to provide guidelines for coding standards.
I suggest you keep those files, especially the first three files. DON'T delete them.
Related
I'm currently working on setting up a custom admin page for a specific task I need to do and it requires some custom styling in the theme. I went to the themes/SuiteP/css folder and found admin.scss. After making a change, I had assumed that Suite would dynamically compile the asset since I am developer mode; however, that did not happen.
I decided to search the code for any place I could find that would deal with compiling those files to *.css, but found no such place.
My question involves inquiring as to where that compilation takes place and/or how it takes place. Right now it appears as if I have to manually compile those assets, which seems pointless because it is just an extra step I have to manually take, rendering using SCSS less useful in comparison with CSS.
Right now, my solution will probably have to be adding a CSS file that has nothing to do with whatever pipeline exists, but if I can leverage existing functionality, that would great.
Due to legacy issues with the SugarCRM framework, SuiteCRM loads style.css for current theme. The sass work for SuiteCRM is in a transitioning period. It is currently a manual process, but we hope to make it automated in the future.
We are using Sass as a way to allow developers to customise the SuiteP theme. I have a github project which provides a UI to generate the variables.scss for you. I am hoping that it will be accepted in a future release.
So in regards to your workflow you only need to care about the style.css.
If you want to contribute back to the SuiteCRM project, then you will need to use the sass files in themes/SuiteP/css/.
However, if this is just for your instance of SuiteCRM, then you will want to create a style.css in the custom/themes/SuiteP/css/style.css. How you change that is up to you.
I would recommend that you use Sass to generate the style.css.
You can achieve this by copying the style.scss file custom/themes/SuiteP/css and then add the following to the file
#import ../../../../themes/SuiteP/css/style.scss
Note: I may have the path slightly wrong
or use the command line tools to include the themes/SuiteP/css/ directory
See for details:
SASS: Import a file from a different directory?
SuiteCRM should pick up the rest of the work. There is a change in SuiteCRM 7.9 that deprecates the $sugarcrm_version in favour of $suitecrm_version. This will effect theme themedef.php.
See for details
https://github.com/salesagility/SuiteCRM/pull/3233/files
I hope this answers your question.
Our current development setup uses a single Subversion repository containing multiple projects, each with branches, tags, and trunk. We then use a "sparse checkout" to select the projects, and branches of those projects, to work with.
The result is that the directory structure of a working copy matches that of the repository, including branch information, and we never use svn switch. (This style of working will probably be familiar to anyone who uses SVN, but may be surprising to those who don't.)
We are thinking of using Composer to manage both external and internal dependencies, but I'm not sure how this can work with the sparse checkout style of working.
I would like some way of using a directory within the existing checkout to satisfy a dependency, rather than each "root project" needing a separate copy.
For example:
sites/Foo/trunk
depends on lib Aaa, so references lib/Aaa/trunk
depends on lib Bbb 1.5.*, so references lib/Bbb/branches/release-1.5
sites/Bar/trunk
depends on lib Aaa 1.0.*, so references lib/Aaa/branches/release-1.0
depends on lib Bbb 1.5.*, so references lib/Bbb/branches/release-1.5
At present, if I edit the code in lib/Bbb/branches/release-1.5, I can test those changes on both sites, without needing to commit one and update the other.
Is there any way of using Composer to manage these dependencies?
(PS: Please don't answer with "give up on SVN, use Git, it is teh awesomez"; that is an answer to a different question.)
No - I do not believe that you can do this with Composer as standard: it expects to copy the files from whichever source (Packagist/VCS/Zips) to the local vendor folder, which is not what you want.
That said, I believe there are two potential ways you could get this working (at least in part):
Autoloader
You could try using the autoload field in the composer.json file to include the correct files into the project. You would still need to manage the checkouts of the relevant branches/versions manually (like I assume you do now), but you would be able to manage the inclusion of the internal libraries through Composer. This will probably require that your libraries are properly namespaced. The paths to the files for each namespace are relative to the root of the project, but can go below the root (via the /../ path) if required.
To be honest though, if you already have an autoloader for these files, there may not be much advantage to this solution. Relevant Docs
Composer Plugin
You could also write a composer plugin/"custom installer" that could probably manage this. This would have the advantage that you could have it manage checking out the correct parts of the sparse repository to have the correct version available, as well as doing correct wildstar version checking, but would be a much more difficult and riskier venture.
The basic process would be that you would define a new package type (e.g. 'internal-svn-package'). You would create the plugin as an external library that gets installed normally via Composer, which declares (via it's composer.json) that it handles this new type of package. Your custom logic would then be used for any packages that are listed with this custom type. I'm not sure how much of the internal composer logic for SVN checkouts you would be able to reuse however. Relevant Docs
I have been looking into incorporating an asset management/pipelining tool (probably Assetic) into my PHP project.
Since assets can be grouped into collections or wildcard-based paths using such tools, if I wanted to set up a watch process that re-compiled/minified only those source files that had changed, how would I do that given that assets have to be looked up by name (see example below)?
(I noticed that for Symfony there's a watch task for Assetic but I'm not sure that it re-compiles only the changed file(s) and also I would have to make it work outside of Symfony since my app uses the CodeIgniter framework.)
In Assetic, you can create a wildcard-based asset, e.g.:
new GlobAsset('/path/to/compass-sources/*')
You can tell it to send the assets through a filter (Compass in this example) and then output the result (CSS) to a folder like public/css.
Let's say I set up the watch process using node.js's fs.watch so that I can theoretically tell Assetic to re-compile a particular asset whenever one of its source files changes.
Since my node.js script would only know the name of the actual file that changed (e.g. compass-sources/layout.scss), how could I look up which AssetCollection or GlobAsset that particular file belonged to (say an asset called global-styles) in order to recompile it?
I'm open to alternatives here. I looked at grunt and may very well use grunt-contrib-watch to handle the file watching, but I like the idea of using Assetic because the project is in PHP and I think that will be easier on future PHP developers working on the system who may not be familiar with node.js. It seems grunt take a different approach where assets don't necessarily go in named bundles. Mostly I want to understand the conceptual approach of named asset bundles (like in Assetic) as it relates to my goal of recompiling assets whenever the source files change.
I use ecplise for my php projects.
I want to have an external location for all my plugins and link specific plugins to each of my projects.
I found how to link folders etc, but the actual files aren't copied in the folder, resulting in errors in the website because the files are missing. They are only inside my project.
How can I link an actual folder to my eclipse project, that is being updated automatically from the source?
In Visual Studio there is an option to copy specific resources to the output folder. I am looking for something similar here.
Some things come to mind:
I don't know if such an option exists. You could achieve that with build tools, that just to the copy on build. You wouldn't then need to reference the files in eclipse any longer then however.
You can configure the PHP include path in your project. Then you can configure the include in your application the same. Might not solve all your issues, but would work cross compatible.
I am brand new at sub-versioning, so please bear with me.
I use CollabNet's Subversion Edge to manage a repository for a PHP/ActionScript based project I am building in the Eclipse IDE. In my project's root folder, Eclipse included several configuration files that aren't directly related to the project. How can I set up my repository to ignore these files/folders via CollabNet? Would it be through the "Repository Access Rules"?
Thank you for your time.
The "Chapter 3. Advanced Topics 'Ignoring Unversioned Items'" seems appropriate for your setup:
Extract:
[...] But these not-to-be-versioned files and directories can cause some annoyance for Subversion users.
For example, because the svn add and svn import commands act recursively by default, and don't know which files in a given tree you do and don't wish to version, it's easy to accidentally add stuff to version control that you didn't mean to.
And because svn status reports, by default, every item of interest in a working copy–including unversioned files and directories–its output can get quite noisy where many of these things exist.
So Subversion provides two ways for telling it which files you would prefer that it simply disregard.
One of the ways involves the use of Subversion's runtime configuration system (see the section called “Runtime Configuration Area”), and therefore applies to all the Subversion operations which make use of that runtime configuration, generally those performed on a particular computer, or by a particular user of a computer.
The other way makes use of Subversion's directory property support, is more tightly bound to the versioned tree itself, and therefore affects everyone who has a working copy of that tree. Both of the mechanisms use file patterns.
The Subversion runtime configuration system provides an option, global-ignores, whose value is a whitespace-delimited collection of file patterns (also known as globs).
The Subversion client checks these patterns against the names of the files which are candidates for addition to version control, as well as to unversioned files which the svn status command notices.
If any file's name matches one of the patterns, Subversion will basically act as if the file didn't exist at all.
This is really useful for the kinds of files that you almost never want to version, such as editor backup files like Emacs' *~ and .*~ files