4 replies to this topic

[WreckWench]

So now that we have successfully moved the site from Webfaction to OpalStack and Butch has pieced together missing internal documentation on what software we've been using for our legacy platforms for example the OTP aka One Time Payment Manual Portal, etc we have some breathing room BUT.... not forever. And while OpalStack is allowing us to use PHP 5.4 without interference if they are bought up by competition like Webfaction was bought by GoDaddy...or we become problematic as a customer due to spam issues, hacking, etc we could be in the same boat again or worse finding ourselves shut down.

 

Since there are a number of IT issues in play Butch would you please summarize our IT challenges and future issues as you see them along with suggested timelines for resolving them so I can start to get my head around them as well as seek out possible solutions for resolving them. This will also help the team know where we stand on these critical matters and how we best resolve them. 

[Cmdr. Clownfish]

Ironically, your biggest IT issue is Forte.  If you were to move to something like Amazon Pay, you would far better off.

https://pay.amazon.com/

 

Here is the problem.... no CMS or other providers support Forte natively.  That means you are forced to have somebody code the interface to Forte.  If you use one that is supported by the shopping carts then you can move to a whole new system with no coding.  Just get a shopping cart that supports the card processor and you can use the inventory in the shopping cart to manage your trip sales.  There are ways to configure Hika for early bird and cash discounts and the new version all supports Amazon Pay.

 

That leaves trying to find a way to manage partial and other payments.  You can use a form builder for the trip forms without any coding also.   It may be a little harder to manage but it is free and you don't sell all that much.  They just need to be redesigned for the form manager backend.

 

The issues are pretty obvious... 

1) keeping PHP and JOOMLA updated.

2) member name legacy requirements have become cumbersome enough to need a developer to manage.  Track them by their numeric id in the joomla db instead.

3) Forte is a lead anchor that needs to be cut free

 

With some rethinking and changing some processes you can do this whole thing without any coding.  The cutover may be unpleasant but you have me yelling at everyone so it will be better than last time.

[Cajun Diver]

Thanks for the info Scott.

 

Kamala per your request here is the setup, challenges and possible future path forward:

 

Opalstack Current setup:

 

We are currently using PHP 5.4, IP.Board 3.4.9 (Invision forum software - where this is posted) and Joomla 3.4.1 (main site).

 

Joomla has Components (extensions) for hikashop 2.4.0, breezing forms 1.8.5, Smart Board 2.0.1 (database linker to use IP.Board forums accounts with joomla now called IPS Community Suite Login) and other add-ons (most not used it appears).

 

Onetime payment uses custom php from Scott and Pear to handle email.

 

Challenges:

 

PHP is out of date - Opalstack doesn't currently show any requirement to go to a newer version.

Forum software is out of date

Joomla uses the login from the forum software causing folks to log in twice

Joomla is out of date (3.4.1 and current version is 3.6.5)

 

Possible paths forward:

 

Upgrade PHP, Joomla and components (extensions) to current version, add a forum plugin and find a payment gateway that works with Forte (current searches don't show any for joomla).  This allows consolidation of the forums and Joomla and has for only one login.

  Pros - take advantage of current setup, less retraining for those doing the admin functions and likely an easier path.

  Cons - no Forte payment gateway plugin

 

Upgrade PHP, move to WordPress and use plugins similar to what we are currently using and have the ability through the Woo Commerce plugin to continue using Forte payment gateway.

  Pros - WordPress is more popular, has a lot of developers and many plugins are available

  Cons - total redesign of site, admins would have to learn a new way to do things

 

Both options allow a path forward and gets rid of the double login problem we currently have.

[Cmdr. Clownfish]

Having had to overcome the problems I have a unique perspective that isn't intuitively obvious to the not so casual observer.  This just my perspective of having tried to solve the problem for 10yrs.  I don't see PHP and Joomla as the overarching problem although your perspective of seeing it as a big issue is correct.  That is more of a result of a number of systemic issues that keep the PHP/Joomla issue from being easily fixable. This is what we call an "overconstrained problem."  That means there are too many requirements that are perceived as  "Must Haves".  The only "Must Haves" are

 

1) Product must sale

2) Company must pay costs

 

How this happens should not be written in stone.  Remove the constraints, there will be some bruising involved but like my recent surgery it is required.

 

You should be looking at root causes and not treating conditions.

 

As I said earlier, Forte is a blocker.  No matter what solution you come up with Forte will always be a blocker for implementing it.  I don't see how to move to any other system, CMS or Third party service, with Forte unless you have alot of funds for a developer.  Forte is not DIY or low budget friendly.  This is the biggest problem since it blocks every other path forward.  Stripe or Amazon Pay is a much better choice and would fit very well in your company.

 

Cash Discounts are the next problem.  These are incredibly hard to manage and generally will take a developer or some very deep configuration of a high end shopping cart to implement.  Hika can do it but I don't remember exactly how.  You have it in some old emails from me. In reality it would be better to drop these completely and offer some other incentive instead.

 

Partial payments are the next problem.  Virtually every payment processor EXCEPT Forte supports partial payments, called subscriptions, now and Hika has a module (which you don't have) that supports them as well.  Stripe has a very good platform for this. They even collect the money!!! It might take some thought but you could probably take that subscription module of Hika and build a partial payment product directly in Hika without a developer.   Everybody paying something different whenever they want to is off the table though.  That takes a developer.

 

You should talk to Synchrony Bank about innovative solutions to the Cash Discount and Partial Payment problems.  These constraints may not be as required as you think.  B&H Photo has a house credit card through them that somehow eliminated the state tax and quite often shipping.  I don't know how it works but I keep going back to BH and I end up saving a ton and paying Synchrony at the end of the month.  If they can find a way to eliminate 8% sales tax then they can eliminate 3% credit card fee. This approach does work.

 

https://www.synchronybusiness.com/?intcmp=how_it_works_footer_syfbiz_int 

BH may have figured it out instead.  Maybe call them if Synchrony is no help.

 

The practice of Quickbooks tracking members by username made complete sense back when everything was manual.   It doesn't really work now that everything is in a database.   For the database to really work it needs to be normalized.  That means the username is a field that exists in only one place.  As it is we have to copy it all over the place and then it is difficult to change anything.  This also makes it very hard to port to another system.  Without a developer this is quite possibly a blocker.  I think that if you can eliminate Forte and get a handle on Cash Discounts and Partial Payments then this it would be fairly easy to normalize the database and maintain it moving forward although accounting would have to make some changes.  Each member should be a number that is only used to track them in Quickbooks.  Otherwise you are probably looking at a custom build.

 

Two databases are an obvious problem, you really should only have one.  Again that is a normalization problem but if you keep sales in one and messages in another then it is more of an annoyance.  That is a bigger problem because of PHP.  You can always upgrade IPB but the new version is a pain and it will break the joomla plugin.

[WreckWench]

Thank you for your insight Butch and Scott.