To work with my tech guy who is stuck. images wont load in listings, have tried all i and he can think off, also now usps is not letting you choose state you live in when filling orders out, among other bugs. If you can help contact me here or through email at jasonsjoes@yahoo.com
thank you
Jason
owner
jasonsjoesandmore.com
Nifty. Version, theme, extensions? One must guess to poke or hit something in order to get past the wall to the cart, where you have /theme/default/ and log-in of /admin/ shows your 1.5.6.0 -- perusal of forums beforehand would have suggested to wait a little bit longer for 1.5.6.1 before upgrading a going shop all the way to the newest, so there is some mopping up to do.
He probably went through these sorts of searches, but these might help while you're waiting.
usps changes:
http://forum.opencart.com/viewtopic.php?f=114&t=106096
1.5.6 image uploads:
https://www.google.com/search?q=1.5.6+i ... encart.com
1.5.6 usps no states zones:
https://www.google.com/search?q=1.5.6+u ... encart.com
He probably went through these sorts of searches, but these might help while you're waiting.
usps changes:
http://forum.opencart.com/viewtopic.php?f=114&t=106096
1.5.6 image uploads:
https://www.google.com/search?q=1.5.6+i ... encart.com
1.5.6 usps no states zones:
https://www.google.com/search?q=1.5.6+u ... encart.com
Ok I need someone tjat knows open cart. Running 1.5.2.1 I think. Usps won't work. As of a month ago. I'm at my wits end. I can't be the only one so there has to be a fix. Please contact me at jasonsjoes@yahoo.com. store is jasonsjoesandmore.com
My develpoer says its usps and there is no solution till they release a patch. I think there is a fix and someone has it cause i seem to b the only one down.
My develpoer says its usps and there is no solution till they release a patch. I think there is a fix and someone has it cause i seem to b the only one down.
gi joe and action figures www.jasonsjoesandmore.com
Your prior admin screen showed 1.5.6.0 but your present one shows Version 1.5.4.0 at now current http://jasonsjoesandmore.com/glenn002/upload/admin/. Look in .htaccess to see whether the base of the store is show as which of these:
the store root and the domain root:
/
the current actual position:
/glenn002/upload/
the position that maybe somebody expected:
/glenn002/
the position that is nested and not renamed because of how it was uploaded:
/upload/
the store root and the domain root:
/
the current actual position:
/glenn002/upload/
the position that maybe somebody expected:
/glenn002/
the position that is nested and not renamed because of how it was uploaded:
/upload/
We reverted back to an older version thinking it wod fix it. It did fix the image problem but usps is still screwed up. Agai. At a loss. My developer thinks its strickly usps fault and there's nothing that can b done. I think there has to be a fix. If not tjen howare all the other stores operating. How did they fix this?
gi joe and action figures www.jasonsjoesandmore.com
He went through the links provided above but said the code is all messed up and none will work. I'm frustrated. I'm at wits end. I need an outside view looking in to fix this. I've been down a month now
gi joe and action figures www.jasonsjoesandmore.com
Changes have been underway in usps to shift express service provisions into priority, and that is probably not yet done. Even If essential mailing is not affected by that but it could mess up how modules are supposed to work, given that they are already several months old. There are a few shipping extensions that are working. However, at the moment you may have some version mismatches or configuration mismatches in the way. See PM.
Here's a start of your issues (not sure if someone is working on it right now): Warning: session_start(): open(/var/www/clients/client0/web2/tmp/sess_e5a259dlqn299d9u33h4g6njm6, O_RDWR) failed: Permission denied (13)
If you want, send an email to support@cwswebsitedesign.com with your FTP information. I can't work on this while others are attempting to fix it as well or that will lead to bigger issues.
DL
If you want, send an email to support@cwswebsitedesign.com with your FTP information. I can't work on this while others are attempting to fix it as well or that will lead to bigger issues.
DL
This account is inactive. Look for us under the name 'EvolveWebHosting' and contact us under that username.
Thanks!
And it's still going on.
This account is inactive. Look for us under the name 'EvolveWebHosting' and contact us under that username.
Thanks!
well i learned a lesson, dont let anyone have ftp info till they talk to your main developer. i allowed someone whom i thought knew what they were doing to look around to see if they can help and charge a price, instead they changed files. the files (index) deleted the entire store and they did not back it up first. my developer just gave me a verbal beatdown. it has to all be done from scratch. thanks for nothing. you just cost me more money and down time 
gi joe and action figures www.jasonsjoesandmore.com
The two changed files were visibly backed up where they sat, as were their several long prior predecessors, all distinguishable by timestamps, missing files were supplied to protect the store, that store and seven others previously attempted alongside it were not changed or deleted in whole or in part, and it does not all have to be redone from scratch although properly upgrading it would be sensible. Lack of .htaccess or robots.txt having any effect, and full rights assigned to virtually all including all configuration files (.htaccess, config.php included), were never proper means to upgrade in any of the eight stores.
Proper means by who? Just cause u said it shouldn't b there cause u do it that way doesn't mean someone else can have it and it works fine. Tbe store worked fine till a monthish ago when this all happned at once. But in any case files were changed without my permision. I gave ftp access to look not to move stuff arounf
By moving stuff around the store is gone. Its having to be built from scratch.
By moving stuff around the store is gone. Its having to be built from scratch.
gi joe and action figures www.jasonsjoesandmore.com
My guess is that this can be recovered a lot easier than you think. Do you have any of the content backed up or still on the server such as the image folder, the database, the theme, etc? Those are the most critical pieces. I'm sure you've got mods installed but I doubt they're so far optimized that you can't just re-install them.
DL
DL
This account is inactive. Look for us under the name 'EvolveWebHosting' and contact us under that username.
Thanks!
(1) There was a resident executable infection of already name-shifted .php files addressable by http and visibly capable of 64-bit decrpytions known as mime attack. Those files, tantamount to live grenades with pins already pulled, were deleted. There remained a 777 block that probably does still have a problem inside it, because its permissions cannot be reset and it cannot be opened, leaving only Linux command line commands or host support as means to be rid of it. It is visibly 777 and bears "1.5.6" in its name.
All permissions of all public files were 777 except for several scattered ones at 776. The 777 .htaccess file's entire content was "## Default .htaccess file". The config.php pair was 777. There was no protection. The 777 robots.txt file's entire impotent content was "User-agent: * [linebreak] Disallow:" -- the directive's "deny" is absent and the syntax is entirely wrong, rendering the file useless. All directories and all files were accessible and viewable via http.
A ongoing recent surge in sessions occurred in concert with an ongoing recent surge in domestic and foreign (including Russian) engine visits logged as seeking variously mundane, inappropriate, and denied files. Engines addressed index.php?route[...] files. There were just under 6,000 recent sessions, all resistant even to being opened. Runaway sessions do cause hosts to shut down websites abruptly till that is stopped and prevented.
The database, breached or not, posed and poses a prize. A brute force attack can be conducted by addressing in http either an injected console or a mere search engine. The 777 block posed elevated likelihood of an embedded, actively addressable console. The surge posed elevated likelihood of active risk to customers.
Whatever commenced "a month ago" was OC at the very least no longer properly installed or upgraded, maintained, and safeguarded. All "public" files were 777 excepting scattered 776, either set that way in the first instance or altered by attack. Both .htaccess and robots.txt were either functionless in the first instance or altered by attack. Surge in sessions was active. The odds favored likelihood that attack was actively seeking its prize; by the second, by the minute.
(2) For those reasons . . .
The impotent 777 .htaccess was recognizably renamed (“.htaccessOFF2013nov08pm”) and kept its timestamp, and was replaced with a functional 644 .htaccess file. The 777 config.php pair was reset as-is to 644. All public files were reset to 755 directories and 644 files, with the exception of the resistant 777 block, whose ownership and permissions both require change in order to be rid of it.
The original simple html landing file, which hands off when clicked to the basal OC index.php, was unchanged. The OC index.php displayed a significant array of errors above the store header (error reporting and error logging were both on). A copy of the landing file but named index.html was inserted, adding only "We are undertaking site maintenance, please bear with us. Thank you for your patience." -- just below the pictures. The OC basal index.php was recognizably renamed "ISINDEX[...]" and kept its timestamp. The added index.html was renamed index.php so to fire in the store's stead. The entirety of the OC directory structure remained intact.
Upon the minor preventive changes in index.php and .htaccess, as well as in permissions particularly of those and config.php, the surge in sessions subsided and stopped.
There were eight stores, among the root, directories, and subdirectories. The entirety of their directory structures remained intact.
There are only two ways that files could have disappeared after they were last seen and specifically confirmed intact with 755/644 permissions. Certainly some of the file structure remains intact right now, because the admin log-in still fires, right now.
(3) Whether any specific modules failed to work owing to ongoing changes (such as are known within PayPal or USPS), or instead owing to 777 permissions or combinations of causes, the fileset was not optimal. Upgrading to three versions including,1.5.4.0, 1.5.5.1, and 1.5.6.0 had not been resounding successes, and at least one to 1.5.4.0 had been compromised from without.
The original OC version seems to have been 1.5.2.1 but the eight stores may hold hybridized versions of the files, of the database, or both, nominally as 1.5.4.0, 1.5.5.1, and 1.5.6.0. There were already known reasons not to upgrade an ongoing established shop hastily or prematurely to 1.5.6.0 (pre-.1) -- already voiced by authors ranging from significant authority as to OC to insignificant experience with OC.
(4) For those reasons . . .
As can be read from the renaming and timestamp of the OC index.php, the storefront is readily reinstated at any time by the simple expedient of renaming the substituted index.php (11/08) back to index.html (bearing with the red text, 11/08) so as to hold it in reserve for the purpose it serves, and then renaming the renamed "THISISINDEX[...]index.php" (11/05) back to "index.php" (11/05). Doing so at the moment, prior to removal of the 777 block and prior to proper upgrade, is not advisable. Whether attack from without availed itself of misset permissions or instead reset proper permissions, it had not been looked for in the several months after the means of attack was recognized or eradicated before it was first found 11/08 (supra).
What needs to be done is to choose one of four versions -- OC 1.5.5.1 standard, OC 1.5.6.0 standard, debugged 1.5.4.1 CE RC1, or debugged 1.5.5.1 CE RC1 -- and set up the fileset strictly according to proverbial Hoyle (including 755 dir and 644 file permissions, .htaccess, and else), and to set up the database strictly according to proverbial Hoyle (including known repairs to upgrade scripts where applicable, before any unrepaired script is even run). All four are possible to maintain and run on a proper server, but there are reasons for choosing any one of them.
For that purpose, all custom files, including images, theme(s), extensions, and any other amended core or ancillary files, need to be withdrawn and inspected, and then in their proper places added to a known good set of OC standard or already specially prepared, debugged CE RC1 files.
All permissions of all public files were 777 except for several scattered ones at 776. The 777 .htaccess file's entire content was "## Default .htaccess file". The config.php pair was 777. There was no protection. The 777 robots.txt file's entire impotent content was "User-agent: * [linebreak] Disallow:" -- the directive's "deny" is absent and the syntax is entirely wrong, rendering the file useless. All directories and all files were accessible and viewable via http.
A ongoing recent surge in sessions occurred in concert with an ongoing recent surge in domestic and foreign (including Russian) engine visits logged as seeking variously mundane, inappropriate, and denied files. Engines addressed index.php?route[...] files. There were just under 6,000 recent sessions, all resistant even to being opened. Runaway sessions do cause hosts to shut down websites abruptly till that is stopped and prevented.
The database, breached or not, posed and poses a prize. A brute force attack can be conducted by addressing in http either an injected console or a mere search engine. The 777 block posed elevated likelihood of an embedded, actively addressable console. The surge posed elevated likelihood of active risk to customers.
Whatever commenced "a month ago" was OC at the very least no longer properly installed or upgraded, maintained, and safeguarded. All "public" files were 777 excepting scattered 776, either set that way in the first instance or altered by attack. Both .htaccess and robots.txt were either functionless in the first instance or altered by attack. Surge in sessions was active. The odds favored likelihood that attack was actively seeking its prize; by the second, by the minute.
(2) For those reasons . . .
The impotent 777 .htaccess was recognizably renamed (“.htaccessOFF2013nov08pm”) and kept its timestamp, and was replaced with a functional 644 .htaccess file. The 777 config.php pair was reset as-is to 644. All public files were reset to 755 directories and 644 files, with the exception of the resistant 777 block, whose ownership and permissions both require change in order to be rid of it.
The original simple html landing file, which hands off when clicked to the basal OC index.php, was unchanged. The OC index.php displayed a significant array of errors above the store header (error reporting and error logging were both on). A copy of the landing file but named index.html was inserted, adding only "We are undertaking site maintenance, please bear with us. Thank you for your patience." -- just below the pictures. The OC basal index.php was recognizably renamed "ISINDEX[...]" and kept its timestamp. The added index.html was renamed index.php so to fire in the store's stead. The entirety of the OC directory structure remained intact.
Upon the minor preventive changes in index.php and .htaccess, as well as in permissions particularly of those and config.php, the surge in sessions subsided and stopped.
There were eight stores, among the root, directories, and subdirectories. The entirety of their directory structures remained intact.
There are only two ways that files could have disappeared after they were last seen and specifically confirmed intact with 755/644 permissions. Certainly some of the file structure remains intact right now, because the admin log-in still fires, right now.
(3) Whether any specific modules failed to work owing to ongoing changes (such as are known within PayPal or USPS), or instead owing to 777 permissions or combinations of causes, the fileset was not optimal. Upgrading to three versions including,1.5.4.0, 1.5.5.1, and 1.5.6.0 had not been resounding successes, and at least one to 1.5.4.0 had been compromised from without.
The original OC version seems to have been 1.5.2.1 but the eight stores may hold hybridized versions of the files, of the database, or both, nominally as 1.5.4.0, 1.5.5.1, and 1.5.6.0. There were already known reasons not to upgrade an ongoing established shop hastily or prematurely to 1.5.6.0 (pre-.1) -- already voiced by authors ranging from significant authority as to OC to insignificant experience with OC.
(4) For those reasons . . .
As can be read from the renaming and timestamp of the OC index.php, the storefront is readily reinstated at any time by the simple expedient of renaming the substituted index.php (11/08) back to index.html (bearing with the red text, 11/08) so as to hold it in reserve for the purpose it serves, and then renaming the renamed "THISISINDEX[...]index.php" (11/05) back to "index.php" (11/05). Doing so at the moment, prior to removal of the 777 block and prior to proper upgrade, is not advisable. Whether attack from without availed itself of misset permissions or instead reset proper permissions, it had not been looked for in the several months after the means of attack was recognized or eradicated before it was first found 11/08 (supra).
What needs to be done is to choose one of four versions -- OC 1.5.5.1 standard, OC 1.5.6.0 standard, debugged 1.5.4.1 CE RC1, or debugged 1.5.5.1 CE RC1 -- and set up the fileset strictly according to proverbial Hoyle (including 755 dir and 644 file permissions, .htaccess, and else), and to set up the database strictly according to proverbial Hoyle (including known repairs to upgrade scripts where applicable, before any unrepaired script is even run). All four are possible to maintain and run on a proper server, but there are reasons for choosing any one of them.
For that purpose, all custom files, including images, theme(s), extensions, and any other amended core or ancillary files, need to be withdrawn and inspected, and then in their proper places added to a known good set of OC standard or already specially prepared, debugged CE RC1 files.
Who is online
Users browsing this forum: alanjones, paulfeakins and 99 guests
