Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Upgrading to the latest version


Jack_mcs

Recommended Posts

@suscrofa Lark...see the link in my signature file...is that where you got the latest version from?  Also what exactly was the server error?

Dan

Link to comment
Share on other sites

  • Replies 162
  • Created
  • Last Reply
5 hours ago, suscrofa said:

After I set up Edge with a few products, I wanted to make sure my payment and shipping modules worked. I tried to do a fake order, but every time I tried to 'buy' (place in shopping cart), I got an Internal server error message. I contacted my server, and they said my version was already old. I dl the version on the top of this post, installed the db, and changed the configure.php files. I then tried to 'buy' one of the products that came with the package and I get the same error message. I changed php version to 5.6 just in case. Still get eror message.

If you downloaded the version from the link Dan mentioned, then your host is not correct. But regardless of if it is old or not, they should tell you want the error is. You can also see if there is a file named error_log in the root of the shop and, if there is, see what the last error is.

Since it is only failing when you try to place an order, it is most likely something to do with the configure file. Or if you have made file changes to the stock code, then it might be that one of those is causing a problem. The first thing to do is to find out what the error is.

Support Links:

For Hire: Contact me for anything you need help with for your shop: upgrading, hosting, repairs, code written, etc.

Get the latest versions of my addons

Recommended SEO Addons

Link to comment
Share on other sites

If you can't find the error_log file, you can edit your includes/application_top.php to create it:

Find at line 24

// load server configuration parameters
  if (file_exists('includes/local/configure.php')) { // for developers
    include('includes/local/configure.php');
  } else {
    include('includes/configure.php');
  }

if you can't find that, you're not running the latest version!

insert after all that :

 ini_set("log_errors", 1);
 ini_set("error_log", DIR_FS_CATALOG . "error_log");

 

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

You changed PHP version (from what?), but did you then clear your browser cache (and possibly any server cache, too)? It might be working now, but you're still being shown an old (failed) page by your browser. Edge should run OK with PHP 7.0 and maybe 7.1.

As mentioned by others, the "link at the top of the post" could be pointing you to the "Gold" edition of 2.3.4BS, which is old and should not be used. Make sure yours shows "2.3.4.1" as the version and is in fact, "Edge". Unfortunately, I don't think it actually says "Edge" anywhere (Gary fell down a bit by not giving it a unique identifier, leading to endless confusion over exactly what is installed).

If you are getting through many pages OK, it's unlikely that you have an .htaccess or php.ini file that contains an invalid command (e.g., php_value or php_flag). However, it would still be a good idea to check all lower-level .htaccess files for any such commands no longer supported by your host.

Link to comment
Share on other sites

  • 2 weeks later...

I've installed recent version of edge but couldn't find a way if a logged in customer can log off by choice. It will keep on saying welcome back whenever you visit store again. 
How to add login - log off link in the header in Edge. Most appropriately before cart content or above search box. I've loved the work done on edge so far. 

Link to comment
Share on other sites

  • 2 weeks later...

We are using v2.2 & really need to go responsive. However, we also have a lot of customization that our new developers think will be hard to debug/recode.

So, what might seem to you programming types an obvious/slash dumb question:  Would our current desktop site still render reasonably ok but mobile responsive would be a mess or would the whole thing be a mess?

 

Link to comment
Share on other sites

@indigoinstruments

What I think you are asking is ... If we keep our current v2.2 site, with it still display fine on a desktop, and mess up on a mobile device? Or, if we keep our current v2.2 site, will everything become a mess?

If those are your questions, the answers are this:

1) If your v2.2 site currently displays fine on a desktop, it will continue to display fine on a desktop ... *** until *** your host upgrades their version of PHP. At that time, your site will, no doubt, crash and burn.

2) Your v2.2 site will continue to display as it currently does on a mobile device (how well it currently works, I don't know) ... *** untill *** your host upgrades their version of PHP (see above).

If that wasn't your question, please ask again with more details.

That all said, it is time to upgrade your site. Unfortunately, it is not an in-place upgrade. You'll need to do a fresh install of Edge (see link in my signature below) into a separate sub-directory, move over all of your product images, import (and convert) a COPY of your database, and make any style changes and/or add any new add-ons your want. Do note that some of the customizations you made in your old site may now be included in Edge.

HTH

Malcolm

Link to comment
Share on other sites

Hi Malcolm,

Thanks. My attempt to be brief didn't aid clarity. A bit more background.

1) Company that did our site in 2013 went under but did upgrade us to php5.6 before they did.

2) New company we found has some experience with osC but dealing with undocumented customized code from previous programmers is an unknown for them.

