Forums / Upgrading to 1.5.x / database writing problem...

database writing problem...

Results 1 to 20 of 26
17 Oct 2015, 17:49
#1
pepperfire avatar

pepperfire

New Zenner

Join Date:
Apr 2008
Posts:
93
Plugin Contributions:
0

database writing problem...

I've managed to install the V154, gotten everything working beautifully, rescued my db from 1.39h except my Define Main_Page isn't working as it should.

The Define Pages editor is trying to write to the db, and indeed it appears to do so. BUT, it isn't saving to the database.

The address in the resulting (kickedout of the admin, now your main page doesn't exist) page is: https://peppermaster.com/stage/shop/admin/define_pages_editor.php?lngdir=english&filename=define_main_page.php&action=save (I've replaced the name of my admin) So, it's supposedly doing it's thing, but the resulting page is painted with my main site visual at peppermaster.com. So, possibly the Define Pages is having an addressing problem with its save as it's not finding the file because the ZC is on the stage root and not the main root.

It is NOT happening with the other pages in define Pages, just Main page; which was written within Define Pages as well as they. So, it's striking me very odd.

To add insult to injury, the db I rescued came from a bilingual ZC v. 138, so I believe the DP may be WRITING to that bilingual page, which doesn't exist, but I'm not getting an error message.

I've verified all of the install files to see what I've overwritten and if it is something in the files, I've missed it, I'm at a loss for which file to look in.

I looked in the logs and caches, and really can't figure out what is going wrong there either.

Perhaps something I rescued is telling the file to save to the bilingual page, but I don't know where THAT is.

So, if anyone can tell me where to find the code that tells the admin to write the copy from the Define Pages Main Page to the db, it would be greatly appreciated.

Also, if you have a thought for the fix that I haven't thought of, please offer that as well.)

Thanks
17 Oct 2015, 21:12
#2
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,907
Plugin Contributions:
1

Re: database writing problem...

Define pages are not written to the database, they are written to files in the includes/languages/YOUR_LANGUAGE/html_includes/YOUR_TEMPLATE/define_xxx.php files if the file exists in YOUR_TEMPLATE otherwise it writes to the html_includes directory. This writing is performed by the define_pages_editor.php file located in your admin directory and references file locations identified in your admin/includes/configure.php file... If the installation was done in accordance with iinstruction such as http://www.zen-cart.com/entry.php?3-How-do-I-rebuild-my-site-on-the-new-version-instead-of-upgrading then the includes/configure.php and admin/includes/configure.php files should both be pointing to the correct base folder structure and editing the file(s) following the above structure.Further, when the define_main_page.php is selected for edit, the line above the text box area should provide the complete folder/file path for the file being edited... If that file path matches your expected location, then perhaps the file has access permissions set on it that prevent editing.As to the discussion of logs, the error logs in a default install of ZC 1.5.4 are directed to the logs directory off of the root of the store and are also identified in the above two configure.php files. Perhaps posting those to files (obscuring admin directory and db credentials) will shed some light on the issue if the above doesn't help.Please when posting identify what actions were attempted, what reviews were performed and the success/failure of each... This will help those helping you and possibly someone that ends up having the same issue.
17 Oct 2015, 23:36
#3
pepperfire avatar

pepperfire

New Zenner

Join Date:
Apr 2008
Posts:
93
Plugin Contributions:
0

Re: database writing problem...

mc12345678:

Define pages are not written to the database, they are written to files in the includes/languages/YOUR_LANGUAGE/html_includes/YOUR_TEMPLATE/define_xxx.php files if the file exists in YOUR_TEMPLATE otherwise it writes to the html_includes directory. This writing is performed by the define_pages_editor.php file located in your admin directory and references file locations identified in your admin/includes/configure.php file...


All good and well. THE save is NOT writing to the file, it is bouncing me out to the main page of my site. If I go back, I am back into the admin I was just kicked out of.

mc12345678:

If the installation was done in accordance with iinstruction such as http://www.zen-cart.com/entry.php?3-How-do-I-rebuild-my-site-on-the-new-version-instead-of-upgrading then the includes/configure.php and admin/includes/configure.php files should both be pointing to the correct base folder structure and editing the file(s) following the above structure.


I would love to have been able to do that, but I was unfortunately not in receipt of a build file showing WHAT had been added by the previous admin and had to fly by the seat of my pants to do that. So, NO, that procedure was not followed.

I am, at this point simply trying to save my data. Be that as it may, the includes/configure and the admin/includes/configure both point where they should as is testified by the fact that ALL of the other define pages, save just fine. As I said I am simply rescuing db files from the old version. I am not working with the same set up at all. The saving of the database has been done line by line. I'd have loved to have done this the "easy" way you describe.

mc12345678:

Further, when the define_main_page.php is selected for edit, the line above the text box area should provide the complete folder/file path for the file being edited... If that file path matches your expected location, then perhaps the file has access permissions set on it that prevent editing.


The define_main_page.php is set to 644, just like all the other define pages. So THAT is not the problem.

mc12345678:

As to the discussion of logs, the error logs in a default install of ZC 1.5.4 are directed to the logs directory off of the root of the store and are also identified in the above two configure.php files. Perhaps posting those to files (obscuring admin directory and db credentials) will shed some light on the issue if the above doesn't help.


That's a useful log file to have. I've been using the cache file and saving to the db when not in production.

The log file reads:

