Market clean-up (attention to all developers)

Notice to all developers.

We're are going to remove the products from the Market which broke the script after the upgrade.

These are the modules which modify a lot of files and when new version is released and upgrade overwrite modified files, the whole Dolphin script becomes broken. 

We've noticed that these are the modules which adds a lot of additional functionality to the BoonEx modules. It's better to clone the module and modify own copy in such case.

When we'll notice such modules in the Market we'll send notice to the developer and we'll allow 3 months to update the module to make it comply with new rules. Developer can request more time for updating the modules if their has more than 1 such module.

We hope that it will make life easier for

- customers: since modules will be independent and the script will be more stable after version upgrade

- developers: no complains that module and Dolphin stop working after Dolphin upgrade

- boonex: no complains and smooth upgrades

It's recommended to develop modifications free modules, if developer need some feature to achieve this they can submit pull request with needed modification.

We are going to see a lot of good modules disappear from the Market because Boonex does not provide hooks.  I guess we need to grab our modules from the Market before they disappear.

You need to expand on this statement because I don't believe you mean you will add a hook to the code if I need it for a module.  Plus, does this mean that every time a developer does need "some feature" added that a new version of Dolphin will be released or will a developer have to wait a couple of years for the "some feature" to be added so he/she can release their module?

Boonex tends to throw this stuff out without details.

@geek_girl: Nowhere do I see it mentioned that all mods are banned. Just the ones that equate to completely replacing a core module with its own files and code. Line edits and additions of code to core files are necessary if code in Dolphin isn't available to do it in a module - BoonEx is only saying everything should be a module if possible to make it easier, and that they're open to pull request to enhance the code to allow it.

Nathan, I did not say that all mods will be banned; of course mods is often used as a shorthand for modules; so when one say mods, it is not clear if it is a modification, or modules.

At any rate, this is what AlexT stated: "These are the modules which modify a lot of files and when new version is released and upgrade overwrite modified files, the whole Dolphin script becomes broken."

So yes, a lot of modules in the market that require core files to be changed will no longer be in the Market.

Based off Alex's mention of cloning the module, it's clear these are modules that work by replacing a BoonEx module with its own files - so the BoonEx module is replaced. So if it works by planting itself into /modules/boonex/modulename, that's the problem being highlighted.

Your own module under its own directories is fine. Making edits to core files to achieve some needed functionality is fine. Completely replacing core modules isn't. Most developers do not do that, but there are some for one legitimate reason or another. And Alex is saying this is bad practice that can cause problems, and needs to be prevented. So for those cases, it's better to make them into their own modules than to keep requiring replacing core files every upgrade or dealing with possible database issues.

So to round this up:

• 3rd Party Module: Fine
• Some edits to core files: Fine
• Replacement of BoonEx module files and database with a new module: Not fine

I understand the purpose for the change; Boonex wants to reduce service calls and make it easier for non IT/sys admins to upgrade Dolphin.  I encountered the problem AlexT outlined myself, during the last upgrade a module from Deano caused a php error when going to the account page because I forgot to include the code changes required for Deano's module.  Of course as soon as I saw the error message I smacked my forehead and included the code changes.  No big deal for me.  I have numerous core file changes on my site both from myself and from modules that I use.  Those modules will now be required to be removed from the Market meaning no future updates from the module developer.  I hate to see these modules disappear which is why I have asked about a third party Market; a central third party Market for vendors that want to continue selling their modules that require code changes to core files.

@Nathan; you are seeing one thing, I am seeing another.  I guess we need to wait for Boonex to expand and clarify; which I hope does not mean waiting a week.  

Let's be clear to the community, this is not necessarily the policy, unless you are claiming to be a part of the policy board in your role of MasterBosun.  I know there are members here that are sitting on a Boonex board.  Were you a part of the policy decision?  Even so, I want to hear it out of the mouth of Andrew or Alex.

And of course you need to defined "some edits".

You are correct - a lot of people think of modules when somebody says "mods". To be clear:

• Mods: Requires changes to core Dolphin files - a mod[ification]
• Modules: Standalone and can be installed/uninstalled from the Admin Panel. No (or few) core file edits.

Here's what AlexT wrote:

We've noticed that these are the modules which adds a lot of additional functionality to the BoonEx modules. It's better to clone the module and modify own copy in such case.