They believe they can convert the 2.2 site to accept a responsive design & avoid having the custom code break. The downside is they want to agree to new designs based on mockups beforehand. Their first designs were unwieldly & I can see us going back and forth & still not get where we need. So, we are beginning think this approach is ass backwards. The design should be done on a live working environment.  Am I not right in understanding that tweaking mockups is much harder than tweaking CSS to arrive at a final design?

In other words, I think they need to create the responsive compatible environment first & then show us new designs that they can tweak, not the other way around.  The question is, is doing it in 2.2 workable given the shortcomings of 2.2.  Or, is it wiser to take the plunge with 2.3.4 Edge/Bootstrap & then debug the custom code?

We can create as many virtual environments as necessary but  I am not a programmer so can't make a convincing case for either approach.

Does that help?

Stephan

 

 

 

Link to comment
Share on other sites

4 minutes ago, indigoinstruments said:

Or, is it wiser to take the plunge with 2.3.4 Edge/Bootstrap & then debug the custom code?

100% this one and you may be surprised how much of your custom code is already included in 2.3.4.1. CE Frozen (Final version of 2.3.4 EDGE) and how much is available as easy to install, modularized contributions.

 

To get a better idea, list us your customizations and we'll see.

Link to comment
Share on other sites

@indigoinstruments

1) what @raiwa said!

2) There *was* an add-on that created a mobile version of your site. Unfortunately, this meant that you actually had two sites (pulling off of the same database) ... a desktop site, and a mobile site. The developer for this add-on has abandoned it, since the new responsive version of osC is a much better solution.

While your new company *may* be able your adapt your old site to a responsive design, please realize that it will still be based on the old v2.2 code, which not only won't support newer versions of PHP, there are also security issues, etc. *IF* you go that way, you are essentially forking your own version of osC, and no-one else will be able to support it for you. You will be tied into this new company.

If I may suggest, post a RFQ in the Commercial Support area of this forum ( https://www.oscommerce.com/forums/forum/79-commercial-support-inquiries/

and get a bid to move your old site to Edge. Compare that to what your new company wants.

Malcolm

(and no, I am not a commercial developer)

Link to comment
Share on other sites

@indigoinstruments Stephan - first off I'm glad you realise that you need to go responsive. It's essential, however you achieve it, to get visitors through the search engines and to convert a large proportion of them into customers.

Your site guys are right that dealing with undocumented customisation is an unknown quantity - and that is true whatever the approach. They are also right that putting a responsive skin on 2.2 is a viable approach (and probably more familiar to them). However, it's dated (it was previously the only option) and I think it's actually more risky than starting over on 2.3.4.1. CE Frozen.

I would also be surprised if skinning your old store comes in cheaper and given that you are already having performance problems on your site, making it slower with an extra presentation layer seems like a bad idea.

Configuring your new store on the Community Edition is much more straightforward and requires much less coding. Many addons don't need any at all. Even stuff done specifically for you is  much easier.

If you don't have much idea of the addons in your existing store, it may be a good idea to ask for help in spotting the major ones. You can ask for paid help by posting in commercial support inquiries.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

John,

Thanks for the reply. .

If I understand you correctly, the 2.3.4.1 CE Frozen would lend itself to a responsive skin more readily & would have a better chance of retaining the functionality of much of the custom work. At the very least, the custom work might be more easily debugged. I take this also means that a database conversion as required for the Bootstrap version is not needed for this. We do want as much speed as possible & from what I have been told, osC is a lean platform well suited to this.

I have poked around a bit & found a number of addons that are attractive. I "spoke" to 2 of the developers of these & it was clear that if modifications was needed, it would be much simpler on 2.3.4 than 2.2.

I'll will encourage my new programmers to join the forum as I am certain they will find much sage advice during this transition.

Regards,

Stephan

Link to comment
Share on other sites

@indigoinstruments

41 minutes ago, indigoinstruments said:

If I understand you correctly, the 2.3.4.1 CE Frozen would lend itself to a responsive skin more readily & would have a better chance of retaining the functionality of much of the custom work.

It is not a "responsive skin". Frozen IS responsive, right out of the box.

There are templates available for Frozen (I guess you could call them skins), although most of them are commercial products. But, the good ones DO NOT REQUIRE ANY CORE CHANGES (or very few, is any).

Regarding the 7000+ add-ons available, most are for older versions of osC, and will require substantial updating to work with Frozen. Be sure to read the description. Frozen has been development for over four years, and has only *just* been, hmm ... 'frozen'. So, even if the add-on says that it works with the 'responsive' or 'community' version of osC, it may still need updating. Many of the add-on developers have been waiting for Frozen to freeze before they update their code to work cleanly with Frozen. Please give them a little time.

58 minutes ago, indigoinstruments said:

I take this also means that a database conversion as required for the Bootstrap version is not needed for this. We do want as much speed as possible & from what I have been told, osC is a lean platform well suited to this.

You will need to do a database conversion to move your v2.2 database to Frozen. Frozen IS the Bootstrap version.

1 hour ago, indigoinstruments said:

I have poked around a bit & found a number of addons that are attractive. I "spoke" to 2 of the developers of these & it was clear that if modifications was needed, it would be much simpler on 2.3.4 than 2.2.

If the developer(s) of the add-on(s) have followed the current (preferred) coding style, add-ons are written to not touch the core code. Any updating needed to the add-on to work with Frozen should then be a simple task.

HTH

Malcolm

Link to comment
Share on other sites

Malcolm/John/Rainer,

Thanks very much for your patience & indulgence. A bit of background info so you don't think I'm a complete twit.

I only have one computer course under my belt, Fortran, taken in 1972. I am actually a biologist by training but sold lasers, nuclear instrumentation, etc. after getting my M.Sc. in 1978. Fast forward 15 years & I have my own company. We went on the web in 1994 with a site done by a grad student at the University of Waterloo & were first hosted at ds.internic.net/indigo. We bought the domain indigo.com in 1994 but didn't have a stand alone site until 1997. Fast forward some more & we had custom work done to build a shopping cart & integrate our office server's accounting/inventory database with our website. In 2012 we needed to improve the site & osCommerce seemed a viable option. 6 years later, we have to go responsive. Clearly if we were starting out today, we would do it differently. A last wrinkle is we sold our domain indigo.com in January & are now using indigoinstruments.com. We will lose complete control of indigo.com mid July.

A very brief listing of some customizations.

1) Our image handler allows us to rename an image at will & it in turn does an URL rewrite for the product page. i.e.. "some-image-product.jpg" creates a corresponding "some-image-product.html". This was an idea I had for SEO since Google was starting to return more images in search. It actually worked very well initially but has since become a burden. We can abandon this one in favour of a more robust CMS. Of course, if the code doesn't break, then we can live with it as is.