[09-Mar-2015 17:01:00 Europe/Paris] PHP Warning: require_once(C:/Program Files (x86)/EasyPHP-DevServer-14.1VC11/data/localweb/projects/product/plugins/riCjLoader/RiCjLoaderPlugin.php): failed to open stream: No such file or directory in C:\Program Files (x86)\EasyPHP-DevServer-14.1VC11\data\localweb\projects\productbackup\includes\init_includes\init_ricjloader.php on line 12

[09-Mar-2015 17:01:00 Europe/Paris] PHP Fatal error: require_once(): Failed opening required 'C:/Program Files (x86)/EasyPHP-DevServer-14.1VC11/data/localweb/projects/product/plugins/riCjLoader/RiCjLoaderPlugin.php' (include_path='.;C:\php\pear') in C:\Program Files (x86)\EasyPHP-DevServer-14.1VC11\data\localweb\projects\productbackup\includes\init_includes\init_ricjloader.php on line 12


I have searched the files using the admin developers tool and I find NO code calling the "require_once" listed in the log. THAT is the file/db entry -- whichever it might be, that I seek.

I don't have these files in the copy of our old site that I have. So, obviously there is a module that I missed. I have no right clue what it is or where it is written into my code.

I have searched to find out what the file it's looking for and I cannot find that either.

mc12345678:

Please when posting identify what actions were attempted, what reviews were performed and the success/failure of each... This will help those helping you and possibly someone that ends up having the same issue.


The only actions I am attempting is to SAVE the edits to the define page in the define editor. When I hit enter it resorts to main site's page not found. There is no error message, other than what is in that log file.

I appreciate the help. I'm scratching my head here.

Also please forgive me if you think I'm not quite speaking your language. I am self-taught here and I think my teacher is a drunk. ;)
18 Oct 2015, 00:15
#4
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,907
Plugin Contributions:
1

Re: database writing problem...

Nope, language seems fine. Basically all the questions/actions were described throughout, thoough one question is not specifically answered (path of define_main_page.php when attempting to edit it).

So the next thing to discover/understand is what the content is being entered? Though, technically to get the content immediately pushed to the site you could directly edit the file using a plain text editor...

If posting the content please enclose in [noparse]
[/noparse] tags created by pressing the # symbol in the message reply toolbar.
18 Oct 2015, 00:46
#5
rodg avatar

rodg

Deceased

Join Date:
Jan 2007
Posts:
6,263
Plugin Contributions:
3

Re: database writing problem...

Pepperfire:


It is NOT happening with the other pages in define Pages, just Main page; which was written within Define Pages as well as they. So, it's striking me very odd.


Odd. but very useful. There isn't really much that could cause this symptom.

Pepperfire:


To add insult to injury, the db I rescued came from a bilingual ZC v. 138, so I believe the DP may be WRITING to that bilingual page, which doesn't exist, but I'm not getting an error message.


It's probably nothing to do with the DB, but could (probably is) related being bilingual.

Pepperfire:


So, if anyone can tell me where to find the code that tells the admin to write the copy from the Define Pages Main Page to the db, it would be greatly appreciated.

Also, if you have a thought for the fix that I haven't thought of, please offer that as well.)



Suggestion:

Replace the /includes/languages/english/html_includes/YOURTEMPLATE/define_main_page.php with a copy of one of the other define_* pages that you know is editable, then try to edit it (as the define_main_page). Only make a minor edit before resaving.

Whether it saves or not will determine your next step. Assuming it does save OK, revert back to the original main page.php (you made a backup right?) - Open it into the editor. Highlight and select/copy all contents. Revert back to the editable file, and replace its contents with your copied version, then resave.

Cheers
RodG
18 Oct 2015, 01:56
#6
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,907
Plugin Contributions:
1

Re: database writing problem...

Pepperfire:

I would love to have been able to do that, but I was unfortunately not in receipt of a build file showing WHAT had been added by the previous admin and had to fly by the seat of my pants to do that. So, NO, that procedure was not followed.

Actually if you still have the fileset you can download an old copy of the previous ZC version from http://www.zen-cart.com/getit and compare the clean version against the "old" version, but at this point I'd wait to do this until a functional version was up...

Pepperfire:

That's a useful log file to have. I've been using the cache file and saving to the db when not in production.

The log file reads:

[09-Mar-2015 17:01:00 Europe/Paris] PHP Fatal error: require_once(): Failed opening required 'C:/Program Files (x86)/EasyPHP-DevServer-14.1VC11/data/localweb/projects/product/plugins/riCjLoader/RiCjLoaderPlugin.php' (include_path='.;C:\php\pear') in C:\Program Files (x86)\EasyPHP-DevServer-14.1VC11\data\localweb\projects\productbackup\includes\init_includes\init_ricjlo ader.php on line 12


I have searched the files using the admin developers tool and I find NO code calling the "require_once" listed in the log. THAT is the file/db entry -- whichever it might be, that I seek.

I don't have these files in the copy of our old site that I have. So, obviously there is a module that I missed. I have no right clue what it is or where it is written into my code.

I have searched to find out what the file it's looking for and I cannot find that either.



The problem file (causing the logged error but not necessarily causing the issue of the OP) is: C:\Program Files (x86)\EasyPHP-DevServer-14.1VC11\data\localweb\projects\productbackup\includes\init_includes\init_ricjlo ader.php

