in a fresh silverstripe installation (3.0.5) there are many files where I wonder if I will ever need them or what their purpose is... so what I would like to have is a clean silverstripe installation and delete all unnecessary files/folders.
For what do I need these files/folders?:
phpunit.teamcity.mssql.xml
phpunit.teamcity.postgresql.xml
phpunit.teamcity.sqlite3.xml
phpunit.teamcity.xml
phpunit.xml.dist
test.php
web.config
vendor
many thanks for the clarification.
Florian
PHPUNIT / TeamCity
phpunit.teamcity.mssql.xml
phpunit.teamcity.postgresql.xml
phpunit.teamcity.sqlite3.xml
phpunit.teamcity.xml
phpunit.xml.dist
those are files used to configure php unit and team city (team city is a continuous integration software by jetbrains https://www.jetbrains.com/teamcity/)
(if you don't use teamcity, you can safely delete this files)
Web Server Config
.htaccess
this is the configuration file for apache web servers (if you don't use apache, you can delete this file)
web.config
this is for Microsoft IIS web servers, it is the equivalent to the .htaccess (if you don't use IIS as web server you can delete this file)
GIT (Version Control System)
.git/
.gitignore
.gitatributes
if you don't use git, you don't need them
Composer
composer.json
vendor/
the composer file holds information of php dependencies and where to get them.
the vendor folder is the folder where composer installs its dependencies
(composer is a php dependency manager which I can really recommend http://getcomposer.org/)
(if you do not use composer, you don't need them)
PHP files
index.php
fallback file in case mod_rewrite or the ISS equivalent is not working
install.php
the installer for SilverStripe, this file should be deleted after you installed SilverStripe
install-frameworkmissing.html
part of the installer
behat
behat.yml
I can't say much about behat because I don't use it, here is a quote from the website (http://behat.org/): "A php framework for testing your business expectations."
All I can say is that you can delete the file if you don't use behat
Other
test.php
no idea, I have never seen this file
README.md
obviously the readme file
CONTRIBUTING.md
a info file containing information on guidelines for contributing back to SilverStripe
Makefile
build.xml
Can't exactly say how to use those 2 files, but unless you do use them, you can delete them safely
tl;dr
the only files you really need is one of those 2:
if you are using apache (linux and mac but also windows) then you need to keep .htaccess
if you are IIS (windows server) then you need web.config
and the index.php if mod_rewrite is not available on your server
all other files are just for 3rd party software the core developers use
Related
A quick question:
which files or directories from Laravel 8 needs to be transferred to a production system or Muße the entire files and directories?
Well, yes, you have to move all the files including the vendor directory which has all the php dependencies (unless you can run composer install in production, in that case there's no need to upload the vendor directory). If you have local logs and cache in the storage directory, you can omit those.
You will also need to create a new .env file for production.
And, if your are using JavaScript with Laravel Mix, you don't need to upload the node_modules folder, only the compiled js or css files.
I'm new to this repository, I already installed it and it is working fine on Ubuntu 14.04. Now I want to personalize it and I've found everywhere that to avoid losing your customizations, you should place them in [dspace-source]/dspace/modules/xmlui/src/main/webapp/themes (I'm choosing xmlui since that is the interface I'm using and themes because that is the only customizations I want to do for now) and then you should do a mvn package from [dspace-source]/dspace for it to apply the changes to the installation directory ([dspace]). I have done this but the new theme I created doesn't appear in the installation directory. Should I do an ant update after the mvn package? Am I missing something for the documentation?
Thanks for the help!
You are correct. mvn package will build the code in dspace-source/target. ant update will copy the code from dspace-source/target to your installation directory. The maven build is generic and does not know your configuration settings. The ant task will read your configuration settings (which contain the install path).
After running ant update, you should restart tomcat.
Because the maven/ant cycles can take some time, I will occasionally make changes to uncompiled files (xsl, js, css) on the source branch and then copy them directly to the install branch.
Beware of making changes directly in the install branch since it is easy to overwrite with the ant command.
The cocoon layer of XMLUI does cache some files. If you make a change and it does not seem to take effect, sign in with an admin login and go to Administrative->Java Console->Clear Cache to force a change to be reloaded.
My understanding is that bootstrap/compiled.php is auto-generated by running php artisan optimize, and is only intended for performance gains on production servers. Therefore it shouldn't committed in version control.
Am I correct?
Correct - it should not be included in version control.
Laravel excludes this file by default in the .gitignore file included in the framework root:
.gitignore
/bootstrap/compiled.php
...
I have multiple projects with very little space to keep.
since most of them uses nearly same packages (only 1 uses phpexcel and the other one swiftmailer ) and vendor folder required biggest space on laravel.
I thought maybe I could use same vendor folder for every of them.
I actually messed with autoload.php and some other config files however I couldn't make it.
simply I'll put vendor folder under public_html and create folder like project1 project2.
under those folders I'll put everything about my projects except vendor folder and then make them subdomain.
Short answer:
You can't.
Long answer:
/vendor folder is not just about packages, you also have in there vendor/composer folder, where your application classes names are stored for autoloading purposes. Everytime you run composer dump-autoload, Composer changes the content of some files there. Take a look at the vendor/composer/autoload_classmap.php file, you'll see that some of those classes are from your own project.
Workaroud:
Please note that I don't see a thing like this going well, but you can, actually, create a blank project, just for package downloading and symlink all packages from all your vendors folders to that one. It's a lot of trouble for a little gain. But it's up to you, of course.
Source: http://www.wenda.io/questions/2416709/laravel-4-1-vendor-directory-config.html
edit composer.json
"config": {
"preferred-install": "dist",
"vendor-dir": "../vendor"
},
edit bootstrap/autoload.php file
require __DIR__.'/../../vendor/autoload.php'
edit bootstrap/start.php file
$framework = $app['path.base'].
'/../vendor/laravel/framework/src';
edit ../vendor/laravel/framework/src/Illuminate/Foundation/Console/Optimize/config.php
$basePath = $app['path.base'].'/../';
then run composer install, you will find vendor dir created ../
php artisan optimize -v --force
Generating optimized class loader
Compiling common classes
Before I put my very first (CodeIgniter) application on Github, I have a question about the CodeIgniter .gitignore file (see below). I do not have a development directory in my config directory. Can I just .gitignore */config/* instead? What is the importance of the development directory in the config directory?
*/config/development
*/logs/log-*.php
*/logs/!index.html
*/cache/*
*/cache/!index.html
Many people set up development and production folders in their config folders. Codeigniter will load the correct file from the correct folder depending on the environment you set in the main index.php
If you're creating a public repository on github copy the files with passwords and keys (your config.php and database.php are the only two that come standard with the framework I believe) to a new folder called development inside config, then remove the passwords and paths and things from the ones in the root folder. Leave the gitignore as is.
This way when you push to git you aren't pushing your personal private information to the project.