2) Our business is both B2C & B2B. Visitors to the site will see products with price discounts for say 10+, 100+, 1000+ or more units. However, we also offer a discount scheme for bulk buyers. These are priced in the lots as they come to us from our suppliers. So there may be a "packof50", "boxof120", or "caseof250, etc. There are perhaps 40-50 of these custom lots. Our first osC developers adapted the product attributes table to accommodate this. Only we can see this as Indigo users so we have to manually select these special prices for our wholesale/large volume customers. My hope is this is simply a matter of copying/adapting that table.

3) Order status. This is harder to explain but osC feeds orders to our office accounting program through an api indicates order status change from New to Accepted, Packed, Completed, Backorder, etc. Some of these status changes are sent to the webserver through an XML feed.

4) Currency. If a customer's IP indicates he is in Canada, he sees $CAD. The rest of the world sees $US. However, if on checkout the ship to address is a different country, the currency & price could change since we have to collect various sales taxes for Canadians.

5) Shipping APIs. We use Canada Post, US Post, FedEx Ground, FedEx Express. There are some additional rules but I can leave that for now.

6) There are some others but technically not complicated. 

The company we have found to do the work is not as familiar with osC as we would like but we are hoping they can come up to speed. They have indicated they can handle the CSS needed for responsive designs.

I do like the suggestion that we perhaps engage a member of the osC community to handle the database conversion & code debugging. We can set up a virtual environment for "new.indigostruments.com" to this end. Once that is done, designing the various pages needed for responsive should go a lot more smoothly.

I certainly do like the idea of having access to all the addons & this would allow others developers to help us rather than have us tied to one group of people.

Your collective feedback on this is of course welcome.

Regards,

Stephan

Link to comment
Share on other sites

Hello Stephan @indigoinstruments

1. There are 2 updated SEO URL rewrite add ons for 2.3.4.1 CE available, ULTIMATE SEO URL 2.2 and ULTIMATE SEO URL 5

2. Two free SPPC (Wholesale) add-ons are available. The old SPPC updated for 2.3.4.1 CE and my Wholesale SPPC light add-on which is much easier to install but has less options (at least the free version).

Quantity price breaks should be straitghtforward to install and adapt to 2.3.4.1 CE.

3. This must be ported and updated for the new version.

4. No problem to port to new version

5. Shipping modules need just a small PHP 7 compatibility fix.

 

