Please look at the bottom of this page (under Support Policy Summary) for our support policy summary, containing important information regarding our working hours and our support policy. Thank you!
EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.
Description of my issue:
THIS IS A VERY LONG POST - I hope it details my issue effectively and that someone can at least explain if it's supposed to work this way.
I came across an unusual situation with the creation of a column in a table during the Akeeba restore process. A little background to try to summarize:
1. I have a "start point" that I use to begin each website that we build. Each time there are updates to the components we use, Joomla, the framework, etc, I create a new one of these so that the next few sites are built on a common base with things that I know are defaults we prefer.
2. To eliminate the possibility of specific company info getting into this file, I began doing this as a generic site name as well as a generic database table prefix.
3. In my last iteration of this, I made the db table prefix "start_" and this would be typically changed during the Akeeba restore process on the page where the database name, user id, etc is supplied.
Here's the issue:
In the table called finder_links, there is a column/field that is called "start_date", so with my case the structure would be like this:
Site as trsstart.mydomain.com
database as trsstart_dbname
so, with a prefix of "start_" the above table would be start_finder_links
and the field SHOULD be start_date (as usual)
But when I use Akeeba to restore, that field ends up being "databaseprefix_date" - literally.
So when I do the restore and set the database prefix to be not "start_" but something else like "client_"
the FIELD in the table called client_finder_links becomes "client_date" instead of "start_date"
So when a component goes to write to the expected start_date field, it doesn't exist and it fails. If I go into the phpmyadmin and change the field name to start_date, everything works again.
I found the code in the table creation in the standard Joomla installation and it looks like this:
CREATE TABLE IF NOT EXISTS `#__finder_links` (
...
`start_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
...
but in the Akeeba ANGIE /installation/sql/site.s01 on line 10, it shows this (highlighted where I think the issue is):
CREATE TABLE `#__finder_links` ( `link_id` int(10) unsigned NOT NULL AUTO_INCREMENT, `url` varchar(255) NOT NULL, `route` varchar(255) NOT NULL, `title` varchar(400) DEFAULT NULL, `description` text, `indexdate` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `md5sum` varchar(32) DEFAULT NULL, `published` tinyint(1) NOT NULL DEFAULT '1', `state` int(5) DEFAULT '1', `access` int(5) DEFAULT '0', `language` varchar(8) NOT NULL, `publish_start_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `publish_end_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `#__date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `end_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `list_price` double unsigned NOT NULL DEFAULT '0', `sale_price` double unsigned NOT NULL DEFAULT '0', `type_id` int(11) NOT NULL, `object` mediumblob NOT NULL, PRIMARY KEY (`link_id`), KEY `idx_type` (`type_id`), KEY `idx_md5` (`md5sum`), KEY `idx_url` (`url`(75)), KEY `idx_published_list` (`published`,`state`,`access`,`publish_start_date`,`publish_end_date`,`list_price`), KEY `idx_published_sale` (`published`,`state`,`access`,`publish_start_date`,`publish_end_date`,`sale_price`), KEY `idx_title` (`title`(100)) ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4;
you can see that all of the fields are normal except that one, which is called out as "#__date" - I suppose grabbing the prefix name and plugging it in rather than having a literal "start_date" there.
Am I losing my mind? It seems like a coincidence. If I leave the prefix as START_ everything works fine because it plugs that in as the same. None of this happened before I started using the "start_" prefix. Is it special. Is there any other word I shouldn't be using?
Thanks for any help on this! :)
EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.
Description of my issue:
THIS IS A VERY LONG POST - I hope it details my issue effectively and that someone can at least explain if it's supposed to work this way.
I came across an unusual situation with the creation of a column in a table during the Akeeba restore process. A little background to try to summarize:
1. I have a "start point" that I use to begin each website that we build. Each time there are updates to the components we use, Joomla, the framework, etc, I create a new one of these so that the next few sites are built on a common base with things that I know are defaults we prefer.
2. To eliminate the possibility of specific company info getting into this file, I began doing this as a generic site name as well as a generic database table prefix.
3. In my last iteration of this, I made the db table prefix "start_" and this would be typically changed during the Akeeba restore process on the page where the database name, user id, etc is supplied.
Here's the issue:
In the table called finder_links, there is a column/field that is called "start_date", so with my case the structure would be like this:
Site as trsstart.mydomain.com
database as trsstart_dbname
so, with a prefix of "start_" the above table would be start_finder_links
and the field SHOULD be start_date (as usual)
But when I use Akeeba to restore, that field ends up being "databaseprefix_date" - literally.
So when I do the restore and set the database prefix to be not "start_" but something else like "client_"
the FIELD in the table called client_finder_links becomes "client_date" instead of "start_date"
So when a component goes to write to the expected start_date field, it doesn't exist and it fails. If I go into the phpmyadmin and change the field name to start_date, everything works again.
I found the code in the table creation in the standard Joomla installation and it looks like this:
CREATE TABLE IF NOT EXISTS `#__finder_links` (
...
`start_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
...
but in the Akeeba ANGIE /installation/sql/site.s01 on line 10, it shows this (highlighted where I think the issue is):
CREATE TABLE `#__finder_links` ( `link_id` int(10) unsigned NOT NULL AUTO_INCREMENT, `url` varchar(255) NOT NULL, `route` varchar(255) NOT NULL, `title` varchar(400) DEFAULT NULL, `description` text, `indexdate` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `md5sum` varchar(32) DEFAULT NULL, `published` tinyint(1) NOT NULL DEFAULT '1', `state` int(5) DEFAULT '1', `access` int(5) DEFAULT '0', `language` varchar(8) NOT NULL, `publish_start_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `publish_end_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `#__date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `end_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `list_price` double unsigned NOT NULL DEFAULT '0', `sale_price` double unsigned NOT NULL DEFAULT '0', `type_id` int(11) NOT NULL, `object` mediumblob NOT NULL, PRIMARY KEY (`link_id`), KEY `idx_type` (`type_id`), KEY `idx_md5` (`md5sum`), KEY `idx_url` (`url`(75)), KEY `idx_published_list` (`published`,`state`,`access`,`publish_start_date`,`publish_end_date`,`list_price`), KEY `idx_published_sale` (`published`,`state`,`access`,`publish_start_date`,`publish_end_date`,`sale_price`), KEY `idx_title` (`title`(100)) ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4;
you can see that all of the fields are normal except that one, which is called out as "#__date" - I suppose grabbing the prefix name and plugging it in rather than having a literal "start_date" there.
Am I losing my mind? It seems like a coincidence. If I leave the prefix as START_ everything works fine because it plugs that in as the same. None of this happened before I started using the "start_" prefix. Is it special. Is there any other word I shouldn't be using?
Thanks for any help on this! :)
