Speed Up OC 1.5.4.1 FREE!

Ah! Ah! I have an error too

When I go to the front end of my second store (I have multistore) I get this message before the page load
There must be something I need to add to the .htaccess or any other file!

Cleo

Cleo wrote:
Do you mean the cache folder in the smartoptimiser folder or the system folder? Sorry to ask just want to make sure

This really made me look closer at how i installed.

Silly me, i uploaded the individual files of smartoptimiser to the root, instead of the entire folder

But after editing the ht access file and setting permission accordingly....I haven't notice any change in speed AT ALL.

whereas if i uploaded the individual files, the thing works, but have an error of smartoptimizer error;Invalid file name ()
[i'd supppose this is the wrong installation method though.]

Guys, any solutions?

I have tried both scripts of .htaccess from federicoch and rdvapors

I removed the code from my .htaccess

Cleo

won't be using it

Cleo

Cleo wrote:Problem fix

I set permissions to 777 for config.php - index.php and admin/config.php and index.php while I visit the 2nd store
didn't see error so I reset them to the right permission and went back to the 2nd site still no error

But I will check often just to make sure

Cleo

Cleo, what exactly did you add to .htaccess?

I have tried both scripts from federicoch and rdvapors and it didn't improve the speed at all.

TIA

Removed everything because butte keep saying I am using 777 when I am not

I don't want to use anything that need chmod 777


Cleo

I installed your extension but im still getting the same results

Guys, maybe it can hurt your website in some way.
This quote below belongs to the developer of this SmartOptimizer tool.

Actually it's an old project of mine and I'm not satisfied with the quality of the code and its architecture. So I'm not willing to continue developing this project, but also this is the most popular project in my github account and I'm not going to abandon it. So I'm planning a whole rewrite of the project from scratch as soon as I can.

So, take in consiferation some risk about using it.
That's all

how to SmartOptimizer images in a subdomain is there anything to add?
or there is any other way to SmartOptimize the images,ccs,js if they are in a subdomain?


any help will be appreciate.
Thanks in advance.
OpenCode

OC V1.5.3.1

Before SmartOptimizer.



After...



Pretty nice improvement for such a little amount of work.

EX: root/public_html/smartoptimizer/
set chmod 777 the folder Cache
EX: root/public_html/smartoptimizer/cache/

Please axplain how to do this?

Hi dodokids,

Most FTP clients allow you to set permissions on a directory or file by right-clicking the file or folder you want to set and then choosing permissions. Either type in 777 or check all the boxes.

Here is a screenshot from WinSCP after right clicking a folder and selecting properties which provides a dialog to change permissions.

Set files to 644, directories to 755, not 777, each 7 conveys "all" read, write, execute rights, the first one to "owner" ("root"--who can do anything except what only the server's very own "root" system administrator can do), the second one to "group" (including the system, including Apache), the third one to "world" (anonymous everybody out there, hackers included), and is an inherent security risk that servers increasingly prevent. A 777 directory or chmod attempt can actually lock things up if it even takes, on modern Linux servers. If you see 777s in your tree, reset them to 755 (files to 644), and if 755 doesn't take or later reverts to 777, then the odds are elevated that you have been hacked and are not the only one going in there. After initial access by any of several avenues that have nothing to do with OC itself, a hacker can establish http access and use it for only two seconds at a time (using software) to wreak havoc. You can tell FileZilla Client (and others) to reset "all" dirs to 755, then files to 644, and to "recurse" through everything in and above the public (Apache's aliased public_html/ or www/ or htdocs/) root. Then look over whole thing, by eye.

Another sort of oddment that can be put in place by a hacker is an inconspicuously DOTnamed directory, such as .admin (.anything). If you see one of those, then you may well have a problem; you might not even be able to get into a 777 .anything easily in order to get rid of it, even using putty.exe inside Linux.

Code, notably .cgi, .pl, .php, used to require 777 routinely in order that ordinary visitors could see things work right. That is now antiquated, Linux and those executables (such as php.exe) have come a long way since then. Among the surviving well known ways in is a whereami.cgi file, 777 or not; hackers love those, they are pretty much a teething device for budding hackers. Some software still deploys them. OC does not have them in the first place, but can reside in an account that does (such as with certain blog software) and can be vulnerable that way.

Nowadays if you have software that requires 777, get rid of it, and if you have a server that requires 777, change servers.

Does anyone know why before making these changes, Specify a Cache Validator was 99 and after it is 54? and Specify a Vary: Accept-Encoding header went from 100 to 56?

Would love to fix these two things.

The eradicated evidence cannot now be autopsied, so causation and effect are not stringently reviewable now, but three points bear mention. In the two post fragments and search fragment below, NOT as demonstrating cause and effect, but as demonstrating palpable RISK, . . .

(A) Notice the opening of a 777 window on May 27 and an accomplished attack on June 17.

(B) Notice that the opened 777 window was publically identified in the forum (http addressable 777 was named).

(C) Notice that "777" is searchable; including by the wrong people; looking for 777 windows with known http addresses.

http://forum.opencart.com/viewtopic.php ... 20#p409352
2013 May 27 Mon 12:52 am
Edited to add: I have set 777 permission to cache folder.

http://forum.opencart.com/viewtopic.php?f=20&t=104214
2013 Jun 17 Mon 7:24 pm
My crawlprotect denied this ip address from India: 119.226.239.74 for sql injection, this is the code they tried to inject!
Do you think it's a real injection attempt?

http://www.google.com/search?q=777&site ... encart.com
where SEARCH FOR "777" ALL BY ITSELF returns "About 25,100 results (0.31 seconds)"

A note concerning relevance of the same appears over at at http://forum.opencart.com/viewtopic.php ... 63#p433363 .

Agreed 777 is not required and should not be used. But i'm still wondering why those 2 scores dropped almost in half.

You brought in the separate point of "why those 2 scores dropped" after the long prior point of 777 was already on the table. The post immediately above yours, here second above, speaks directly to an experience Cleo had shortly after setting 777 in this thread. As for why, experience is plainly mixed, so for now we just plain dunno, yet.

Actually my questions are about the smartoptimizer which this thread is about. I have no idea why you responded to my questions about Cache Validator and Specify a Vary: Accept-Encoding header scores with the beaten dead horse about 777.

Yes it was suggested in this thread, yes it is a bad thing but this thread is not about 777, its about the smartoptimizer script. So let's get this topic back on track and everyone will see your warnings also.

The thread promptly became "about" more than your narrow, and thus far unique, concern for "went from 100 to 56" among lesser drops as well as improvements. As for 777 I did NOT respond to YOUR posts, which make no mention of 777, and which do not just because you made the two posts wipe out prior trains of thought or commandeer the whole thread to your narrowed experience of "went from 100 to 56". And, to reiterate, my second post supra on 777 went straight to what happened to Cleo after she set 777 supra, and wound up with the cited problem in another thread. If you want fuller relevance spelled out here, it is merely that optimizing brought out 777 without attention to possible attack because of it, and there was an attack within three weeks of a change to 777 for the sake of optimizing.

Typically when several authors are responding to various points intermingled rather than merely lock-step sequential in a thread, most readers manage to figure out several of them jump over each other. You are not the center of the thread, which has taken in more than pure and simple optimization, and even as to that has gone in several directions already.

When someone realizes a solution for your "went from 100 to 56" it will surely be posted.