You should post in the commercial support enquiry topic:

https://www.oscommerce.com/forums/forum/79-commercial-support-inquiries/

 

regards

Rainer

Link to comment
Share on other sites

Create your new develop store under subdomain. Most hosts allow to use different PHP level there.

Link to comment
Share on other sites

On 5/25/2018 at 11:29 AM, indigoinstruments said:

If I understand you correctly, the 2.3.4.1 CE Frozen would lend itself to a responsive skin more readily & would have a better chance of retaining the functionality of much of the custom work.

As others have pointed out, Frozen is already responsive all by itself. However, if you are talking about changing function and appearance through a new skin ("template"), whatever you have now would have to be rewritten to be compatible with Frozen. There are already several such templates (some may be free) that may be a good starting point, with only minor adjustments to the CSS (placed in file user.css) needed in most cases.

Note that using one of the SEO add-ons may produce slightly different URLs than your current system. Search engines will regard these as different, and you may lose SE ranking for a while. Depending on just how different the systems are, it may or may not be feasible to come up with something that either accepts (in addition) the old URLs, or returns a 301 code with a new URL. It might even be possible to tweak the new SEO code to produce the old style URLs (links produced to match the old), but this will take someone quite skilled in this area.

Frozen is happy to run on PHP 5.6, but will also do 7.1 (which your host will upgrade to soon enough, as it is the current production level).

Special pricing, etc. should be largely independent of the responsive skin issues. Your old database will need to be updated to work with Frozen, but you should be able to keep all your existing data (just be sure to back up your DB!). Anything you added to the DB for custom function can be kept, unless there is a naming conflict with Frozen's changes. About the best thing you can do is make a test installation (in its own directory) of Frozen, migrate over a copy of your data, and start playing with it to add in your custom function (possibly already built-in or available as add-ons). Don't sweat it if there are minor differences in appearance -- customers like to see that a shop is being kept updated rather than stagnating.

The biggest impediment to such a changeover is that most site owners never kept track of what changes they made over time -- both what they changed and (just as important) why they changed it. For instance, if you made massive changes to implement responsive, all that's built-in now. If you're in this boat, start now to write down everything you can remember that was changed (and why), which will help you to replicate your custom functionality and appearance. Get in the habit of carefully documenting all changes, so the next time around, it won't be so painful.

Link to comment
Share on other sites

Rainer,

Your wholesale plug-in might be of interest down the road.

We could do a subdomain but the problem with that I think is that Google might be able to index it. If we create a new virtual environment, then we can restrict access to just developers & ourselves based on IP address.

Phil,

Good to know that 5.6 can support both versions. The URL rewriting is a major issue for us since current file/path structure has to be maintained during & post domain migration, ideally for another 18 months. We've managed to maintain our domain authority so don't want to tamper with that while we try to get our SERPS up with responsive mobile.

Templates for responsive may also be useful. Depending on what progress we make in the next few weeks, I may go to the commercial posting area to see what talent is available, especially regarding URL rewriting/SEP.

Good point on the documentation. This has been a major weak spot for us for years. Will have to see if I am up to wearing another hat.

I'll keep you all posted. Your prompt, information responses have been a great help.

 

Regards,

Stephan

 

 

Link to comment
Share on other sites

31 minutes ago, indigoinstruments said:

we could do a subdomain but the problem with that I think is that Google might be able to index it. If we create a new virtual environment, then we can restrict access to just developers & ourselves based on IP address.

Use the store mode add-on to filter access by IP:

https://apps.oscommerce.com/XTWqf&store-mode-bs

and in addition prevent crawling by robots.txt restriction

Link to comment
Share on other sites

Remember that all robots.txt and <meta>-style nofollow, noindex are just suggestions to search engines. None have the force of law. A well-behaved SE will probably obey them, but don't count on it. If you have no public links to a test directory, it's unlikely (but not impossible) for a SE to still index it. The only sure-fire way I know of to put the test directory under password control (via your hosting control panel).

Quote

The URL rewriting is a major issue for us since current file/path structure has to be maintained during & post domain migration, ideally for another 18 months.

I think we're talking two different things here. The paths and files could change radically, but a SE seeing only SEF URLs could have no idea that the directory structure has been changed underneath it. Of course, you may have other reasons that you want to retain a certain directory structure, that are independent of SEO. If you have valuable SE goodwill built up, you may want to think about how you could preserve your current SEF URLs by tweaking an SEO add-on. Alternatively, it should not be harmful to redirect (301) existing URLs to new URLs, which could be an option for you.

Link to comment
Share on other sites

  • 5 months later...

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...