HashtagCms, Use it as Headless CMS or Bundled, API enabled, Admin Panel, multisite, multi-tenant, multiplatform, multilingual with endless possibilities. The Most powerful, fast, user-friendly and secured platform. Made with PHP Laravel Framework.
After having problems of different nature, I was compelled to install everything from fresh. Due to this, I have customized everything multiple times. The time invested in customizing it becomes useless, when starting from fresh. There is a ZERO chance to import the old data. SQL inserts does not help.
When one begins to customize, php scripts begins to create IDs in database. The next time, you may not follow the same sequence of customization. This results into different IDs. There does not exists any absolute system default of creating IDs. They are installed relative to the pattern followed by the administrator.
Concept:
I suggest to abolish the relative IDs from everywhere.
The HashtagCMS core Controllers (all) will create and inherit (absolute or script generated) IDs, wherever possible, based on specific logic. These IDs will not be based on SQL record_ids.
Implementation:
Table: sites
At the time one adds the site, the Controller uses the first four alphabets and the first two alphabets of a domain, convert it into a number to create the site_id. The field id in site table will be used only for SQL purpose.
For HashtagCMS.com, the Controller will calculate the following based on alphabets mapping to numbers, a--->01, b--->02, etc:
If the site has less than four alphabets/numbers, it will add defaults.
Advantages:
All other tables will hold references from this site--->site_id 080119080315 everywhere. The advantage of this system will be:
1.
Because the site--->site_id 080119080315 will be generated by the scripts based on specific logic related to the domain itself, like five alphabets/numbers, etc., it will always remain the same within the database.
It can be used later on because the same scripts will generate the same IDs.
2.
Applying this logic, one could extend the concept to other areas, like currency, languages, etc.
These IDs will remain the same everywhere as well as between the backups and different databases.
3.
The absolute referencing system opens doors to export and imports amongst database versions and backups.
4.
One could update databases based on absolute_ids.
All the records within the database will have absolute reference and shall not be relative to particular installation any more.
Had this system be in there, then I could have imported SQL INSERT queries. This would help starting from fresh and thereafter executing custom queries based on absolute_ids.
Almost all CMS use relative IDs based on SQL record_ids. Due to this, other CMS have an inborn drawback mentioned in above four aspects.
Hello Marghoob,
After having problems of different nature, I was compelled to install everything from fresh. Due to this, I have customized everything multiple times. The time invested in customizing it becomes useless, when starting from fresh. There is a ZERO chance to import the old data. SQL inserts does not help.
When one begins to customize, php scripts begins to create IDs in database. The next time, you may not follow the same sequence of customization. This results into different IDs. There does not exists any absolute system default of creating IDs. They are installed relative to the pattern followed by the administrator.
Concept: I suggest to abolish the relative IDs from everywhere.
The HashtagCMS core Controllers (all) will create and inherit (absolute or script generated) IDs, wherever possible, based on specific logic. These IDs will not be based on SQL record_ids.
Implementation: Table: sites At the time one adds the site, the Controller uses the first four alphabets and the first two alphabets of a domain, convert it into a number to create the site_id. The field id in site table will be used only for SQL purpose.
For HashtagCMS.com, the Controller will calculate the following based on alphabets mapping to numbers, a--->01, b--->02, etc:
h = 08 a = 01 s = 19 h = 08 c = 03 o = 15
The Table: sites will have:
id | site_id | name | category_id | etc.
01 | 080119080315 | Hashtag CMS | 1 | 1 | 1 | 1 | 110 | 0 | HashtagCMS.com | etc.
If the site has less than four alphabets/numbers, it will add defaults.
Advantages: All other tables will hold references from this site--->site_id 080119080315 everywhere. The advantage of this system will be:
1. Because the site--->site_id 080119080315 will be generated by the scripts based on specific logic related to the domain itself, like five alphabets/numbers, etc., it will always remain the same within the database.
It can be used later on because the same scripts will generate the same IDs.
2. Applying this logic, one could extend the concept to other areas, like currency, languages, etc.
These IDs will remain the same everywhere as well as between the backups and different databases.
3. The absolute referencing system opens doors to export and imports amongst database versions and backups.
4. One could update databases based on absolute_ids.
All the records within the database will have absolute reference and shall not be relative to particular installation any more.
Had this system be in there, then I could have imported SQL INSERT queries. This would help starting from fresh and thereafter executing custom queries based on absolute_ids.
Almost all CMS use relative IDs based on SQL record_ids. Due to this, other CMS have an inborn drawback mentioned in above four aspects.