Should ShopParameters.php be removed?

[pakricard]

Hi all:

@PhilDaintree created webSHOP long time ago (thanks Phil!), and I tested it (can't remember if it was used in a real life scenario).

Nowadays, the only remains are ShopParameters.php and 42 settings, in table config all starting with Shop* (Checked via SELECT * FROM config WHERE confname LIKE "Shop%";).

I checked, and these parameters are not used anywhere else, except on the ShopParameters.php that set them up.

Should we remove these unused settings and the ShopParameters.php script?

R

[timschofield]

As far as I recall those parameters are used in Phil's webSHOP (https://github.com/PhilDaintree/webSHOP). Phil would know better than me, but it's possible there are people out there still using it, and dropping ShopParameters.php would break their implentations.

I think having the webSHOP improves webERP, but only if it can be maintained.

[pakricard]

As ShopParameters.php is exclusively used with webSHOP, it should be maintained and distributed at webSHOP repository, but not in webERP, where is not used, at all.

Same way, teh Shop* parameters should be maintained by webSHOP repository, not webERP.

My point being: the less code we have to check, verify, maintain, the better.Any line we remove because is not needed, makes ourwwebERP developers life slightly better.

R

[timschofield]

I think if webSHOP is to carry on then it will have to be maintained by us anyway. It looks to me as if it is a collection of scripts that sit alongside the webERP ones, using the same database.

My preference would be to keep it alive at this point and then do a proper analysis of whether we want it after v5 is out.

Tim

[dalers]

I think it best to keep ShopParameters.php ([Main Menu > Setup > General Setup > Web-Store Configuration]) where it is for now.

That doesn't affect a "v5" release. Release v5 with no guarantees for webSHOP and promise official support in 5.1.

I think webERP is stronger with webSHOP and it needs to be maintained.

I would argue ShopParameters.php is a webSHOP integration file and should be provided by the webSHOP project.

Either way, for now leave ShopParameters. php and the menu as-is.

Has anyone tried using webSHOP lately? This discussion may motivate me to try.....

Would a plugin system help with your vision @pakricard ?

the less code we have to check, verify, maintain, the better.Any line we remove because is not needed, makes ourwwebERP developers life slightly better.

Plugin systems are used to keep "core" as minimal as possible and need as little testing as possible, which should lead to improved quality and reliability. For webERP, "core" would be what is left after carving-off well-contained functionality peripheral to "core" into plugins (I know, a circular argument...). I'm thinking the API should be part of "core" and perhaps plugins access "core" through the API (e.g. following Z_ImportPartCodes.php).

For webSHOP, a webSHOP plugin may simply create an apropriate menu entry that links to ShopParameters.php (included in the plugin).

QA, MRP and the report writer could be candidates for plugins, and perhaps a future PLM or CRM plugin. It may be helpful to move the Z_ scripts to a "Utilities" plugin, perhaps being unique to a webERP site.

I suggest any actual movement towards a plugin would be "late 5.x" or "6.0", this will take a while to sort out....

[pakricard]

Yes, this does not affect v5, Agree, we can decide after the release.

My point is: If I create a webERP add-on (let's imagine "Automatic bank statement reading and consolidation for webERP"), the setup script for that add-on should be included in the add-on, not in Standard webERP.

As it is now, ShopParameters.php is useless to any webERP user, except if they use webSHOP, and I doubt anyone is still using it.

Has anyone tried using webSHOP lately? This discussion may motivate me to try.....
I think webERP is stronger with webSHOP and it needs to be maintained.

I think, nowadays webSHOP adds very little value. I found a webSHOP backup I used in 2013 (live) and back then was great, but now it is obsolete. webSHOP simply can't compete with Shopify, OpenCart, PrestaShop or any current e-commerce software out there. I would not spend any time trying to bring it up-to-date. That's why around 2015 I developed the bridge webERP-OpenCart, to get the advantages of webERP and a “full” e-commerce site.

Would a plugin system help with your vision @pakricard ?

I think the current setup of webERP that it is "all-included" is great. Removing functionalities and re-package them into plugins will require a massive revision of most scripts and no added benefits, as per current licence the software is free open source.

webSHOP at that time was sold by Phil (if I recall it properly) as an add-on. So, could not be included in the open source webERP as webERP is free ("free" like in a "free beer"). ;-) Phil graciously allowed me to use the webSHOP to test and debug, and did not charge me anything. Thanks, Phil!

Now the code is available in https://github.com/PhilDaintree/webSHOP if anyone wants to try.

R

[dalers]

My point is: If I create a webERP add-on (let's imagine "Automatic bank statement reading and consolidation for webERP"), the setup script for that add-on should be included in the add-on, not in Standard webERP.

I agree.

My point is that if the code does not require significant effort to use and maintain, the webERP project is stronger by having it's own e-store to have an all-in-one solution, it will tick boxes for a potential user and provides a reference design or example app for a domain-specific PHP web app that interfaces with webERP. I agree there is nothing to be gained by trying to compete with Shopify, OpenCart, PrestaShop, etc.

(plugins would have) ...no added benefits...

The benefit would be to continue to provide the functionality but without keeping it in the main webERP code. However, I can accept the effort to create a plugin system may not be justfiable or even practically feasible - even if existing functionality is not re-factored into plugins.

... 2013 ... webSHOP at that time was sold by Phil (if I recall it properly) as an add-on.

The first commit in the GitHub webSHOP repo was in 2018, which I take to mean Phil decided to release it as open source code and contribute it to the webERP community. However, there is no license explanation or license file in the webSHOP repo, which should be rectified.

Fwiw, should @timschofield's webSHOP repo (https://github.com/timschofield/webSHOP) be considered the the "official" upstream repo? It is 3 commits ahead of the original upstream repo (although 1 commit behind).

Btw, glad to see a license file in the OpenCartBridge repo :-)

[timschofield]

One of the great things about the way our code is structured, is that it is very easy to add in or take out batches of scripts - plugins by another name. For instance I have a batch of 70+ scripts which add some HIS functionality to webERP. They all have the same prefix, and they can be added in (with a single sql update file for the menu items) or taken out as needed. This wouldn't be possible with the code structure that is sometimes advocated for us.

Tim.

[efeoli]

Hi All,
this discussion is quite interesting and I would like to contribute a bit as an experimentes user.

First, it is exciting how v. 5.0.0 is turning out and the improvement of 4.15.2 is impressive. It is a system that adapts to many scenarios and how it is kept below 70mb is just a tremendous achievement.

Instead the shop setup by Phil, although it was great due to the integration, was hard to adopt in production scenario. Would it not be better to concentrate in the depuration of v. 5.0.0 of small details that innevitably arise and instead opt for an integration withh Open Cart or WooCommerce? Both are opensource and work very well.

Another idea (a bit radical) would be to adopt Rafael's Chacon code for electronic invoice integration (update it) and that way I am sure that the system could sold in Latin America. I am not sure if this tendency has spread in other continents, but the most difficult part in selling products in line is to comply with tax authorities with the electronic invoicing full of requirements and nuissances. If webERP could communicate with tax authorities and emit outgoing invoices to the customer and accept the incoming supplier invoices, then it could be sold anywhere (to local sellers) such modality of controlling commerce is implemented.

Please forgive my suggestion of "selling", but webERP as advanced as it looms and if it would solve the electronic invoice tendency, deserves financial reward return in virtue of its vast functionality and uniqueness (enhanced information keeping linked to the WO and other functions, exchange of sensitive production information through multiple entities across borders, etc), . It would improve the management of a score of small and medium size businesses.

Very honestly and not intended to intrude your open source values!
Enrique

[timschofield]

Hi Enrique, I would be more than happy to include the electronic invoicing code written by @rafa62 but it would need someone to maintain it. Have you had any contact with Rafael? I haven't spoken to him in a long time.

Tim

[efeoli]

Hi Tim,
I have made all efforts to contact him, but hehas not responded. The idea was just that, for him to manyain it and perhaps promote it with local businesses as a start effort and test the market. I would be glad to talk to him and coordinate.

We are completely innovative and have developed very advanced biomedical products now in human use in Costa Rica and the USA. We have no interest in selling the connected ERP to the tax authority and only wish that it is perfected and handle the market to you guys once is tested in Costa Rica.

Enrique

[efeoli]

Or, as we progress financially we could find another young developer to maintain itif Rafa doesn't show up.

[efeoli]

Are there intelectual property conflicts with finding another developer?

[pakricard]

Would it not be better to concentrate in the depuration of v. 5.0.0 of small details

Hi @efeoli : Cleaning the code of obsolete bits is part of the "depuration". I was revising code when I found that, and plenty other issues, labelled as "post v5", for us to keep in mind.
It is very difficut to keep building quality code, if we leave leftovers here and there, that can (and eventually will) create collateral damage.

instead opt for an integration withh Open Cart

I developed an integration with OpenCart, and donated it to webERP. You can find it here: https://github.com/timschofield/OpenCartBridge It probably needs a general check, but in general terms it works.

Are there intelectual property conflicts with finding another developer?

I don't think so. webERP code is open source, and everybody is allowed (and welcomed) to copy, modify, improve it ;-)

R

[efeoli]

Hi Ricard,
I have followed all your cleaning and simplification and functioning of v 5.0.0 reflects it. I appreciate how nice webERP now runs. I hope there are not many more leftovers potentially harmful.

Integration as yours with OpenCart would be ideal. Does it work with PHP >8? OpenCart now is also at such level. Why don't you guys pursue bringing it to date?

Enrique