It should be made more clear, but I can say that these are modules that are actually mods of BoonEx modules. They work by replacing the BoonEx module with their own, and have massive amounts of code changes, and also sometimes database changes. This isn't always an issue, but it can be. Dolphin patches don't assume this has happened, so doesn't take into consideration that the BoonEx Boards module is now Foobar's Boards and has a lot of database edits with all module files modified in some way. So the patch replaces the board's modules files, and also applies some database changes that cause a conflict and fail. It's better for Foobar to release their own version of the Boards module under their own name and vendor folder. It should be possible to transfer data from one to the other if it's based on Boards and uses a similar database setup.

Here's what AlexT says about all other mods:

It's recommended to develop modifications free modules, if developer need some feature to achieve this they can submit pull request with needed modification.

It's only a recommendation to avoid mods. But I think we can all agree that mods should be avoided. They are messy and can create headaches. But sometimes they are needed. For example, if somebody develops a mod to implement thumbnails in the sounds module, that requires core code changes to a few files. These are usually a few lines here or there. No massive replacement of code, but still changes. That's fine. It's better if the code is added to Dolphin so no mod is needed, but that's all.

I was indeed involved in some of the chats about this, so I do know the issue and what exactly these changes are about.

I still want Andrew and Alex to come in and be very specific about what is going to be allowed.  Because any modules or mods that change code in core files can break Dolphin in an upgrade and that is exactly what was mentioned by Alex.  The module or mod from Deano broke a Dolphin upgrade and it was one line of code in one file.

There was several areas mentioned in the post; it needs to be stated very clearly and specifically by Boonex what will be allowed in the Market.

Nathan, you seem to have miss this statement:

We're are going to remove the products from the Market which broke the script after the upgrade.

These are the modules which modify a lot of files and when new version is released and upgrade overwrite modified files, the whole Dolphin script becomes broken.

This part is actually ridiculous because for one, even a one line change in Dolphin code requires a whole new version release.  Secondly, Boonex is not going to add hooks left and right for all the developers that might need them for modules that need to bypass or change code. 

No. the solution is that we are going to need a third party Market for all the modules that change code in core files; and maybe other modules as well.

@geek_girl: You're reading into this too much. Here is what AlexT says about removals:

We've noticed that these are the modules which adds a lot of additional functionality to the BoonEx modules. It's better to clone the module and modify own copy in such case.

When we'll notice such modules in the Market we'll send notice to the developer and we'll allow 3 months to update the module to make it comply with new rules. Developer can request more time for updating the modules if their has more than 1 such module.

"... which adds a lot of additional functionality to the BoonEx modules. It's better to clone the module and modify own copy in such case. When we'll notice such modules in the Market..."

That's all that's said about removals. If there's a module in the market that works by completely replacing the BoonEx module files and database entries with its own, that's what's no longer allowed. A third-party module in its own vendor folder that also requires editing /inc/design.inc.php is fine. A third-party module that moves into /modules/boonex/modulename and uses its files and database entries is not. Developers have three months standard, but can request more time. That's all. No fire and brimstone about mods themselves.

I am attentive to this discussion and I understand Boonex's preoccupation. This seems logical for more homogeneity.

Now I guess that applies to UNA as well. That's why I do not understand why since the beginning, the profiles in UNA do not contain standard default fields like this is the case in dolphin pro, I think of fields like, date of birth, age, etc. .

If I understand correctly this post, it prevents a lot of initiative to resolve these shortcomings which are important (to me). So this is bad news ...

I also think of a profile search module, of course, it is not justified for now because precisely there is nothing to look for.

Is this kind of thing you call "hooks" GG?

 Good move!

We aren't going to remove many modules from the Market, it just for the some particular cases of the modules. I've described just the general description of such modules, and as Nathan said, in almost all cases they are the modules which replaces files for some of the default modules:

Just the ones that equate to completely replacing a core module with its own files and code.

Alex, I am not trying to be an arse here but you are still using some generalities in your statement;  "in almost all cases" so this would say that there will be some cases in which it is not just replacement of default Boonex modules. What are those cases?

Alex, in your original statement: "We're are going to remove the products from the Market which broke the script after the upgrade.

These are the modules which modify a lot of files and when new version is released and upgrade overwrite modified files, the whole Dolphin script becomes broken. "

There are modules in the market (and everything is listed as modules) that require code changes in core files that can cause Dolphin to stop working after an upgrade.  For example, a module needs a line of code added to utils.inc.php   A Dolphin upgrade overwrites utils.inc.php removing the needed line of code.  After the upgrade going to member.php results in a white screen due to a php error.  That module has broken Dolphin after the upgrade.  So even though that module does not replace a core Dolphin module, it is included in your original statement.

