Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Addon installer concept


piernas

Recommended Posts

Estimado Piernas:

Happy with your proposal!!!

How we can help you?

It needs to be into core? nooooooooo if it does the  life easy to shopowners they simply use it (as they use others contrib).

Here, as ALWAYS, we need find a place where find the instructions to make the zip an the extra files to 'order' the installation.

My point of view:

A contribution needs to add new files and EDIT old (core or not) files, so:

* zip file with all the files needed from a /catalog/ dir.

* in the root (not in catalog) a .php file that does the install. why not installer.php? You put it  the list of 'steeps' for make the installer: -check ver, files permisions, existence of files, etc but also the hooks for add/edit the new code.

In a second step, 'We' need study the way to make a log of the orders that 'installer.php' did, may be using a variation of 'Contribution Tracker'. In a future these orders may be executed in reverse to 'unninstall' the addom.

I suggest you that you see here:

https://apps.oscommerce.com/JWbl5&core-code-of-the-autoinstaller-script

https://apps.oscommerce.com/Profile&247516-pektsekye

They do almost the 75% of the needes you listed. The only drawback is that the 'list of steps' is written BY HAND in a xml file.

If you make a class or a sort of functions that can translate a list of human readable actions (located in an array, for example) to a xml file you will do it!

Whe array has 'verbs' that trigger a kind of functions like that:

$instrucctions_array = array (

  'action' => 'insertCode',    //  <-- this verb will trigger the actions listed below
 'file' =>  '/admin/customers.php',
  'line' => 56,
  'beforWhere' => '<div class="located place">,
  'codeToBeInserted' => '<p>A buen precio va el tomate</p>'


)

tep_insert_in_cofiguration_table ( $paramName, array $arrayOfBeautifullParams) if needed...

tep_insert_in_configuration_table ( $paramName, array $arrayOfBeautifullParams) if needed...

tep_insert_in_file_this_code

tep_uncomment_in_file_this_code

tep_add_in_file_this_hook

tep_edit_language_file_with

 

tep_write_in_log_when_installation_is_sucessfull

Another suggestion: STOP adding in classes params that almost never are used. Where need we  to  know the value of MY_N_MODULE_VERSION_NUMBER ? In the modules.php page?

If not the infinite number of define()'s will be as crazy as useless, I think)

https://generatewp.com/plugin-readme/?clone=test-plugin-readme-txt-file

Link to comment
Share on other sites

May be I'm wrong but I think almost the 60% osC installations are 2.2.  Why they can't update? We all know why, right?

30% 2.3, why? Some new shops with a version with an ongoing increase of goods contributions that does the life easy. The effors that some of you for adapt from 2.2 a lot of contributions confirm my suspects.

5%  with 3.0 -> only for intrepid people

5% with 2.4 -> only for intrepid people. Good coding but with very few contributions, I think.

IF in 2.4 is easy to add contributions, don need this code/contribution, but 2.3 needs it as wordpress need it or magento needs it, or open cart, etc.

A scrip that does a backup to your database is essential.

A script that install contributions and help you to keep them updated in a easy way is also essential.... of course in the osC version that I needs...

Shopowners want to sell products and don't think in php to much. We like to open our IDE, run our local server or our beyond compare to spend a single evening find why 'this' or 'that' code don't work...:laugh:

Edited by Antonio Garcia
Link to comment
Share on other sites

3 hours ago, frankl said:

@piernas You touched on this a little, but the sad thing is that 2.4 makes addons ultra easy to install and uninstall. It almost makes me cry to see the wasted opportunity there.

The other option is that I let the Community Version come to an end, and those who are interested can work with 2.4

Every shopowner using Community Version has a working Responsive php7-ready shop, so it could just be left.
Those who want to continue using, continue.  Those who don't, use official 2.3.x, go to a different software or pitch in and help on 2.4.

I have an issue with 2.4 and transparency of just what is exactly going on with it, but that is for another time.

Edited by burt
Link to comment
Share on other sites

17 minutes ago, burt said:

The other option is that I let the Community Version come to an end, and those who are interested can work with 2.4

IMHO, I think this is the way forward, if we can get a proper management structure in place to keep things moving.

Dan

Link to comment
Share on other sites

20 minutes ago, burt said:

The other option is that I let the Community Version come to an end, and those who are interested can work with 2.4

I agree - Finalize 2.3 Community Version as it stands now. It is workable and for those who want to stick with older addons it should work.

The rest of us should focus energy on 2.4 ....  That's to say  2.4 Community Edition because I do not think any official will ... blah blah blah .....:blush:

 

Link to comment
Share on other sites

31 minutes ago, burt said:

The other option is that I let the Community Version come to an end, and those who are interested can work with 2.4

Every shopowner using Community Version has a working Responsive php7-ready shop, so it could just be left.
Those who want to continue using, continue.  Those who don't, use official 2.3.x, go to a different software or pitch in and help on 2.4.

I have an issue with 2.4 and transparency of just what is exactly going on with it, but that is for another time.

Sadly, there is know one  steering that (2.4) ship. 

I’ve (as a shopowner) abandon the idea it will ever come - my only hope lay with the community versions. 

 

Link to comment
Share on other sites

12 minutes ago, azpro said:

I agree - Finalize 2.3 Community Version as it stands now. It is workable and for those who want to stick with older addons it should work.

The rest of us should focus energy on 2.4 ....  That's to say  2.4 Community Edition because I do not think any official will ... blah blah blah .....:blush:

 

+1

Link to comment
Share on other sites

piernas - I think this is a good idea if you can figure out a way to get it to reliably work. It's too bad one or two of the posters gave you such a hard time and were so negative about it. There's just no reason for that. 

