Core bugs and marketplace submissions
Permalink
Every now and then we get a marketplace submission to the PRB containing any of:
- deprecated code
- code that is very poorly structured
- code that contains edge case bugs
- code that contains security loopholes
The PRB likes such issues to be resolved before approving a submission.
Sometimes the developer is perplexed because they followed an example of code from the core, from a previous marketplace item or from the documentation. However, that is not a valid excuse for the issue to be allowed through the review process.
The core is big, complex and evolving. It contains historical issues and bugs. Despite the best efforts of the PRB, addons already in the marketplace can also contain historical issues and bugs.
That a new marketplace submission follows a poor or faulty example is not a justification to propagate the problem further. The correct course of action for any such issue is to report it by raising an issue on github, filling a bug report on concrete5.org, or opening a support request to an addon developer.
Obviously such issues are not always black and white. Sometimes the best we can hope for is a marketplace submission developer to do a reasonable best in cleaning a problem up rather than a complete resolution. A certain amount of judgement is involved and we try to be fair about it.
- deprecated code
- code that is very poorly structured
- code that contains edge case bugs
- code that contains security loopholes
The PRB likes such issues to be resolved before approving a submission.
Sometimes the developer is perplexed because they followed an example of code from the core, from a previous marketplace item or from the documentation. However, that is not a valid excuse for the issue to be allowed through the review process.
The core is big, complex and evolving. It contains historical issues and bugs. Despite the best efforts of the PRB, addons already in the marketplace can also contain historical issues and bugs.
That a new marketplace submission follows a poor or faulty example is not a justification to propagate the problem further. The correct course of action for any such issue is to report it by raising an issue on github, filling a bug report on concrete5.org, or opening a support request to an addon developer.
Obviously such issues are not always black and white. Sometimes the best we can hope for is a marketplace submission developer to do a reasonable best in cleaning a problem up rather than a complete resolution. A certain amount of judgement is involved and we try to be fair about it.
An addon doesn't need to give a perfect edit mode view when the core isEditMode() bug happens, but the addon at least shouldn't give a rush of secondary bugs. Usually a test early in and addon's view JavaScript for
is enough to protect the edit dialog save from returning errors.
If your dev system is not showing the isEditMode() bug, you can test the above JavaScript behaviour by temporarily hacking your php test to make sure it fails, for example:
Once you have tested, remember to hack it back again (remove the 0&& part) !!!