PHPackages effcore/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. [Framework](/categories/framework) 4. / 5. effcore/core ActiveProject[Framework](/categories/framework) effcore/core ============ EFFCORE — the next-generation mini-CMS/CMF 00PHP Since Apr 22Pushed 1y ago1 watchersCompare [ Source](https://github.com/effectivecore/core)[ Packagist](https://packagist.org/packages/effcore/core)[ RSS](/packages/effcore-core/feed)WikiDiscussions main Synced 1mo ago READMEChangelogDependenciesVersions (2)Used By (0) ``` ○○○○ ○○○○ ○○○○○ ○○○○○○ ○○○ ○○○ ○○○○○○○ ○○○○○○○○○○○○○○ ○○○○○○○ ○○○○○○○ ○○ ○○○ ○○○○○○○ ○○○○ ○○○○ ○○○○○○○○○○○○ ○○○ ○○○ ○○○ ○○○ ○○○ ○○○ ○○○ ○○○ ○○○ ○○○ ○○○ ○○ ○○ ○○ ○○ ○○ ○○ ○○○○○○○○○○○○○○ ○○○ ○○○ ○○ ○○ ○○ ○○ ○○○○○○○○○○○○○○ ○○○ ○○○ ○○○ ○○ ○○ ○○ ○○ ○○ ○○○○ ○○○○ ○○○ ○○○ ○○○ ○○○ ○○○ ○○○ ○○ ○○○ ○○○ ○○○○○○○ ○○○ ○○○ ○○○○○○○ ○○○○○○○ ○○ ○○○○○○○ ○○○○ ○○○○ ○○○○ ○○○○ ``` General information ------------------- [](#general-information) - Type: content management system/framework - Author: Maxim Rysevets - Developer: Maxim Rysevets - Start of development: end of 2016 - Initial release: 2022-01-01 - Written in: PHP - Supported OS: UNIX, Linux, Microsoft Windows - Supported web servers: NGINX, Apache, IIS - Supported databases: SQLite, MySQL - Is open source project: yes - License: proprietary software - Website: - Code repository: **EFFCORE** — the next-generation mini-CMS (Content Management System) and mini-CMF (Content Management Framework). It was developed between 2016 and 2024. Uses technologies such as: HTML5, CSS3, IP v6, SVG, SMIL, UTF8, UTC, WAI-ARIA, NoSQL, Markdown, UML, Composer, Docker… Can be used as a tool to create simple websites without the need for programming. It can be used as a tool for creating web portals and web services with the need to program additional functionality or search for ready-made solutions. The name of the System is an acronym and comes from the phrase `effective core`. The System was designed from scratch. Its main principle is the absence of third-party code (for the exclusion of legal claims), as well as the lack of third-party ideas (for the development of innovative solutions). The incentive for the creation of the System was the massive degradation in the development of Open Source projects. The first reason is the distributed development team. At its core, it is a group of people with different skill levels, different views and a weak level of coordination in such projects. The second reason is the approach to development itself. Instead of an intensive path of development, they chose an extensive one. An intensive development path involves the development of your own code and its close integration with other components of the System. The extensive way is to use ready-made libraries and assemble these libraries into something unified. At the same time, only a part of the functionality is used from each such library. Each such library was created for abstract purposes. As a result, the amount of code grows, the load on the equipment grows, the number of errors grows, the reliability and security decreases, and the functionality increases only slightly. The main emphasis in the System is on obtaining maximum performance. The evaluation criterion is a simple and understandable condition: the System installed on the hosting with the cheapest tariff plan should generate the main page in 0.01 second. This will allow up to ~100 requests per second to be served simultaneously. The plan must meet the minimum installation requirements and include basic features such as OPCache + JIT and a Solid State Drive. The approximate cost of the tariff plan should vary within $3-5 per month. Content management ------------------ [](#content-management) Any page in the System (except for the administrative interface) can have its own layout with a different number of regions. Each region can have any number of different blocks. Each block is any element of the System that has a block representation (menu, form, text, survey, and others). Localization ------------ [](#localization) The System interface can be translated into any language. The System already comes with some translations. You can change the interface language at any time using the *Management → Locale* section. In turn, any page (except for the administrative interface) can override the global settings and select a different language to match the language of the content on this page. Each page is configured in the section *Management → Data → Content → Pages*. The System implements a more advanced "Plural" system. This system allows you to insert any content from your function, depending on the value of the variable in the phrase. Example: `%%_number second%%_plural(number|s)` at `number = 1`will return `1 second`, and at `number = 10`will return `10 seconds`. **There are two ways to set up a multilingual website/web portal**: 1. organize as many copies of pages and blocks within one domain as many languages need to be supported (for example, `http://example.com/EN/about`); 2. organize a separate copy of the System for each language domain (for example, `http://EN.example.com/about`). **Note**: Both the first and second versions require duplicate pages and blocks in different languages. This approach is justified because often different language versions of content have differences not only in content, but also in structure. For example, the main menu in one language version may have some menu items, and in another — completely different — the names of these points and their addresses, and their number will also differ. In the module "Profile "Classic" you can see an example of the implementation of multilingualism according to method #1. Decoration ---------- [](#decoration) There is no such thing as a theme in the System. Instead of themes, a special kind of module called "Profile" is used. Any profile can contain the following types of elements: - pages; - page layouts; - blocks (menu, text, audio, video, galleries, selections, polls, etc.); - colors and color profiles; - templates in `*.tpl`/`*.data` files; - user styles in `*.css`/`*.cssd` files; - user scripts in `*.js`/`*.jsd` files; - files `robots.txt`, `sitemap.xml`; - any files that are copied to the System when deploying a profile; - and other elements that a typical module can generate. The profile is installed as a normal module. If you specify `enabled: yes` in the `module.data` profile file, then it will appear in the list of profiles on the System installation page. When a profile is enabled, it can either override any decoration settings or not make any changes, but only add additional features that the user can activate on their own. You should place profile files like any third-party modules in the `modules` directory. Otherwise, all changes may be lost during the update — when the System is brought to the reference copy from the repository. To work with the decoration in the administrative interface of the System, there is a section *Management → View*, which includes the following subsections: - *Colors → Management*: work with colors; - *Colors → Profiles*: work with color profiles; - *Layouts*: view available page layouts; - *Global CSS*: adding users CSS directives; - *Settings*: change the minimum and maximum width of all pages (this parameter can be overridden in the settings of each page); All layouts available in the System (as well as Selections with the design type "Table (adaptive)") are already able to adapt to the mobile version. File organization ----------------- [](#file-organization) The intuitive location of files in the System allows you to determine their purpose without resorting to documentation: - directories like `module_*/frontend` contain everything you need for frontend development; - directories like `module_*/backend` contain everything you need for backend development; - directories like `module_*/data` contain NoSQL data. The System has a built-in parser and class loader. The operation of files does not depend on their location and, if necessary, all files will be found and processed if they are located in the `modules` and `system` directories. The placement of the main System modules, third-party modules and library packages in the file system can be represented by the following scheme: ``` ├─ modules │ ├─ module_custom_0 │ ├─ module_custom_1 … │ ├─ module_custom_N │ │ ├─ backend │ │ ├─ data │ │ └─ frontend │ └─ vendors │ └─ packages │ ├─ package_0 │ ├─ package_1 … │ └─ package_N └─ system ├─ module_0 ├─ module_1 … └─ module_N ├─ backend ├─ data └─ frontend ``` You cannot make changes to the `system` directory, otherwise, when the System is updated, its contents will be restored to the reference copy and all changes in it will be lost. Third party modules should be placed in the `modules` directory. Library packages should be placed in the `modules\vendors\packages` directory. Information about modules and packages of libraries is stored in the cache, so when the state of their files changes, the cache should be reset. To reset the cache, go to the administrative interface in the section *Management → Modules → Install* and press the `↺` button. Architecture ------------ [](#architecture) The architecture is made according to the classic MVC scheme. Data is stored in SQL and NoSQL storages. Structured data uses SQL storage. For unstructured data (for example, forms, color profiles, tests, module settings), NoSQL storage is used. SQL and NoSQL are described in their respective sections. The System operates with two types of classes: 1. static factory classes; 2. pattern classes. In terms of quantitative composition, there are much more pattern classes than static factories. The description of instances of pattern classes (future PHP objects) is stored in NoSQL. At the moment of sampling this description, an instance (object) is created. The code of the System follows the DRY (Don't Repeat Yourself) and KISS (Keep It Short and Simple) principles. Each class consists of a small number of methods, consisting of a small number of lines. The code is adapted for reuse, and this approach greatly facilitates the perception of the code. The development process follows the following rules: - everything that seems complicated needs to be redone (each method can be iteratively rewritten 3 to 10 times); - for functional testing it is necessary to iterate over all possible combinations of arguments/parameters (complete set of combinatorial permutations), for check both the correct operation of the System and its components, and operation with obviously false values (for look for simple bugs and deliberate hacking attempts). In the *Develop → Structures → Diagram* section, a diagram of classes registered in the System is generated. There is also a link to download this diagram as a JSON file for the StarUML program. This section will become available after enabling the "Develop" module. In the *Develop → Console* section, you can enable the display of the console for developers. The console shows the order of actions for generating the page (calling classes, including files, triggering events, queries to the database and others). This section will become available after enabling the "Develop" module. There are basic tests in the *Develop → Tests* section. The "Security of Server Settings" test allows you to check server software for security. The "Security of Roles" test allows you to check the security of the project's role system. This section will become available after enabling the "Test" module. `*.data` format. NoSQL ---------------------- [](#data-format-nosql) One of the strengths of the project is the `*.data` format. It is similar to the YAML format, but has the following advantages: - more simple description; - more strict and unambiguous syntax; - faster parser; - allows you to describe future objects of any pattern classes; - each format line describes only one property and its value, for example, in this way: `key: value`; - changing one line in the `*.data` file changes one line in `git diff`. Example of `*.data` file: ``` example string: text string_empty: integer: 123 float: 0.000001 boolean: true null: null array - key_1: value 1 - key_2: value 2 - key_3: value 3 array_empty|_empty_array object property_name_1: value 1 property_name_2: value 2 property_name_3: value 3 object_empty object_text|Text text: some translated text ``` Such a file will be converted to a PHP file `/dynamic/cache/data--example.php`with content like the following: ``` Cache::$data['example'] = new \stdClass; Cache::$data['example']->string = 'text'; Cache::$data['example']->string_empty = ''; Cache::$data['example']->integer = 123; Cache::$data['example']->float = 0.000001; Cache::$data['example']->boolean = true; Cache::$data['example']->null = null; Cache::$data['example']->array['key_1'] = 'value 1'; Cache::$data['example']->array['key_2'] = 'value 2'; Cache::$data['example']->array['key_3'] = 'value 3'; Cache::$data['example']->array_empty = []; Cache::$data['example']->object = new \stdClass; Cache::$data['example']->object->property_name_1 = 'value 1'; Cache::$data['example']->object->property_name_2 = 'value 2'; Cache::$data['example']->object->property_name_3 = 'value 3'; Cache::$data['example']->object_empty = new \stdClass; Cache::$data['example']->object_text = new \effcore\Text; Cache::$data['example']->object_text->text = 'some translated text'; ``` When `Cache::select('example')` is called, this file will be loaded into memory and the data will become available without delay. **If PHP OPCache is used** then all data will be compiled into op-code and stored in shared memory, which will not take time to load a PHP file and parse it on every request. If **PHP JIT** is used, then parts of the code are already converted to bytecode and executed even faster. Using this format, a developer can describe **any structure with any level of nesting** — he is limited only by his imagination. For each line in this format, there are only the following notation variations: - `entity_name` - `entity_name|Class_name` - `object_property_name: value` - `- array_key_name: value` Each module can have any number of `*.data` files and place them anywhere, but traditionally all such files will be stored in the `data` directory of each module. **A set of such `*.data` files, as well as the mechanism for parsing, storing and retrieving them, is essentially a NoSQL storage.**In fact, this is a hybrid of a document-oriented, object-oriented and hierarchical database model. All `*.data` files are parsed once, when the cache is cleared. Cleaning the cache is a very rare procedure that is required only after updating the modules in the System. After parsing, all content is placed in the `dynamic/cache/data_original.php` file. Also, a separate file is created for each type of entity. Here is an example of such file organization: - `dynamic/cache/data--forms.php` - `dynamic/cache/data--pages.php` - `dynamic/cache/data--menus.php` When a change needs to be made to the NoSQL tree, the "Changes" mechanism is used. It describes what changes should be made to this tree. The process of making changes can be described by the following procedure: a full load of the NoSQL tree from the `data_original.php` file is performed, further changes are made to this tree, then, each entity of the NoSQL tree is saved file-by-file (example above). If there were no changes for any entity, the file is not overwritten. The "Changes" mechanism is also rarely used — mainly when saving System settings through the administrative interface. **Note**: An example of making changes is shown in the `test--data--changes.data` file of the "Test" module. The cache refresh rate does not exceed one second on average. The update rate via "Changes" is performed in tenths of a second. Thus, NoSQL works mostly in read mode and gives the best possible performance when using OPCache + JIT. SQL --- [](#sql) MySQL or SQLite can be used as SQL storage. Required versions can be found in the `docs/software.md` file. The main emphasis in the System is on ANSI SQL and cross-platform. The following features are supported: - checks `check` (SQLite, MySQL v.8+); - transactions `transaction` (`begin`, `rollback`, `commit`); - collations `collate` (`nocase`, `binary`); - constraints `constraint` (`primary`, `unique`, `foreign` with cascading action); - simple and unique indexes (`index`, `unique index`); - connection to additional storages through the process of manual initialization; - table prefixes. Foreign key cascading actions are supported: - for update: `cascade` (`restrict` and `no action` have not been tested); - for remove: `cascade` (`restrict` and `no action` have not been tested). Cross-platform field types are supported: - `autoincrement` - `varchar` (MySQL: `varchar` | SQLite: `text`) - `integer` (MySQL: `int` | SQLite: `integer`) - `real` (MySQL: `double` | SQLite: `real`) - `time` (MySQL: `time` | SQLite: `text`) - `date` (MySQL: `date` | SQLite: `text`) - `datetime` (MySQL: `datetime` | SQLite: `text`) - `boolean` (MySQL: `tinyint` | SQLite: `integer`) - `blob` (MySQL: `blob` | SQLite: `blob`) The set of specified types is sufficient for most tasks. Other types are allowed but have not been tested. It is recommended to use only these types to ensure cross-platform. Storing dates in **any RDBMS** has its own peculiarities. For example, the `timestamp` type stores the date as a number, so it has a small range of values — from `1970-01-01 00:00:01` UTC to `2038-01-19 03:14:07` UTC. Also an additional problem is its conversion to a timezone. Therefore, this type is not used in the System, but instead it is **recommended to use the `integer`** type. However, there is an ideal solution for full-fledged dates — this is **using the types `time`, `date` and `datetime`**. For example, the `date` and `datetime` types have wide ranges from `0001-01-01` to `9999-12-31` and are not tied to a time zone. When adding values to fields of these types, they should be converted to the UTC±0:00 time zone. **Note**: SQLite only supports 4 data types: `integer`, `real`, `text` and `blob`. If another type is used, then its value is cast to these base types. So `datetime` is cast to `text`, `boolean` to `integer`, and so on. Such an implementation does not control the integrity of the data domain, however, this System performs such control on the side of the form fields and it will be impossible to enter invalid values. **Note**: MySQL prior to version 8 did not support `check` checks, however this System implements such control on the side of form fields and it will be impossible to enter invalid values. **Note**: During the development process, PostgreSQL was excluded from support as a RDBMS that is the least compliant with ANSI standards and has features in working with `autoincrement` counters. Dynamic files ------------- [](#dynamic-files) There are special types of files in the System — these are **`*.cssd`**, **`*.jsd`**, **`*.svgd`**, **`*.htmld`**, **`*.txtd`**, **`*.xmld`** and possibly others if they were described as `kind: dynamic` in `file_types.data`. These files are **not cached** and are dynamically processed — for each request of this type of file, it is processed on the PHP side (if a handler function of this type or a handler function of all similar types was registered in the System). Dynamic processing makes it possible to organize the output of System variables in such files or perform any other operation with their content. An example of variables that can be used in dynamic files: ``` %%_color(main) %%_color(main|profile=dark|r=10|g=20|b=30|o=.5) %%_return_if_scope_is_dark(text|#000|#fff) %%_return_if_token(color\(text\)|#fff|1|0) %%_avatar_path %%_page_width_min(context) %%_page_width_max(context) %%_request(scheme) %%_request(host) %%_translation(simple string) ``` In fact: - *`*.cssd`* is a classic CSS file that contains cascading style sheets, but which may contain dynamic content; - *`*.jsd`* is a classic JS file containing JavaScript code, but which may contain dynamic content; - *`*.svgd`* is a classic SVG containing vector graphics in XML format, but which may contain dynamic content. **Note**: See `develop.cssd`for more examples. Event model ----------- [](#event-model) The System has a transparent and predictable event model. It is enough to find or create the `events.data` file in the **custom** module, specify the event handler function and its weight in it, and then reset the cache and the event will be processed. In the administrative interface of the System in the section *Develop → NoSQL data → Events* you can view all registered events. This section will become available after enabling the "Develop" module. Caching ------- [](#caching) The System architecture is designed in such a way as to work as quickly as possible and do not require page caching. On projects of any level, the System will work as fast as other systems with caching enabled. For heavily loaded projects, you can organize **page caching** using the NGINX, Apache or IIS web server, and no additional actions from the System are required. **Note**: Dynamic files are not cached (`*.cssd`, `*.jsd`, `*.svgd`and others). When organizing their caching, the developer takes full responsibility for updating such a cache. Performance improvement ----------------------- [](#performance-improvement) To improve performance, you should: - in PHP v.7+ enable OPCache; - in PHP v.8+ enable OPCache + JIT; - switch to Solid-State Drive (SSD); - transfer directories `dynamic/cache` and `dynamic/tmp` to RAM, at the same time, to increase the level of reliability of the web server, such RAM must support the error-correcting codes (ECC), and the server itself use an Uninterruptible Power Supply (UPS). The **best** way to improve performance is to cascade styles intelligently. This approach allows you to do without SAS and LESS preprocessors, the main task of which is to copy existing styles to many new elements, as a result of which the volume of each CSS file begins to multiply, and the very idea of cascading is leveled. A **good** way to improve performance is to minify JS files by reducing code by third party programs or services. It is also a good idea to move away from "heavy" libraries like jQuery and switch to CSS3 animation, SMIL animation, modern JavaScript and HTML5 features. The **controversial** way to increase performance is to enable GZIP streaming compression technology. This can be done using the NGINX, Apache, IIS web server. However, it should be remembered that compression and decompression of GZIP traffic leads to an increase in processor load, creates a delay when downloading and decompressing compressed traffic, and also reduces the battery life of a mobile device. Updates ------- [](#updates) System or module update provides: - new functionality; - bug fixes; - performance improvement; - security improvement. **To update files of the System manually**, you need to go to its official website [effcore.com](effcore.com) and download the current version of the distribution as an archive. Next, unpack the downloaded archive locally. **Important: The unpacked files include the `modules` and `dynamic` directories. In these directories you need to transfer files from an existing project.**Next, copy the resulting files to a web server. Third-party modules are updated separately. **To update files of the System or Module via Git repository**, go to the *Management → Modules → Update → Files from repository* section in the administrative interface of the System and click the "update" button. If the "update" button is not available, but the "restore repository" button is available, then you must first perform the procedure for restoring the repository. If the "update" and "restore repository" buttons are not available, then the System or Module does not have its own repository and it is impossible to update it via Git. **Updating files of the System via Git** can be performed **from the command line**by accessing the web server via an SSH connection, going to the `shell` directory and executing the `./update.sh` command. This update is only possible if there is a `.git` directory in the web root. Third-party modules are updated separately. **Updating files of the System and Modules via Composer** can be performed from the command line by logging into web server via SSH connection, going to web root, and executing the `composer update` command. This update is only possible if Composer is installed on the web server. All modules that were not added via `composer require` or were not registered in `composer.json`or `composer.lock` **will not be updated**. **After updating files of the System or Module, the data must be updated.**Such an update is performed in the section *Management → Modules → Update → Data*. Licensing --------- [](#licensing) The System is **open and free**. The license agreement is simple and minimalistic and does not restrict the rights of respectable users. According to the license agreement, malicious users who would like to give out this work as their own will already be out of the legal field. ### Health Score 13 — LowBetter than 1% of packages Maintenance26 Infrequent updates — may be unmaintained Popularity0 Limited adoption so far Community4 Small or concentrated contributor base Maturity21 Early-stage or recently created project How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Community Maintainers ![](https://www.gravatar.com/avatar/6e0a5d4ffac4e73f9069165361140a621b9e5c35087c4de555bcebffdb054d96?d=identicon)[effcore](/maintainers/effcore) ### Embed Badge ![Health badge](/badges/effcore-core/health.svg) ``` [![Health](https://phpackages.com/badges/effcore-core/health.svg)](https://phpackages.com/packages/effcore-core) ``` ### Alternatives [laravel/telescope An elegant debug assistant for the Laravel framework. 5.2k67.8M192](/packages/laravel-telescope)[spiral/roadrunner RoadRunner: High-performance PHP application server and process manager written in Go and powered with plugins 8.4k12.2M84](/packages/spiral-roadrunner)[nolimits4web/swiper Most modern mobile touch slider and framework with hardware accelerated transitions 41.8k177.2k1](/packages/nolimits4web-swiper)[laravel/dusk Laravel Dusk provides simple end-to-end testing and browser automation. 1.9k36.7M259](/packages/laravel-dusk)[laravel/prompts Add beautiful and user-friendly forms to your command-line applications. 708181.8M596](/packages/laravel-prompts)[cakephp/chronos A simple API extension for DateTime. 1.4k47.7M121](/packages/cakephp-chronos) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)