I have just completed a fresh install of PyroCMS on a dev server and it appears that the system and addons folder reside above the document root folder within "public_html".
PyroCMS is based off of CodeIgniter and every time I did a CodeIgniter install it always had me place the system folder below the document root for security purposes. Shouldn't this be true with the PyroCMS install?
Modules require assets, which of course means HTTP access is required. We plan to eventually improve the Asset helper to GZIP/minify/combine everything and pass it through an "asset" controller, meaning images can be cached and resized, javascript can be squashed, etc.
Putting everything through a PHP file in this way means eventually you'll be able to have everything outside of the public folder, but for now you need direct access or you are entirely screwing with your chances of having a theme with images, css, javascript or icons.
Just don't tell Apache to serve PHP files as text/plain and you'll be absolutely fine. ;-)
Related
In Laravel 9 where it uses Vite to bundle the js and css files, after running
npm run build
it created the bundled js and css files inside public/build folder.
Can we now delete the original js and css files that are created inside resources? or to upload the project to hosting without this resources folder?
Also, if I have other css/js files but not inside Resources folder, should I add them manually to the input array inside the vite.config.js file to get them compiled and bundled ?
Thanks
It depends on the assets you have in resources directory.
This directory can hold un-compiled front-end assets such as CSS or JavaScript - those will be bundled and available in public folder and served from there, therefore it's safe to delete them on the shared hosting.
However, this directory can also hold backend assets like views, and those files will be read by Laravel directly on shared hosting. If you delete them, your Laravel application will crash.
Therefore, if the only assets you have in the folder are frontend ones that are bundled and served from public, it is safe to remove this directory, howevever there won't be any performance improvement coming from that.
Which folders I'm supposed to mark as Sources/Resources/Excluded?
My own logic based on the PHPStorm guide
Sources
The root folder
reasoning: Your source code can be in mutliple folder inside the root.
alternative: Just mark the real folder you have your code inside app, bootstrap, config, routes, (more...)
Click this button to mark the selected folder as the root for
namespaces used in your project. Based on this setting, PhpStorm
suggests you the proper folder name when you want to create a new
namespace under another parent namespace during creation or moving a
PHP class, that is, when you are actually creating or moving a PHP
class to a non-existing namespace under another parent namespace. If
no Sources folder is specified, you will have to type the proper
folder manually.
Appointing a Sources folder is not mandatory but this helps you keep
your project structure in compliance with the PSR0 and PSR4 standards.
See Configuring PHP Namespaces in a Project for details.
Tests
tests
reasoning: For obvious reasons your tests live there by default. It might be possible you use some test library for your javascript code that lives in another folder.
Click this button to mark the selected folder as a test root.
Excluded
vendor, storage, node_modules
reasoning: All (composer) libraries we use in our project live in vendor, but are not our own code. We should not search trough it by default.
In storage live caching files, files that have no significant meaning to us, we do not track them in version control (like vendor). We could just delete them and the application would still work. Same for node_modules, but this directory is for javascript packages.
Click this button to mark the selected folder as excluded so PhpStorm
ignores it during indexing, parsing, and code completion.
Resource Root
public
reasoning: Your own frontend assets should be (somewhere) under the public folder to serve to the browser. Frontend assets are (mostly?) files, javascript and css.
Click this button to enable PhpStorm to complete relative paths to
resources under the selected folder.
I got thrown this task because no one in my company understands websites, but I have only worked with very basic sites before, so I need help please. I haven't found another question quite like this one.
My company has an established site, running on Joomla 2.5, hosted on GoDaddy. They recently commissioned a company to build them a new site (not Joomla based), but want me to put it up on GoDaddy (saves money). The design company sent me a zip file, and GoDaddy told me to just move all the current site folders into one single folder, then unzip the site in the Public folder.
This is what I'm seeing in cPanel.
And this is what I see in FileZilla.
Do they really mean for me to move ALL these files to one folder? Or are there some I shouldn't touch, like the public_ftp folder? Or only move the files in the Public_html subfolder? Or only move files that are not in any folder?
Please be descriptive, I'm very new. Thanks in advance.
Joomla directories names are very intuitive. For most of them, you can guess the folder content just seeing it name. Basically we have these folders:
Any folder or file does not belong to joomla and therefore you should not move to the new subdirectory.
No changes are required in the database, so that all continue working on www.domain.com/oldweb
root: this is the directory where you made your Joomla pack extraction. When you first place Joomla on your web site, the root directory contains an index.php file that will run the Joomla installer. Once installed Joomla, this index.php page will detect your settings in the configuration.php file and execute your main Joomla engine.
administrator: In this directory you find all files for your Joomla administrator web interface (components, templates, modules, plugins, etc). The Administrator interface itself is a Joomla web site, and has a complete user interface that can be augmented by administrative extensions.
cache: This folder holds Joomla cache files. To accelerate performance, Joomla will cache popular pages requested in this directory, so they don’t have to be re-downloaded by PHP and MySQL for each time it is requested.
components: This directory holds all Joomla components, accept those for your administrator interface. By default, Joomla has some components available, such as login, newsfeeds, poll, registration, search, and others. They are ready to go, and can already displayed them in your website front-end.
images: This folder by default holds images used for your extensions. It contains all bitmaps used by the administrator interface as well as images that have been uploaded to present with article content. Within it you find the \smiles folder that contains emoticons; the \stories folder that has images; and the \banners folder that holds some sample banner files.
includes: In this directory you find core files of Joomla. It contains PHP execution files that automate inclusion of content.
installation: This folder contains needed files for Joomla installation. It should be deleted after installed Joomla.
language: This folder holds all language files. Joomla stores translations in a simple INI-based file format. All languages files are contained in it own folder and have filename prefix that matches the folder name. For example, all language files for English template from the country Great Britain are stored in a folder named eng-GB and all of them has a prefix eng-GB.
libraries: this directory holds your entire Joomla system and third-party libraries used in your website. A Joomla website uses the core libraries contained inside the \libraries folder. Within this folder you find the \joomla folder where you will see different implementations areas (such as file system, application, database, etc). These implementations make up the functional parts of your application. Its library has its own subfolder in this folder to aid in organization.
logs: Where Joomla stores its log files.
media: Default folder to store media files. It may contains files related with user interfaces, such as: JavaScript libraries, flash files, etc.
modules: This folder contains all installed front-end modules. It holds the modules available for display by a template. By default Joomla comes some modules, such as banners, breadcrumbs, latest news, login, newsflash, poll, random image, others. Modules are placed like panels into a Joomla template. They often encapsulate or provide the front-end display for related component. Like a component, a module is a type of add-on extension.
plugins: It contains all your plugins files. As well as components and modules, plugins are a type of add-on extension. However, they work at a lower level than components.
templates: This directory has all your frontend template files. You can notice that the name of each template subfolder must match the template it contains. By default Joomla brings some templates already done, and ready for use.
tmp: This folder stores temporary files and cookies that are used by the administrator and user interface of Joomla. Most of time, extensions’ files are copied to this folder during Joomla installation process.
I'm going to implement version control for a project via GitHub. It's a website using mostly PHP and JavaScript. And we're switching from one script to another. I'm using cPanel / ftp to access the files. I would prefer not to mess around with apache config files.
/home/website/ - home directory
/home/website/public_html/ - document root for website.com - has existing php script files which will be overwritten once the beta site is tested to be working properly
/home/website/public_html/beta.website.com/ - document root for beta.website.com - has existing php script files which have been minimally modified from the original vendor source. ie header / footer / config files.
/home/website/public_html/orig.website.com/ - a possible directory where I could update the original vendor files?
/home/website/public_html/addon-website.com/ - document root for another addon domain - completely separate website has nothing to do with the project
This script is to be used on many different websites. The difference would be in:
config files
template files
website specific changes
I have the original vendor source files on my local computer but no local web server. I need help in initial setup. How should I set things up so I can track all of the following:
track changes to the original vendor files done via patches and updates
track changes to 1 or many versions of the original script installed on different websites
track changes to a beta which has my own modifications to the vendor files
track website specific changes
push changes from vendor files to where I do my own modifications
push changes from my modifications to all different websites / website specific
I had a look at how do I maintain divergent code on github but I need more specific instructions than what is provided there. Should I even be trying to do this all in one repo with many branches / forks / whatever?
It would be beneficial to have an integration branch and each party to work on features that are merged there. This is the workflow that I developed with my colleagues and has worked out very well:
http://dymitruk.com/blog/2012/02/05/branch-per-feature/
For an introduction of Git itself, this is a very good resource:
http://git-scm.com/docs
I am trying to deploy a PHP Yii app to Orchestra (https://www.engineyard.com/products/orchestra/). The platform, like I think many cloud-based platform, doesn't allow write permissions.
I've managed to get around the 'runtime' directory that Yii requires by putting it in the system's tmp folder. However I'm stuck with the 'assets' folder. Yii requires a writable AND publicly accessible folder.
Is there a way around this?
Yii requires somewhere to put the files from within the core or modules to be publicly accessible.
If this isn't possible you might have to go through and manually grab each js/css file your going to want, place them in the folders required and use scriptMap to map these back or block them and include them yourself.
There's lots of documentation around Client Script which is what handles all this.