Zen Cart Logo
Forums / All Other Contributions/Addons / Improve 138 by cannibalizing from 139? [BAD IDEA]

Improve 138 by cannibalizing from 139? [BAD IDEA]

Locked

Views: 1,271

Results 1 to 7 of 7
This thread is locked. New replies are disabled.
1 May 2010, 9:39 PM
#1
feznizzle avatar

feznizzle

Totally Zenned

Join Date:
Apr 2010
Posts:
900
Plugin Contributions:
0

Improve 138 by cannibalizing from 139? [BAD IDEA]

So I am new to Zen, migrating from CRE.

Talk about lousy timing!!! If ZC 1.3.9 had come out say 6 months ago, then I bet all the mods would be working nicely w/ 139 by now.

I have been following this thread about which mods are working with 139.
Unfortunately it appears that a TON of good mods are NOT ready, several of which I really need. Sadly I am not a programmer and cannot help with rewriting mods and I have run out of time. I have no choice but to move forward.

So as much as I desperately wish I could start from scratch and go with 139 right away, I have made the sad decision to revist 139 in 6 months or so.

With that in mind, there are many things I like about 139 that I would like to cannibalize into my 138. I will be looking at this more over the coming week, posting my experiences (what works/doesn't). This is not to encourage others to wait, rather it is just in case others can't program and cannot afford to wait. Maybe they can also benefit a bit from 139 while waiting for mods to catch up.

Anyway, here is one easy improvement: DrByte has added many bots to the spiders.txt in 139, so i will use the 139v in place of the 138v.

If anybody else has ideas or suggestions, plz jump right in!

1 May 2010, 9:49 PM
#2
feznizzle avatar

feznizzle

Totally Zenned

Join Date:
Apr 2010
Posts:
900
Plugin Contributions:
0

Re: Improve 138 by cannibalizing from 139? [BAD IDEA]

The next thing I really want to do is adapt the security provided by the htaccess files. I wonder if I can do this in a wholesale manner or do I have to be very careful about this? I tend to think that some of the mod issues might be related to htaccess use?

Here is the 138 htaccess from admin folder:

$Id: .htaccess 1105 2005-04-04 22:05:35Z birdbrain $

This is used with Apache WebServers

For this to work, you must include the parameter 'Options' to

the AllowOverride configuration

Example:

<Directory "/usr/local/apache/htdocs">

AllowOverride Options

</Directory>

'All' with also work. (This configuration is in the

apache/conf/httpd.conf file)

The following makes adjustments to the SSL protocol for Internet

Explorer browsers

<IfModule mod_setenvif.c> <IfDefine SSL> SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 </IfDefine> </IfModule>

Fix certain PHP values

#<IfModule mod_php4.c>

php_value session.use_trans_sid 0

php_value register_globals 1

#</IfModule>

to turn off register_globals

php_value register_globals 0

Here is the 139 htaccess from admin folder:

@copyright Copyright 2003-2010 Zen Cart Development Team

@license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0

@version $Id: .htaccess 15992 2010-04-19 06:02:20Z drbyte $

This is used with Apache WebServers

The following blocks direct HTTP requests to all filetypes in this directory recursively, except certain approved exceptions

It also prevents the ability of any scripts to run. No type of script, be it PHP, PERL or whatever, can normally be executed if ExecCGI is disabled.

Will also prevent people from seeing what is in the dir. and any sub-directories

For this to work, you must include either 'All' or all of these: 'Limit Options Indexes' parameters to the AllowOverride configuration in your apache/conf/httpd.conf file

Example:

#<Directory "/usr/local/apache/htdocs">

AllowOverride Limit Options Indexes

#</Directory>
###############################
DirectoryIndex index.php

deny everything

<FilesMatch "...">
Order Allow,Deny
Deny from all
</FilesMatch>

but now allow just certain necessary files:

<FilesMatch "(^$|^favicon.ico$|.*.(php|js|css|jpg|gif|png)$)">
Order Allow,Deny
Allow from all
</FilesMatch>

IndexIgnore /

The following makes adjustments to the SSL protocol for Internet Explorer browsers

<IfModule mod_setenvif.c> <IfDefine SSL> SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 </IfDefine> </IfModule>

Fix certain PHP values

#<IfModule mod_php4.c>

php_value session.use_trans_sid 0

php_value register_globals 1

#</IfModule>

to turn off register_globals

php_value register_globals 0

#turn off X-PHP-Originating-Script header when sending emails from admin
#uncomment to activate:

php_flag mail.add_x_header Off

Would there be any harm by replacing the 138 w/ 139 file? Seems like an obvious security gain.

I wonder if there is htaccess manager mod? Man, that would make an awesome mod!

1 May 2010, 11:01 PM
#3
drbyte avatar

drbyte

Sensei

Join Date:
Jan 2004
Posts:
63,513
Plugin Contributions:
177

Re: Improve 138 by cannibalizing from 139? [BAD IDEA]

While you can use all the .htaccess files and the spiders.txt file from 1.3.9 on older versions, EVERYTHING ELSE really needs to be treated as a "package deal".

In fact, cannibalizing from 139 back to 138 is going to take you as much time and troubleshooting as upgrading other addons will. And, may break existing addons anyway.

IT IS STRONGLY ADVISED TO NOT SELECTIVELY PICK AND CHOOSE ONLY CERTAIN 1.3.9 UPDATES ONTO v1.3.8. YOU SHOULD DO A COMPLETE UPGRADE.

Partial/cannibalized upgrades will not be officially supported. ie: if you run into problems with a half-baked botched site as a result of cannibalizing, you should be fully prepared to do all your own support yourself.

2 May 2010, 3:36 PM
#5
feznizzle avatar

feznizzle

Totally Zenned

Join Date:
Apr 2010
Posts:
900
Plugin Contributions:
0

Re: Improve 138 by cannibalizing from 139? [BAD IDEA]

DrByte and frank18,

I truly want to go straight to 139 especially since I am fresh installing everything. But I really need Image Handler and a number of other mods. Also a few days before 139 came out I purchased a copy of Easy Populate Advance which has not yet been updated. And since the free easy pop is not working yet with 139... well.

sigh

This is how I put food on the table for my family and it is how my employees put food on their tables. My websites have generated 90% of my income for the last 6 years. I cannot afford to leave my company in a lurch while I bang my head into wall after wall.

I really don't want a "half-baked" site. Tomorrow morning I will take a run at 139b and bolt on a few of my mission critical mods.

I am NOT a programmer, don't have a clue how to "trouble shoot" or "fix" mods. If I cannot get 139b running smooth in a TIMELY manner, I will either switch back to 138 or bail out on Zen altogether.

I'll report back.

Thanks for your input, gentlemen.

3 May 2010, 1:14 AM
#6
lankeeyankee avatar

lankeeyankee

Totally Zenned

Join Date:
Jan 2007
Posts:
1,514
Plugin Contributions:
1

Re: Improve 138 by cannibalizing from 139? [BAD IDEA]

Feznizzle:

Also a few days before 139 came out I purchased a copy of Easy Populate Advance which has not yet been updated. And since the free easy pop is not working yet with 139...

EP 1.2.5.4 works with 1.3.9a and b. I submitted it to the downloads section but you can pm me your email address and I will send it to you. There are no core overwrites in this version.

3 May 2010, 8:38 PM
#7
feznizzle avatar

feznizzle

Totally Zenned

Join Date:
Apr 2010
Posts:
900
Plugin Contributions:
0

Re: Improve 138 by cannibalizing from 139? [BAD IDEA]

Hi lankeeyankee,

Thank you for the offer, very kind sir!

Right after deciding to switch to Zen, I purchased a copy of Easy Populate Advanced 3.0.3 for $65. I tried using the CSV version of the free EP, but ran into problems related to platform (I could get it to work on a PC, but not a mac.. and I work mostly on mac). The paid version worked right away, plus gave me more extensive options.

I just finished installing EP Adv on 139b, seems to be working w/o any probs!