So, are you going to release a new official statement clearly outlining what is allowed by modules? We need a clear understanding before we see modules disappear or before we work creating a module only to have it denied by Boonex.

I am not arguing against the new rules; Boonex gets to decide the rules.  I just want a clear understanding of what the rules are concerning modules.

I own tons of modzzz modules, i hope this does not affect any of them!

Allot of developers have abandon their modules and left boonex, boonex should update these modules themselves and off them to the members for free.

May I add a suggestion, when you clean it up please add he categories back to separate the different modules into classes and another good idea would be to add a link to related modules so members can easily view related mods and not the other mods by the same owner.  

Regarding modules, I understand the original intent was to allow for additional functions that would not affect the Dolphin core. Modifying existing modules is at the site owner's risk. That being said, a majority of my work is about modifying existing modules but if required I have created standalone modules that will not break if Dolphin gets updated.

Back in the early days of Dolphin 6, I remember the major issues with custom mods being applied to Dolphin then the site breaking. If anyone remembers, having modules was suppose to fix all that. But some are not modifying the Dolphin core, but the mods themselves and that's when problems start to occur. While slightly better, it is not in line with the original intent.

By working with distinct mods that would install with Dolphin, it keeps things tidy but it also takes more level of effort to create custom functions by the developer. While the easy way out is to add to an existing module, in the long run, it does end up being better for the site owner to use a pure module. That's been my experience with Dolphin relating to mods. Unless, you really have to mod a mod, using a pure module is the best route.

My suggestion to BoonEx is to create more hooks into Dolphin so that it's easier to add custom code into the core without having to go through the whole parade of module development. From what I can see, UNA might allow for this.

Copyright prevents this action.

Nothing stopping the boonex crew from changing their TOS for developers to make abandoned modules community property.

Changing just a mere 30% changes the copyright law and I'm sure more than 30% of the code may be changed to bring the module upto date.

LOL, not sure where you are getting your information, but I'd like to see you change 31% of Windows 10 and try to publish it. Microsoft would tear you a new one. 

Please, let's keep this thread on topic; Alex and Andrew have yet to answer my last post.

What would be good would be to alow members who have purchased the mods/modules that get removed to still download them from their accounts, while adding a temp block of purchasing them by non owners.

I've purchased items before that have ended up being removed, and had them running on a site, then for some reason (cant remember) had to re-download the item but found it dissapeared as Boonex removed it. That decision by Boonex became my loss.

Surely we should be able to still dload, but not purchase items that cause issues if we've already paid for them.

Failing that, there would need to be a forum post announcing a list of all mods/modules being removed with 3 month notice not just to devs but to members also so we can dload for local storage. Should be sticky post...

I like this idea, maybe they can also upload them to GitHub so the community can make change in the code for those old modules, also maintain it...

The modules are copyrighted by the developers.  Only the developers can release them as open source.

The topic under concern here is what exactly will be the criteria that Boonex will use for removing modules and for future modules.  There is some vague wording that needs to be clarified.

Its just a suggestion. I believe that if they left  Boonex then they perhaps give those modules for the community for free.

Again:

Alex, in your original statement: "We're are going to remove the products from the Market which broke the script after the upgrade.

These are the modules which modify a lot of files and when new version is released and upgrade overwrite modified files, the whole Dolphin script becomes broken. "

There are modules in the market (and everything is listed as modules) that require code changes in core files that can cause Dolphin to stop working after an upgrade.  For example, a module needs a line of code added to utils.inc.php   A Dolphin upgrade overwrites utils.inc.php removing the needed line of code.  After the upgrade going to member.php results in a white screen due to a php error.  That module has broken Dolphin after the upgrade.  So even though that module does not replace a core Dolphin module, it is included in your original statement.

So, are you going to release a new official statement clearly outlining what is allowed by modules? We need a clear understanding before we see modules disappear or before we work creating a module only to have it denied by Boonex.

I am not arguing against the new rules; Boonex gets to decide the rules.  I just want a clear understanding of what the rules are concerning modules

Thank you for the responses. 

@baloo

> Now I guess that applies to UNA as well. That's why I do not understand why since the beginning, the profiles in UNA do not contain standard default fields like this is the case in dolphin pro, I think of fields like, date of birth, age, etc. .

In UNA we don't allow modifications at all, but we will add necessary hook if needed as soon as possible - actually in Dolphin the same.

@jtadeo

> My suggestion to BoonEx is to create more hooks into Dolphin so that it's easier to add custom code into the core without having to go through the whole parade of module development. From what I can see, UNA might allow for this.

We're open for suggestion from developers (or better pull requests). We've made several calls to developers to add necessary hooks, but no one responded.