I see two main issues with the project:

1 - Someone referred to an auto-installer addon written a few years ago. I had written one several years before that but it became too difficult to maintain due to all of the possible variations. I told the same thing to the programmer of that addon and, if you read the thread, he ended up having the same problem. Maybe you have figured out a way to make changes to core files when needed from the script but I have my doubts.

2 - I think for it to work, there would have to be some sort of structure for the addon, like all new files it has are to be in a directory in the addon package named new_files. That is a simple thing but many addon contributors don't do this so for their addons to work with your script, they would have to change their package and upload again. This is the main problem, I think, because creating extra work for developers will probably not accomplish what is needed.

But for addons that are strictly new module files, this would be a good start. There would have to be a way to mark the addons as modules only, maybe just a simple statement in the package. Your script could then download the addon, search for that text or file and, if found, extract the files and install. Of course, the files would have to be in a defined directory so the script could find them. This would still require the developers to make a change to their addons but it would be a relatively simple change so I think they would be more likely to do it. Many addons require file changes but there are also quite a few that are just uploads and your project would work with those quite well. I think that, over time, the number of addons that are just module uploads will increase so having a basic install for those already in place would help the project.

If I were coding it, I would create a cron job to read in the addons and create a list of ones ready to install. Then the shop owner would just need to click a download and install button for any he want to install.

I wish you good luck with it and think you should proceed.  I don't have a lot of time to get involved with coding but I will certainly help if I can.

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

Hola Juanma @piernas,

You could have a look into my installation scripts in ht_points_rewards.php of the Points and Rewards BS add-on:

https://apps.oscommerce.com/G5ep5&points-and-rewards-bs

It auto installs the hook register (not needed any more) and the hook calls in several core files. It also checks applications_top.php for hook support and installs it if needed.

There are also uninstall, check scripts and error/success messages included, all done via class methods.

The scripts are not generic, they are specific for the points and rewards add-on and for sure need a lot of "polishing", but they may include some snippets or ideas for your project. Use it for your convenience.

Here the ht module:

ht_points_rewards.php

Something similar I used in the newest version of sloppy words cleaner:

https://apps.oscommerce.com/Aoyvj&sloppy-words-cleaner-reloaded

st_swcleaner.php

 

 

Edited by raiwa
Link to comment
Share on other sites

16 hours ago, raiwa said:

You could have a look into my installation script

Yes, I saw these scripts and also I think that they should be a good starting point.

All these functions packed in a generic class plus another zip class that handles read/copy, etc may do the work.

(Guau! How easy is make code whitout write it!) :laugh:

In the other hand, I'm a 2.3 hooligan, so in the next osC football match competition I like play with the 2.3 team, with the number 4...

Link to comment
Share on other sites

I don't think anyone is going to argue against addons being easy to install or update. I'd really like to be able to avoid ftp altogether but that clearly needs core stuff.

It is more realistic now that there is so much more that can be accomplished without changing core code.

I've been doing something around this myself - starting with making an addon able to identify a new version is available, and offer a one-click install of an update, and offer a paid version with more features in the same way.

It doesn't take long before you need some decent configuration management behind it!

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

Sorry I've been out this past days.

@BrockleyJohn I had a modest idea for start. Didn't have in mind a version checker. I think that would be best accomplished with a new marketplace as @wHiTeHaT mentioned, but that's a step beyond of my idea. I'd implement it later because a marketplace needs much work and thinking before it's operational.

@wHiTeHaT I'm not sure if I understood wel your first video. It packages files on a zip file right? Why don't you just use 7-zip winrar or other GUI instead? What's the need of programming there?

My idea is a tool that lets you install all those modern addons that does not require core code changes, that installs them without touching ftp/mysql from the shopowner but also simplifies life for programmers who doesn't need to add any install instructions or explain users how to upload files or modify tables.

The core part (I mean the functions of the installer) would manage an addon record, so you can easily check new versions and inform you, for example, if the addon you just uploaded is already in the system and if the version is bigger than the installed one. Will also copy and remove files and create new tables or fields and set registry constants.

But that also works for more complex installations. For that, after the installer processes all the common functions mentioned, the coder would be able to do other things, like modifying core files, but that would be done by the php supplied with the install package, not by the installer. The installer would only call the custom installation part at that point. In this case, it's the programmer who should add the code to modify those files (open file, search for the correct place, write lines, close files). So the part done by the installer can be extended in most cases, but would require extra programming. So:

- Pack/unpack install package -> installer common routines

- Check for existing version/compatibility -> installer common routines

- Copy/overwrite/remove files -> installer common routines

- Create/remove/modify database tables/fields -> installer common routines

- Modify existing files (currently not reccomended on community version but still necessary in some cases) -> install package own routines. These has to be programmed by the addon maker.

@raiwa will take a look at your addon tomorrow. For your comments I think it will do similar things like the ones I have in mind.

Will also take a look to the other previous installers mentioned by @justcatering and @Antonio Garcia. Maybe we're talking about something that's already solved!

@frankl @Dan Cole @azpro and all others - I've also tried 2.4. I've been playing with templates and you can do a lot of things! I love it! but, among other things, the attributes part is completely missing ( @wHiTeHaT started working on it time ago but the project seems to be unfinished), so 2.4 it's not functional. We could work on it, but what about the commander in chief? He's gone and we don't have no idea on what's going on in his head - Should we continue the work without knowing what will happen with that code when commander returns?

 

 

 

Link to comment
Share on other sites

@raiwa just took a look at you code and yes, that's the idea. Installer would do those checks himself (if a table exists, if another module is already loaded) so you can avoid checking if the module is installed every time the module is called.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...