PHPackages tigron/skeleton-core - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Utility & Helpers](/categories/utility) 4. / 5. tigron/skeleton-core ActiveLibrary[Utility & Helpers](/categories/utility) tigron/skeleton-core ==================== Core functionality for Skeleton v5.2.3(11mo ago)019.8k↓30%311MITPHP Since Aug 18Pushed 11mo ago4 watchersCompare [ Source](https://github.com/tigron/skeleton-core)[ Packagist](https://packagist.org/packages/tigron/skeleton-core)[ RSS](/packages/tigron-skeleton-core/feed)WikiDiscussions master Synced 1mo ago READMEChangelog (10)DependenciesVersions (94)Used By (11) skeleton-core ============= [](#skeleton-core) Description ----------- [](#description) This library contains the core functionality of the `skeleton` framework. It performs these main tasks: - Autoloading - Config management - Application detection - HTTP toolkit Installation ------------ [](#installation) Installation via composer: ``` composer require tigron/skeleton-core ``` After installation you can start a skeleton project. Features -------- [](#features) ### Autoloading [](#autoloading) Skeleton doesn't enforce you to use a specific file structure. This means that skeleton can adapt itself to your structure. In order to do so, you need to configure the skeleton autoloader. Autoloading can be configured like this: ``` /** * Register the autoloader */ $autoloader = new \Skeleton\Core\Autoloader(); $autoloader->add_include_path($root_path . '/lib/model/'); $autoloader->add_include_path($root_path . '/lib/base/'); $autoloader->add_include_path($root_path . '/lib/component/'); $autoloader->add_include_path($root_path . '/tests'); $autoloader->register(); ``` Skeleton autoloader will include the given include paths in its search for the requested class. An optional parameter 'class\_prefix' can be given. This will prepend all classes for a given path with the given prefix: ### Config management [](#config-management) Skeleton core offers a Config object that is populated from a given config directory. The Config object automatically includes all php files which are stored in the config directory. Each php file should return a php array. Each key/value pair will be available in your project. Include a config directory ``` \Skeleton\Core\Config::include_path('/config'); ``` PHP files stored in the config directory will be evaluated in alphabetical order. In case you have environment-specific configuration, you can create a file `environment.php` in your config directory which will be evaluated last. Get a config object ``` $config = \Skeleton\Core\Config::get(); ``` Skeleton needs at least these config items to operate properly: ConfigurationDescriptionDefault valueExample valuesapplication\_pathSets the directory where skeleton-core can find Applications'app/'asset\_pathsAn array containing optional paths to search for assets\[\]\[ 'lib/external/assets' \]### Application detection [](#application-detection) The package will automatically detect "applications", which are separate parts of your project. The following application types are available: - [skeleton-application-web](https://github.com/tigron/skeleton-application-web): A web application. - [skeleton-application-api](https://github.com/tigron/skeleton-application-api): An Openapi interface - [skeleton-application-dav](https://github.com/tigron/skeleton-application-dav): A webdav interface Based on the `Host`-header in the request, the correct application will be started. This is where the `hostnames` array in the application's configuration file (shown above) will come into play. If `skeleton-core` could find a matching application based on the `Host`-header. It is the responsibility of the application to finish the HTTP request. Applications are identified in the $application\_path and should respect at least the following directory structure: ``` - {application_path} - {APP_NAME} - config - event ``` The application config directory should contain the application-specific configuration files. The following configuration directives should at least be set: ConfigurationDescriptionDefault valueExample valuesapplication\_type(optional)Sets the application to the required type\\Skeleton\\Application\\Webhostnames(required)an array containing the hostnames to listen for. Wildcards can be used via `*`.\[\]\[ '[www.example.be](http://www.example.be), '\*.example.be' \]session\_nameThe name given to your session'App'any stringsticky\_session\_nameThe key in your session where sticky session information is stored'sys\_sticky\_session'any string### HTTP toolkit [](#http-toolkit) Altough skeleton can be used for a console application, it has an HTTP toolkit available. It can: - accept an HTTP request and pass it to the correct application - serve media files - session management #### HTTP handler [](#http-handler) The HTTP handler will accept an incoming HTTP request and searches for the correct application based on the HTTP host header. To run the HTTP handler: ``` \Skeleton\Core\Http\Handler::Run(); ``` It will then pass the request over to the application. The application will be set via: ``` \Skeleton\Core\Application::set(); ``` In the lifespan of the request, the application can always be retrieved via: ``` \Skeleton\Core\Application::get(); ``` #### Serve media [](#serve-media) Media serving is only done for known filetypes. The known filetypes are: css, map, pdf, txt, woff, woff2, ttf, otf, eot, gif, jpg, jpeg, png, ico, svg, js, html, htm, mp4, mkv Any other file extensions will be ignored. Media serving can be requested via: ``` \Skeleton\Core\Http\Media::detect($request_uri); ``` The asset will be searched for in the following order: 1. The media directory of the current Application 2. The configured asset\_paths 3. The media directory of other skeleton packages ### Events [](#events) Events can be created to perform a task at specific key points during the application's execution. Events are defined in `Event` context classes. These classes are optional, but when they are used, they should be located in the `event` directory of your application. The filename should be in the form of `Context_name.php`, for example `Application.php`. The class should extend from `Skeleton\Core\Application\Event\{Context}` and the classname should be within the namespace `\App\APP_NAME\Event\{Context}`, where `APP_NAME` is the name of your application, and `Context` is one of the available contexts: - Application - Error - Media Depending on the type of Application you are running, additional events could be available. Please read the application-type Readme for more information. Example of a `Module` event class for an application named `admin`: ```