@geek_girl

> I am not arguing against the new rules; Boonex gets to decide the rules.  I just want a clear understanding of what the rules are concerning modules

Nathan provided very good explanation, and I 100% agree with him:

So to round this up:

- 3rd Party Module: Fine

- Some edits to core files: Fine

- Replacement of BoonEx module files and database with a new module: Not fine

@BoonEx why you dint your "Upgrades" ion a way, that changes still working?

Whit Dolphin a Upgrade means new Bugs, new Errors and that the expansive buyed Modules are not working.

If a Mudule that costumers have Bued is not Working after a Upgrade, do you pay it back?

If not you have to make the changes in a other Way so that the modules still working.

Doplhin is a Collection of Reasons to be  pissed off

 What in blazes does some edits mean? You are still not being specific here.  One line of code added, 10 lines of code added? Do I get to change a core function?  What does some edits mean?

To try and be the definitive definition and provide clarity to this:

"Modules" that completely replace BoonEx modules are no longer allowed. Requiring the user to edit some class files and add/replace snippets in files is still allowed and fine (it's easy to re-apply those to the patches or site). But requiring a user to upload a fully-modded module into a BoonEx module and make it its own is not.

Examples:

* "Edit /modules/boonex/boards/classes/BxBoardsModule.php and look for line... replace with...": Fine

* "Upload /modules/boonex/boards" and overwrite all files. Then install the Foobar Boards module": Not Fine

Basically: You can't take over a BoonEx module as your own module. If you have a super-awesome module to replace Boards, it needs to be repackaged as its own module. You can't have it work by replacing the BoonEx module and using all its files and database entries. You CAN have improvements to the BoonEx modules with file edits. Mods themselves have always been discouraged, but are still allowed and sometimes needed. AlexT only asked that if some kind of hook or change to functionality is needed to make a module mod-free, they're open to it in order to make it easier on everyone.

Mods are not banned. But total-conversion mods that make a BoonEx module into the developer's own module are not allowed now. So if you have in the market a module that requires a few line edits, that's fine. If you have a mod that requires uploading some files and editing some files, that's also fine (PLEASE comment the start and end of any code changes - you'll make my day much easier!). But if you replace a BoonEx module with your own module and take its files and database entries as your own, that's not fine anymore.

 Finally!

Now to read the rest of this thread.

~~~~~~~~~~~~~~~~~~~~~~
Michel ✈ Meta-Travel.com
~~~~~~~~~~~~~~~~~~~~~~

Just to add, I would consider any Module that needs edits to core files not fine at all.

It is these little lines of code, if not followed properly, that cause all the problems.

Then people need to go back and keep track of which files might have changed, when doing Dolphin upgrades, and add the lines of code to the core files all over again.

Sometimes these core files change so much that the Module code edits no longer fit in where they should.

~~~~~~~~~~~~~~~~~~~~~~
Michel ✈ Meta-Travel.com
~~~~~~~~~~~~~~~~~~~~~~

Requesting an update on this post.  Has Boonex compiled a list of modules that are going to be removed from the Market?

We inform vendor privately when we find such module.

So you are just going to leave the community clueless about deleting modules from the Market?  Suppose we want these modules even if they change dozens of files?  Not all of us are just users, many of us have the skills to handle such modules.  You are doing this to cover Boonex's arse so they have less support issues.  Not telling us which modules are being removed is bullshit.  So the community as a whole has no fucking idea what Boonex is removing from the Market, BULLSHIT!

How about informing the people that spent their hard earned money buy the module? 

Chillax a little bit, It's vendor's job to let their customers know. If they are still active here, they will most likely update their modules.

Vendors that left will probably not, so just save a copy of your purchased modules if you still care.

I'll take a stab in the dark: there's no reason to tell people when they message a vendor, because most likely the vendor can resolve it, especially since BoonEx hasn't set some kind of hard time limit. You only need to be notified if removal is imminent, and I see no reason why BoonEx wouldn't do that, or keep it available for customers only to access. Or the vendor could let customers know.

Only products at risk are those packaged as modules or similar that actually replace all the BoonEx module's files and database entries as its own. The vendor just needs to repackage it as their own module. Importing data from an existing install of the old mod/BoonEx module is the biggest hurdle, but that's probably part of the reason for no hard time limit.

Yes, BoonEx will have less tickets to handle because the upgrade no longer makes the site turn all white. So will the vendor. The customer won't have an issue after upgrade. There will be no need to re-upload module files each time or worry about some database change causing a conflict.