Because it is in the init_includes folder (and likely called by another loader elsewhere to be discovered after removal of that file) it is trying to do it's thing which it can not because of whatever else is missing or not right.

I'm pretty sure someone will say that should address the original issue first... Regardless keep track of what you're doing, what needs to be done, and while I suggest enjoying your Saturday don't get to be like your teacher. :P
18 Oct 2015, 05:17
#7
kobra avatar

kobra

Black Belt

Join Date:
Aug 2005
Posts:
31,500
Plugin Contributions:
4

Re: database writing problem...

I would love to have been able to do that, but I was unfortunately not in receipt of a build file showing WHAT had been added...
The saving of the database has been done line by line

Can you outline then how you have upgraded
Please explain what steps you are taking to perform your "line by line" statement
18 Oct 2015, 15:26
#8
pepperfire avatar

pepperfire

New Zenner

Join Date:
Apr 2008
Posts:
93
Plugin Contributions:
0

Re: database writing problem...

kobra:

Can you outline then how you have upgraded
Please explain what steps you are taking to perform your "line by line" statement


I installed version 1.54 clean, then began adding the modules I know are in the old cart. (http://www.peppermaster.com/product). I took great care to go line by line through each of the files for the modules as I did so.

Then I exported the database for 1.54 and I migrated data line by data line all of the information I could save from the old db. Literally. I have been working at this a long time already.

I thought everything was working perfectly because I experienced no problems with the clean site, so I started to paint the CSS. Unfortunately, I keep breaking things and discovering new things missing, or things like some file I installed not uploading correctly. I don't expect to discover that the file error is even remotely connected to this, but I have been going into the cache file to find the error and fixing them one by one. The log file, is useful to the extreme. Glad to learn of that file's existence.

It seems everytime I fix something, something new breaks. So, I fix that. I expect that once I fix THIS problem I will find others that need fixing as well. I'm VERY old school. I have no other knowledge of how to trouble shoot the upgrade of this site any other way.

I don't know what I'm doing, but I'm trying very well. I'm quite proud of what I've accomplished.

At this moment, I have a couple of suggestions, it seems I have two problems (unrelated) to fix. As someone above noted, I will perform the suggestions posted and come back with my results.

Thanks to you and everyone who posted for their help!
18 Oct 2015, 17:46
#9
kobra avatar

kobra

Black Belt

Join Date:
Aug 2005
Posts:
31,500
Plugin Contributions:
4

Re: database writing problem...

I migrated data line by data line all of the information I could save from the old db

That is really not the way to do this at all

I suggest that you backup the DB that you have worked on and save it locally

Then do a full backup of your live site DB(make sure to check "add drop table" statement when doing this) - and import it into your 1.5.4 DB

Then run zc_install and select upgrade DB only

You should then be good to go
20 Oct 2015, 20:57
#10
pepperfire avatar

pepperfire

New Zenner

Join Date:
Apr 2008
Posts:
93
Plugin Contributions:
0

Re: database writing problem...

kobra:

That is really not the way to do this at all

I suggest that you backup the DB that you have worked on and save it locally

Then do a full backup of your live site DB(make sure to check "add drop table" statement when doing this) - and import it into your 1.5.4 DB

Then run zc_install and select upgrade DB only

You should then be good to go


That worked beautifully right until I go into the back office or the db and I get nada and I'm back to starting from scratch again. No clients, no products, no history. I've got a lovely brand new empty ready to do ZC 1.54 though.

http://www.peppermaster.com/stage/shop2

The log files for the experience:

---------------
Oct 20 2015 20:27 -- inspect
/admin/includes/configure.php does not exist

---------------
Oct 20 2015 20:27 -- inspect
FATAL: store configure.php is not writeable

---------------
Oct 20 2015 20:34 -- database_upgrade
NOTE: Skipped upgrade statements: 25 - See details at bottom of page for your inspection. - (Details also logged in the "upgrade_exceptions" table.) - Note: In most cases, these failed statements can be ignored, - as they are indications that certain settings may have already been set on your site. - If all the suggested upgrade steps have been completed (no recommendations left), - you may proceed to Skip Upgrades and continue configuring your site.

---------------
Oct 20 2015 20:35 -- database_upgrade
NOTE: Skipped upgrade statements: 4 - See details at bottom of page for your inspection. - (Details also logged in the "upgrade_exceptions" table.) - Note: In most cases, these failed statements can be ignored, - as they are indications that certain settings may have already been set on your site. - If all the suggested upgrade steps have been completed (no recommendations left), - you may proceed to Skip Upgrades and continue configuring your site.


and

---------------
Oct 20 2015 19:43 -- inspect
System Inspection Results:
------------------------------
NA: Webserver => Apache
NA: HTTP Host => peppermaster.com
NA: Path_Translated => /home/pepperma/public_html/stage/shop2/zc_install/index.php(SCRIPT_FILENAME)
NA: Real Path => /home/pepperma/public_html/stage/shop2
NA: Server Free Disk Space => 1133.38 GB
NA: PHP O/S => Linux
NA: PHP API Mode => cgi-fcgi
NA: PHP Max Execution Time per page => 90
OK: Register Globals => OFF
OK: MySQL Support => ON
OK: PHP Version => 5.3.29
OK: PHP Safe Mode => OFF
OK: PHP Sessions Support => ON
OK: PHP Session.AutoStart => OFF
OK: PHP session.use_trans_sid => OFF
OK: Suggested SQL Cache Folder => /home/pepperma/public_html/stage/shop2/cache
OK: PHP magic_quotes_runtime setting => OFF
OK: PHP magic_quotes_sybase setting => OFF
OK: PHP GD Support => ON
OK: GD Version => GD bundled (2.1.0 compatible)
OK: PHP ZLIB Compression Support => ON
OK: PHP OpenSSL Support => ON
OK: PHP cURL Support => ON
OK: CURL NON-SSL Capability => Okay
OK: CURL SSL Capability => Okay
OK: PHP Upload Support => ON upload_max_filesize=64M; post_max_size=64M
OK: PHP Upload TMP dir =>
OK: Apache .htaccess Support => ON
NA: PHP include_path => .:/opt/alt/php53/usr/share/pear:/opt/alt/php53/usr/share/php
NA: PHP SMTP destination => localhost
NA: PHP sendmail path => /usr/sbin/sendmail -t -i
NA: PHP sendmail 'from' =>
OK: PHP open_basedir restrictions =>
OK: PHP Output Buffering (gzip) => ON
OK: PHP XML Support => ON
OK: PHP Session.Save_Path => /home/pepperma/public_html/stage/shop2/cache-->Writeable
OK: includes/configure.php => Writeable
OK: admin/includes/configure.php => Writeable
OK: cache => OK 777 read/write/execute
OK: images => OK 777 read/write/execute (INCLUDE SUBDIRECTORIES TOO)
OK: includes/languages/english/html_includes => OK 777 read/write (INCLUDE SUBDIRECTORIES TOO)
OK: logs => OK 777 read/write/execute
OK: media => OK 777 read/write/execute
OK: pub => OK 777 read/write/execute
OK: admin/backups => OK 777 read/write
OK: admin/images/graphs => OK 777 read/write/execute
PHP Extensions compiled: Core, date, ereg, libxml, openssl, pcre, sqlite3, zlib, bz2, calendar, ctype, curl, hash, filter, ftp, gettext, gmp, SPL, iconv, pcntl, readline, Reflection, session, standard, shmop, SimpleXML, exif, tokenizer, xml, cgi-fcgi, bcmath, dom, enchant, fileinfo, gd, imagick, imap, intl, json, mbstring, mcrypt, mysql, mysqli, mysqlnd, PDO, pdo_mysql, pdo_sqlite, Phar, posix, pspell, sockets, tidy, wddx, xmlreader, xmlrpc, xmlwriter, xsl, zip, mhash, ionCube Loader, SourceGuardian, Zend Guard Loader
------------------------------


---------------
Oct 20 2015 20:04 -- database_setup1
Installer - Page: database_setup -- collected information: Array
(
[language] => english
[DIR_FS_SQL_CACHE] => /home/pepperma/public_html/stage/shop2/cache
[DB_TYPE] => mysql
[DB_PREFIX] =>
[DB_CHARSET] => utf8
[DB_SERVER] => localhost
[DB_SERVER_USERNAME] => pepperma_admin
[DB_SERVER_PASSWORD] => ***private***
[DB_DATABASE] => pepperma_shop2
[SQL_CACHE_METHOD] => file
)


---------------
Oct 20 2015 20:27 -- inspect
/admin/includes/configure.php does not exist

---------------
Oct 20 2015 20:27 -- inspect
FATAL: store configure.php is not writeable

---------------
Oct 20 2015 20:27 -- inspect
System Inspection Results:
------------------------------
NA: Webserver => Apache
NA: HTTP Host => peppermaster.com
NA: Path_Translated => /home/pepperma/public_html/stage/shop2/zc_install/index.php(SCRIPT_FILENAME)
NA: Real Path => /home/pepperma/public_html/stage/shop2
NA: Server Free Disk Space => 1133.43 GB
NA: PHP O/S => Linux
NA: PHP API Mode => cgi-fcgi
NA: PHP Max Execution Time per page => 90
OK: Register Globals => OFF
OK: MySQL Support => ON
OK: PHP Version => 5.3.29
OK: PHP Safe Mode => OFF
OK: PHP Sessions Support => ON
OK: PHP Session.AutoStart => OFF
OK: PHP session.use_trans_sid => OFF
OK: Current SQL Cache Folder => /home/pepperma/public_html/stage/shop2/cache-->Writeable
OK: Suggested SQL Cache Folder => /home/pepperma/public_html/stage/shop2/cache
OK: PHP magic_quotes_runtime setting => OFF
OK: PHP magic_quotes_sybase setting => OFF
OK: PHP GD Support => ON
OK: GD Version => GD bundled (2.1.0 compatible)
OK: PHP ZLIB Compression Support => ON
OK: PHP OpenSSL Support => ON
OK: PHP cURL Support => ON
OK: CURL NON-SSL Capability => Okay
OK: CURL SSL Capability => Okay
OK: PHP Upload Support => ON upload_max_filesize=64M; post_max_size=64M
OK: PHP Upload TMP dir =>
OK: Apache .htaccess Support => ON
NA: PHP include_path => .:/opt/alt/php53/usr/share/pear:/opt/alt/php53/usr/share/php
NA: PHP SMTP destination => localhost
NA: PHP sendmail path => /usr/sbin/sendmail -t -i
NA: PHP sendmail 'from' =>
OK: PHP open_basedir restrictions =>
OK: PHP Output Buffering (gzip) => ON
OK: PHP XML Support => ON
OK: PHP Session.Save_Path => /home/pepperma/public_html/stage/shop2/cache-->Writeable
FAIL: includes/configure.php => <span class='errors'>Unwriteable</span>
FAIL: admin/includes/configure.php => NOT FOUND
OK: cache => OK 777 read/write/execute
OK: images => OK 777 read/write/execute (INCLUDE SUBDIRECTORIES TOO)
OK: includes/languages/english/html_includes => OK 777 read/write (INCLUDE SUBDIRECTORIES TOO)
OK: logs => OK 777 read/write/execute
OK: media => OK 777 read/write/execute
OK: pub => OK 777 read/write/execute
WARN: admin/backups => <span class='errors'>Unwriteable</span> 777 read/write
WARN: admin/images/graphs => <span class='errors'>Unwriteable</span> 777 read/write/execute
PHP Extensions compiled: Core, date, ereg, libxml, openssl, pcre, sqlite3, zlib, bz2, calendar, ctype, curl, hash, filter, ftp, gettext, gmp, SPL, iconv, pcntl, readline, Reflection, session, standard, shmop, SimpleXML, exif, tokenizer, xml, cgi-fcgi, bcmath, dom, enchant, fileinfo, gd, imagick, imap, intl, json, mbstring, mcrypt, mysql, mysqli, mysqlnd, PDO, pdo_mysql, pdo_sqlite, Phar, posix, pspell, sockets, tidy, wddx, xmlreader, xmlrpc, xmlwriter, xsl, zip, mhash, ionCube Loader, SourceGuardian, Zend Guard Loader
------------------------------


---------------
Oct 20 2015 20:29 -- inspect
System Inspection Results:
------------------------------
NA: Webserver => Apache
NA: HTTP Host => peppermaster.com
NA: Path_Translated => /home/pepperma/public_html/stage/shop2/zc_install/index.php(SCRIPT_FILENAME)
NA: Real Path => /home/pepperma/public_html/stage/shop2
NA: Server Free Disk Space => 1133.45 GB
NA: PHP O/S => Linux
NA: PHP API Mode => cgi-fcgi
NA: PHP Max Execution Time per page => 90
OK: Register Globals => OFF
OK: MySQL Support => ON
OK: PHP Version => 5.3.29
OK: PHP Safe Mode => OFF
OK: PHP Sessions Support => ON
OK: PHP Session.AutoStart => OFF
OK: PHP session.use_trans_sid => OFF
OK: Current SQL Cache Folder => /home/pepperma/public_html/stage/shop2/cache-->Writeable
OK: Suggested SQL Cache Folder => /home/pepperma/public_html/stage/shop2/cache
OK: PHP magic_quotes_runtime setting => OFF
OK: PHP magic_quotes_sybase setting => OFF
OK: PHP GD Support => ON
OK: GD Version => GD bundled (2.1.0 compatible)
OK: PHP ZLIB Compression Support => ON
OK: PHP OpenSSL Support => ON
OK: PHP cURL Support => ON
OK: CURL NON-SSL Capability => Okay
OK: CURL SSL Capability => Okay
OK: PHP Upload Support => ON upload_max_filesize=64M; post_max_size=64M
OK: PHP Upload TMP dir =>
OK: Apache .htaccess Support => ON
NA: PHP include_path => .:/opt/alt/php53/usr/share/pear:/opt/alt/php53/usr/share/php
NA: PHP SMTP destination => localhost
NA: PHP sendmail path => /usr/sbin/sendmail -t -i
NA: PHP sendmail 'from' =>
OK: PHP open_basedir restrictions =>
OK: PHP Output Buffering (gzip) => ON
OK: PHP XML Support => ON
OK: PHP Session.Save_Path => /home/pepperma/public_html/stage/shop2/cache-->Writeable
OK: includes/configure.php => Writeable
OK: admin/includes/configure.php => Writeable
OK: cache => OK 777 read/write/execute
OK: images => OK 777 read/write/execute (INCLUDE SUBDIRECTORIES TOO)
OK: includes/languages/english/html_includes => OK 777 read/write (INCLUDE SUBDIRECTORIES TOO)
OK: logs => OK 777 read/write/execute
OK: media => OK 777 read/write/execute
OK: pub => OK 777 read/write/execute
OK: admin/backups => OK 777 read/write
OK: admin/images/graphs => OK 777 read/write/execute
PHP Extensions compiled: Core, date, ereg, libxml, openssl, pcre, sqlite3, zlib, bz2, calendar, ctype, curl, hash, filter, ftp, gettext, gmp, SPL, iconv, pcntl, readline, Reflection, session, standard, shmop, SimpleXML, exif, tokenizer, xml, cgi-fcgi, bcmath, dom, enchant, fileinfo, gd, imagick, imap, intl, json, mbstring, mcrypt, mysql, mysqli, mysqlnd, PDO, pdo_mysql, pdo_sqlite, Phar, posix, pspell, sockets, tidy, wddx, xmlreader, xmlrpc, xmlwriter, xsl, zip, mhash, ionCube Loader, SourceGuardian, Zend Guard Loader
------------------------------


---------------
Oct 20 2015 20:29 -- inspect
System Inspection Results:
------------------------------
NA: Webserver => Apache
NA: HTTP Host => peppermaster.com
NA: Path_Translated => /home/pepperma/public_html/stage/shop2/zc_install/index.php(SCRIPT_FILENAME)
NA: Real Path => /home/pepperma/public_html/stage/shop2
NA: Server Free Disk Space => 1133.45 GB
NA: PHP O/S => Linux
NA: PHP API Mode => cgi-fcgi
NA: PHP Max Execution Time per page => 90
OK: Register Globals => OFF
OK: MySQL Support => ON
OK: PHP Version => 5.3.29
OK: PHP Safe Mode => OFF
OK: PHP Sessions Support => ON
OK: PHP Session.AutoStart => OFF
OK: PHP session.use_trans_sid => OFF
OK: Current SQL Cache Folder => /home/pepperma/public_html/stage/shop2/cache-->Writeable
OK: Suggested SQL Cache Folder => /home/pepperma/public_html/stage/shop2/cache
OK: PHP magic_quotes_runtime setting => OFF
OK: PHP magic_quotes_sybase setting => OFF
OK: PHP GD Support => ON
OK: GD Version => GD bundled (2.1.0 compatible)
OK: PHP ZLIB Compression Support => ON
OK: PHP OpenSSL Support => ON
OK: PHP cURL Support => ON
OK: CURL NON-SSL Capability => Okay
OK: CURL SSL Capability => Okay
OK: PHP Upload Support => ON upload_max_filesize=64M; post_max_size=64M
OK: PHP Upload TMP dir =>
OK: Apache .htaccess Support => ON
NA: PHP include_path => .:/opt/alt/php53/usr/share/pear:/opt/alt/php53/usr/share/php
NA: PHP SMTP destination => localhost
NA: PHP sendmail path => /usr/sbin/sendmail -t -i
NA: PHP sendmail 'from' =>
OK: PHP open_basedir restrictions =>
OK: PHP Output Buffering (gzip) => ON
OK: PHP XML Support => ON
OK: PHP Session.Save_Path => /home/pepperma/public_html/stage/shop2/cache-->Writeable
OK: includes/configure.php => Writeable
OK: admin/includes/configure.php => Writeable
OK: cache => OK 777 read/write/execute
OK: images => OK 777 read/write/execute (INCLUDE SUBDIRECTORIES TOO)
OK: includes/languages/english/html_includes => OK 777 read/write (INCLUDE SUBDIRECTORIES TOO)
OK: logs => OK 777 read/write/execute
OK: media => OK 777 read/write/execute
OK: pub => OK 777 read/write/execute
OK: admin/backups => OK 777 read/write
OK: admin/images/graphs => OK 777 read/write/execute
PHP Extensions compiled: Core, date, ereg, libxml, openssl, pcre, sqlite3, zlib, bz2, calendar, ctype, curl, hash, filter, ftp, gettext, gmp, SPL, iconv, pcntl, readline, Reflection, session, standard, shmop, SimpleXML, exif, tokenizer, xml, cgi-fcgi, bcmath, dom, enchant, fileinfo, gd, imagick, imap, intl, json, mbstring, mcrypt, mysql, mysqli, mysqlnd, PDO, pdo_mysql, pdo_sqlite, Phar, posix, pspell, sockets, tidy, wddx, xmlreader, xmlrpc, xmlwriter, xsl, zip, mhash, ionCube Loader, SourceGuardian, Zend Guard Loader
------------------------------


---------------
Oct 20 2015 20:34 -- database_upgrade
NOTE: Skipped upgrade statements: 25 - See details at bottom of page for your inspection. - (Details also logged in the "upgrade_exceptions" table.) - Note: In most cases, these failed statements can be ignored, - as they are indications that certain settings may have already been set on your site. - If all the suggested upgrade steps have been completed (no recommendations left), - you may proceed to Skip Upgrades and continue configuring your site.

---------------
Oct 20 2015 20:35 -- database_upgrade
NOTE: Skipped upgrade statements: 4 - See details at bottom of page for your inspection. - (Details also logged in the "upgrade_exceptions" table.) - Note: In most cases, these failed statements can be ignored, - as they are indications that certain settings may have already been set on your site. - If all the suggested upgrade steps have been completed (no recommendations left), - you may proceed to Skip Upgrades and continue configuring your site.


So, now I'm back to the starting point a nd I still don't have the db. Was it your intent to make me cry about this stupid thing again? maybe I should just go hire some shopify account and have done with it?

I'm sorry if this seems really simple to you, but now I'm just more confused than ever because, this should be so simple. And it really isn't.

So, I really do appreciate any help here.
20 Oct 2015, 22:23
#11
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,907
Plugin Contributions:
1

Re: database writing problem...

Well it looks like *A* database is present and an outdated one at that... (Likely your old database.) Need to upload the zc_install directory, then access it to do a database only upgrade...
20 Oct 2015, 22:26
#12
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,907
Plugin Contributions:
1

Re: database writing problem...

Be sure to upload it to the above path so that only touching this database and not your live store.
20 Oct 2015, 22:33
#13
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,907
Plugin Contributions:
1

Re: database writing problem...

Also, in trying to access your admin, did you get to a point to provide your login credentials and then actually provide them? Hopefully not, yet...
21 Oct 2015, 01:20
#14
barco57 avatar

barco57

Totally Zenned

Join Date:
Apr 2006
Posts:
2,841
Plugin Contributions:
0

Re: database writing problem...

Do you actually have a copy of the original 1.3.9 database from before the upgrade? If you do, drop all tables in the 1.5.4, import the 1.3.9 DB into the 1.5.4 database, then run the zcinstaller and process the DB upgrade. That will update your database from 1.3.9 to 1.5.4....now the only problem you are going to have is if when building out the 1.5.4 you ran sql files for addon modules, parts/pieces of them maybe present if those modules were installed in the 1.3.9 but if you try and run some of them again to put them in you will most likely run into mysql error for stuff already being present. That's a slightly harder nut to crack, as it requires knowledge of how to work in phpmyadmin to pull configs out of the configurations table based on the group_id, copy those out, and delete them, then you can run the sql file to add the newer version back in and you can then make any adjustments to setting from inside the admin based on what you copied out and set aside.....confused yet? It does take patience and attention to detail to not screw it up. but its the kind of thing I run into again and again while doing upgrades.
If you had started out correctly by doing the upgrade on the original database you would have been better off and would only have to copy over those customers and orders that were new since you started working on the upgrade.
21 Oct 2015, 01:44
#15
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,907
Plugin Contributions:
1

Re: database writing problem...

barco57:

Do you actually have a copy of the original 1.3.9 database from before the upgrade? If you do, drop all tables in the 1.5.4, import the 1.3.9 DB into the 1.5.4 database, then run the zcinstaller and process the DB upgrade. That will update your database from 1.3.9 to 1.5.4....now the only problem you are going to have is if when building out the 1.5.4 you ran sql files for addon modules, parts/pieces of them maybe present if those modules were installed in the 1.3.9 but if you try and run some of them again to put them in you will most likely run into mysql error for stuff already being present. That's a slightly harder nut to crack, as it requires knowledge of how to work in phpmyadmin to pull configs out of the configurations table based on the group_id, copy those out, and delete them, then you can run the sql file to add the newer version back in and you can then make any adjustments to setting from inside the admin based on what you copied out and set aside.....confused yet? It does take patience and attention to detail to not screw it up. but its the kind of thing I run into again and again while doing upgrades.
If you had started out correctly by doing the upgrade on the original database you would have been better off and would only have to copy over those customers and orders that were new since you started working on the upgrade.


This is not the recommended method of upgrading, especially if a problem occurs while trying to upgrade the original database for the first time which could disable the store until the issue is resolved... Which could be an extended period of time for one not so familiar with the process that has just been described to circumvent.

Further by running this process on a development location all of the so called SQL install issues can be addressed in that environment so that such SQL clashes will not occur on the upgrade of the live site.
21 Oct 2015, 15:34
#16
barco57 avatar

barco57

Totally Zenned

Join Date:
Apr 2006
Posts:
2,841
Plugin Contributions:
0

Re: database writing problem...

Sorry bad language, I should have said "by doing the upgrade with the original database in a development environment"....
21 Oct 2015, 17:38
#17
pepperfire avatar

pepperfire

New Zenner

Join Date:
Apr 2008
Posts:
93
Plugin Contributions:
0

Re: database writing problem...

barco57:

Do you actually have a copy of the original 1.3.9 database from before the upgrade?


I have the original files. I have a Zen-cart export of the database. I still don't have a clue what was originally installed nor what is right or wrong with the crazy site that is currently live.

If you do, drop all tables in the 1.5.4, import the 1.3.9 DB into the 1.5.4 database, then run the zcinstaller and process the DB upgrade. That will update your database from 1.3.9 to 1.5.4....


What STARTED this process was being told in this forum that I needed to HIRE someone to do that upgrade because the core files had been changed for security and the whole thing was going to be over my head. Now you tell me it's that simple?

REALLY?

now the only problem you are going to have is if when building out the 1.5.4 you ran sql files for addon modules, parts/pieces of them maybe present if those modules were installed in the 1.3.9 but if you try and run some of them again to put them in you will most likely run into mysql error for stuff already being present. That's a slightly harder nut to crack, as it requires knowledge of how to work in phpmyadmin to pull configs out of the configurations table based on the group_id, copy those out, and delete them, then you can run the sql file to add the newer version back in and you can then make any adjustments to setting from inside the admin based on what you copied out and set aside.....confused yet?


So far, it's been a case of post it, look test, find error, fix, post it, look, test, find error, fix and on ad nauseum. Guess what I've been doing for the last year?

It does take patience and attention to detail to not screw it up. but its the kind of thing I run into again and again while doing upgrades.
If you had started out correctly by doing the upgrade on the original database you would have been better off and would only have to copy over those customers and orders that were new since you started working on the upgrade.


So far, I've paid three different people FAR TOO MUCH MONEY to not only not be able to do that, but to so badly screw up that I've gone from 300 hits a day to 3. When I fired the third one, I took over and started learning this stuff myself. W3Schools has been most educational.

I have had to resort to doing EXACTLY what you tell me I'm supposed to do when I can't figure out what the original files all are. I'm THIS close to believing I'm done, until this. I was proud of me on Sunday, now I'm just thinking I'm as stupid as they come.

Like I said, I'd appreciate HELP... Not admonishment. I have lots of patience with this thing, it seems, until I humble myself enough to come in here and ask where one file call is hiding.

I'm really sorry if everyone thinks I'm doing this wrong, but since I've not got any more money to throw at it, this is me doing it.

Perhaps THIS should have been my original question.

Is ZenCart NEVER going to work if I simply propagate the database like it's a database or am I wasting my time even bothering to do this, because honestly, losing the database seriously isn't worth losing my mind. EVEN IF it's 11 years worth of data and clients. :frusty:
21 Oct 2015, 22:44
#18
rodg avatar

rodg

Deceased

Join Date:
Jan 2007
Posts:
6,263
Plugin Contributions:
3

Re: database writing problem...

Pepperfire:


Perhaps THIS should have been my original question.

Is ZenCart NEVER going to work if I simply propagate the database like it's a database or am I wasting my time even bothering to do this, because honestly, losing the database seriously isn't worth losing my mind. EVEN IF it's 11 years worth of data and clients. :frusty:


The database is the single most precious aspect of a ZenCart installation. There is *always* a way to migrate the data from one Zen Version to another - And generally with ease. (Especially upgrading).

It is possible to do a (near) complete site restoration and/or upgrade based on nothing other than the database. I'd rather lose my mind than my database(s) :-)

Cheers
RodG
21 Oct 2015, 23:25
#19
rodg avatar

rodg

Deceased

Join Date:
Jan 2007
Posts:
6,263
Plugin Contributions:
3

Re: database writing problem...

barco57:

now the only problem you are going to have is if when building out the 1.5.4 you ran sql files for addon modules, parts/pieces of them maybe present if those modules were installed in the 1.3.9 but if you try and run some of them again to put them in you will most likely run into mysql error for stuff already being present. That's a slightly harder nut to crack, as it requires knowledge of how to work in phpmyadmin to pull configs out of the configurations table based on the group_id, copy those out, and delete them, then you can run the sql file to add the newer version back in and you can then make any adjustments to setting from inside the admin based on what you copied out and set aside.....confused yet?


I'm commenting to this mainly for the OP's attention.

Until I read this I'd never been confused about the process. <grin>

Furthermore, I can't think of a time or situation where I've ever had a need to follow your process of manually identifying and deleting group_ids. It is easier to execute any uninstall scripts first (if available), or to modify the install script(s) to skip the errors and/or keep the existing group_ids.

I'm sure the situation may arise (or has arisen) where manual intervention (direct DB manipulation) is needed, but most times it can be avoided.

There is nothing to 'fear' about a database. As long as you always have backup copies they are trivial to restore.

mysql errors for stuff already being present (when running sql install/upgrade scripts) can generally be ignored.

If/when you ever remove a zencart module/add-on you *don't* need to remove or revert any DB changes made by the module. They will cause no harm. In fact, it is the reverting of such changes that will often cause a problem as a consequence of an incomplete reversal of the *file* changes (or additions).

Making any DB changes via tools like phpmyadmin should be made with caution. Always backup first. Most folk doing nothing more than site upgrades/migration can do so without even touching the DB related tools such as this.

Cheers
RodG
22 Oct 2015, 13:47
#20
pepperfire avatar

pepperfire

New Zenner

Join Date:
Apr 2008
Posts:
93
Plugin Contributions:
0

Re: database writing problem...

I'd like to thank everyone for their comments, most of which, I just skipped over, THOSE who actually helped though, now know who they are, they have been expressly thanked for their kindnesses.

Fwiw, and for the furtherance of the the original problem I came in here to fix. It has been fixed. Per https://www.zen-cart.com/member.php?120199-mc12345678 telling me that there was a log file I didn't know existed, I found the file call source error and replaced the file IT was asking for. Apparently, it used to be a pay to use module that has since become free. Which is why I couldn't find anything about it - nobody here troubleshoots paid files and what was here at ZC-forum pointed back to the developer where I found the file. Anyway, to resolve the problem, I simply added in the files for the CSS_JS_LOADER that the file was calling for and fixed a problem I didn't know I had. I have not reinstalled the files to find out whether or not that has fixed the Define Pages not saving problem.

I'm going to leave this thread with this comment, as it is important, I think.

It dawns on me, that every one of us does this in our own way. I'm self taught, I don't have the "education" that some of you do, and I'm a lot of a hack, but I'm a geek for clean code and look forward to the day when MY zencart is the cleanest code on the planet, but for now, I'm still a beginner. I appreciate the comments about the fact that I am doing this the hard way, I knew I was, although, I question the use of wording, ("wrong") some of you are coming across as a little less than respectful in the way you choose to "help". I do appreciate that help was your intent. But doing this the way I have been doing it is the only way sometimes.

That is not lost on me.

The problem is not that I am doing it "wrong", the problem is that I am doing it the hard way. I have been working with databases since before some of you people were born, and I appreciate your comments especially, @RodG, as I am of a mind when it comes to databases and data. My husband was willing to toss the db yesterday and start all over again from scratch.

That said, I have as a result of this, found someone who has graciously offered to help me take the original site to 1.54 level so that I can focus on moving forward more quickly.

I'm a hypersensitive individual, as I am sure other people on this planet are as well, and it would do all of us who are really into this thing called ZenCart to remember that when you are dealing with others, it is kind to be sensitive to the fact that they are not you and may appear to be doing it differently, but sometimes not doing it your way is indeed not the "wrong" way, although, I do agree it is the hard way. Anyway, just this thought to remind you that you get a lot more flies with honey than you do vinegar. And if indeed you LOVE zen they way that I have come to, then respect of other Zenners is PARAMOUNT to this forum being an effective place to get help and support.

That is all -- Be kind. It's not hard.

Thank you.