1
DCrussader
Propose for Coding Standards and Rules (for last time)

Here no one likes the rules, but believe they're make everyone's life easier. Users, translators, testers, other developers.

First...
Such modules as APCal must be threaded as hostile (https://xoops.org/modules/news/article ... ootid=55938&#comment55946)

Module which not uses provided directories and libraries with the core must be categorized as 'non-trusted'. If the module requires 3rd party library which is not present within latest XOOPS distribution, it must place it in the dedicated folder for that reason - Frameworks/ Libraries/. Not everyone to use whatever he decides, Cli/, Common/.

2nd XOOPS is already bloated with definitions, why the module developers simply don't call and use them instead to write new ones for the same things and to make language files bigger and bigger with every new release.

3rd Unicode UTF-8 at all, no more mixes with ISO/UTF-8, it's standard, if u are using ISO, u're out of this ages, nothing works fine on ISO. Not the advertised Multi-lingual function with XOOPS.

4. Clean and understandable ENGLISH only language files distributed with the modules, I don't care where from you grab the first copy of your future work and on which one is based to be forked. Nor the user cares, if got future questions and bug reports. Translations are provided from Transifex, only people working there hard to make XOOPS and it's modules available to they're countries, deserves to be packed and distributed with the module.

5. When you fork someone else work, please (no, no please anymore) RENAME the damn module, it's no longer the one created by the initial author.

6. Maintain discipline when u writing Language files, pseudo formatting will make it less usable, and u will won nothing with that. Specially not and single translated string.

7. All language files must end (for now) with LF+CR, no matter what PHP.NET says, you want popularity - u will follow.

8. Every module must be packed with ZIP or 7Z, no rars, no crappy UHA or else unknown archiving formats or paid such as RAR.

9. Every module must include in the root folder
/htdocs/modules-required directories
README
INSTALL
CHANGELOG
GPL v2 or v3 copy

10. If you're not native English speaker, and u can't create English language file for your module, contact with the proper Team Leaders on Transifex, instead to make some crappy English version with google translator or bing.

11. When u release a news story about your work, provide accurate mirroring on SourceFore.NET or Google Code, they're not going down like your shared hosting somewhere in Argentina or Mexico or Sudan. Add a link to support thread in forums on this site, ppl can't learn, speak and write in Every language on this planet, nor they to be forced to register everywhere to ask question or to submit bug report.

12. Forcing people to register somewhere to download a thing released under GNU GPL is in conflict with GPL and I'm asking kindly XOOPS.org to take actions against GPL abusers. GPL products must be freely world wide accessible.

13. Regarding paid modules, release them under different license, GPL (for me GWL - General Warez License) - allows to be distributed for free, if u wont start such threads here, change the license before the release.

14. When you release a GPL module, it's in your right to display your copyright link on the module index page, but also there must be and option to be turned off. Otherwise you're GPL abuser and your work will be hacked, sooner or later, APCal or else may go under new name, or patched by someone simply to remove this copyright which is copyleft information. If you don't wont that - put a option to be turned off (this can be done in 2 ways).
14.1. By free will - the option is there, and everyone can decide by himself to show your copyleft information or not.
14.2. By donating a fee, not 20 EURO for sure, 5 are enough. So there be a option for entering token given by you - the developer, so this copyleft to not be seen on the user site.

15. Make several readings on latest version of General Public License and ask yourself what you're doing and does this license fits your needs. There is Creative Commons organization, and thanks to XOOPS which not maintain such blind restrictions as J! community, u can have your work released under non-restrictive CC License.

16. Diplomat position is required to make peace (...or "Remember peace is a Lie") with rest forks, 4 groups of developers can make 4 different strong full of exciting features cores.

17. Task Giver (Someone evil and polite in same time) and Censors are required too.
Task giver to know what and who works on current tree, and who can make the requested change or adding feature and who not, not feature requests for XOOPS 2.0.18 still to be with status Open, not even rejected or closed with reason. Censor, to look after all 3rd party developers - what they're provide with they're modules, thumbs.db or language files made with automated translations, or adding invalid spaces and pseudo formatting everywhere.

18. Wiki maintainer to install, maintain and keep up to date Wiki sections with help for every module. Some module developers right now may want to provide help, but with current /help option this is not possible. Some people want to provide documentation for different stuff/tasks in XOOPS - but there is no such place.

19. Personal GForge, dev.xoops.org idea was nice, but was released in worst way ever. Every single module, template developer or XOOPS hacker to be able to make his own project page. Since XOOPS in on server (VPS) this wouldn't be a problem. 100 USD for shared hosting is damn too high price.

20. Graphics designers to make professional, good looking and catchy promotional materials.
By this market share (http://www.opensourcecms.com/general/cms-marketshare.php) XOOPS is bellow the dead Mambo, the core used for Joomla! to be made.

21. Imtfan, me, Mamba and active core developers to make a forum thread for and against INI files, and finally this PHP DEFINE to go in history once and for all.

22. 3rd party translator which is using Notepad or Notepad + or else providing any kind of translations, to contact with the proper team leaders on Transifex, before to be published anywhere or distributed with module. Saw already amazing translations in Bulgarian, Macedonian, Serbian and Afrikaans languages made with Google, thanks but such ppl for me deserves nothing more then ban on IP (on both places, TX and xoops.org) and to forget for anything else in future.

23. Adding strict terminology for the core process of XOOPS, damn weight must gone once and for all, mistakes made by banned cms such as in they're content module:

News 1.68 Beta 1
In one file on 3 different lines u can see 5 different misleading bugs
Story is published by %1
Articles in this topic %1
News in total %

Content taken from 1.3.2.1
Module Name Content
"Contents submitted by %1"
"Groups allowed to add contents"
Won't mention AMS and rest.

First content can't exist with s, 2nd the content is used mainly for articles in both places. Single page with one word is article, not story, not content, not contents, not news.

24. Strict names for the distributive packages, eg.
core-version_modulename-version.zip or .7z (lately if the installer is added to the core, they're should be in Zip only)
XOOPS2.5_ModuleA-1.01.zip - not XOOPS2.5.5_ModuleA_1_01.zip

(Can someone sticky it, I want to see your comments)

2
Anonymous
Re: Propose for Coding Standards and Rules (for last time)
  • 2012/8/9 21:24

  • Anonymous

  • Posts: 0

  • Since:


I guess many of the issues you bring up can be tackled by coloborating when making modules, Xoops is not called a community for no reason. Module developers need feedback from others, help by changing code, others to correct english spelling, make a nice readme and so on...

3
jagibu
Re: Propose for Coding Standards and Rules (for last time)
  • 2012/8/9 21:55

  • jagibu

  • Just popping in

  • Posts: 68

  • Since: 2005/6/17


Quote:
24. Strict names for the distributive packages, eg.


What with paths inside packages to easy installation (without manually creating/ moving folders and reading installation.txt )?

1. simple module -> core-version_modulename-version.zip
paths:
/modulename/..other_paths ( easy copy to xoops/modules)
or
modules/modulename/..other_paths ( easy extract in main xoops directory )
or
public_html/modules/modulename/..other_paths ( xoops installation pack )

2. modules like protector
public_html/modules/modulename/..other_paths
+
public_html/xoops_lib/modules/modulename/..other_paths ( like xoops installation pack, but here is problem -> xoops_lib in other root path )
/ IMO why not force separated public_html and xoops_secure( with /xoops_lib and /xoops_dat - this is recommended ...) /

3. modules with frameworks and other paths
Frameworks/"create_new_one"/
or
public_html/Frameworks/"create_new_one"/
or ( damn ;P )
xoops_lib/Frameworks/"create_new_one"/
or (better)
xoops_secure/xoops_lib/Frameworks/"create_new_one"/ ( outside public_html )

+ other paths like
public_html/uploads/"module name"/ ( tagged by modules )
or
public_html/uploads/photos ( photos or files or other tagged by category )


4
jagibu
Re: Propose for Coding Standards and Rules (for last time)
  • 2012/8/9 22:03

  • jagibu

  • Just popping in

  • Posts: 68

  • Since: 2005/6/17


Quote:
What with paths inside packages to easy installation


Standard will help with universal autoupdate function.

5
Mamba
Re: Propose for Coding Standards and Rules (for last time)
  • 2012/8/10 1:54

  • Mamba

  • Moderator

  • Posts: 11204

  • Since: 2004/4/23


We already have a spreadsheet with a checklist for module developers. I just converted it to Google Docs, so everybody can access it, and the Editors will be able to collaborate online for updating it.

I was going to add a section for Translations there in the next week or so, based on recent discussions here, but your post makes it easier to start earlier

There is also another document that I've published last year: "Standard Module Structure Guidelines"

So you post in an excellent head start for us! Thanks!

I'll be reviewing your list, but one quick thing that caught my eye that is different is:

Quote:
9. Every module must include in the root folder
/htdocs/modules-required directories
README
INSTALL
CHANGELOG
GPL v2 or v3 copy

All documentation should in /module/docs.

As I said, I am glad that you started this discussion. Let's include the Quality Team with Cesag, and let's consolidate all the different information into one clear process that could be used as Quality Assurance Checklist.

This will be the tool that we'll be using for XOOPS 2.6.0 "approved/certifed" modules.
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

6
chefry
Re: Propose for Coding Standards and Rules (for last time)
  • 2012/8/10 7:46

  • chefry

  • Home away from home

  • Posts: 1005

  • Since: 2006/10/14


I would like to add that developers should test their product a little more thoroughly before releasing them. If they say it works on xoops xxx, then it should work "out of the box" on xoops xxx, without a bunch of hacks, mods, etc to core files.

I unfortunately have to point my finger at Wishcraft here as a case in point. I have yet to get ANY of his modules to work "out of the box" even on a clean install with the specified additional modules. And his product support leaves a LOT to be desired.

Any module should work "out of the box" and should only need debugging to find errors.

And only the Xoops team should be able to say when a module is "FINAL" because "Final" means it's been tested, debugged, and works on the specified xoops xxx without problems.

7
DCrussader
Re: Propose for Coding Standards and Rules (for last time)

Quote:

Module developers need feedback from others, help by changing code, others to correct english spelling, make a nice readme and so on...


Usually is like this, but here someone - just throw release after release without paying attention to discovered bugs or problems with they're work - wont mention nicknames anymore.

In paths talking about following strict XOOPS paths
There are:
/Frameworks/
/xoops_lib/Frameworks/
/class/

Everything else such as common/, libs/, libraries/, mycontent, etc. to be tagged as "hostile".

If module developer requires to use 3rd party extension which is not distributed with latest core of X to be placed within /Frameworks or xoops_lib/Frameworks, not everywhere.

Packaging like some versions of AMS - directly in the root folder of the module - same tag.

Protector for me is still on alpha stage or preview release, until all bugs are removed and becomes integrated part of the core, wont mention it at all - perfect example for "how must not write any modules in future".

Quote:

public_html/modules/modulename/


that's should be the whole path like in latest XOOPS Distributions
htdocs/modules/modulename
or
htdocs/
Frameworks/ (if need to add additional required libraries) or /xoops_lib/Frameworks
modules/modulename
docs/mention above papers.

Quote:

+ other paths like
public_html/uploads/"module name"/ ( tagged by modules )


This is pointless, since Catzwolf (wf-downloads) and ...catz (NewBB 2.02) can make function for auto-creation/population of required folders in uploads/, adding such folder is pointless and away from KISS.

Quote:

Any module should work "out of the box" and should only need debugging to find errors.


+1
Wish is not the only one, but yeah - his modules leads the chart.

Quote:

And only the Xoops team should be able to say when a module is "FINAL" because "Final" means it's been tested, debugged, and works on the specified xoops xxx without problems.


...and don't have conflicts with naming!

8
Shine
Re: Propose for Coding Standards and Rules (for last time)
  • 2012/8/10 21:53

  • Shine

  • Just can't stay away

  • Posts: 822

  • Since: 2002/7/22


Quote:
5. When you fork someone else work, please (no, no please anymore) RENAME the damn module, it's no longer the one created by the initial author.

++++++++++

Quote:
8. Every module must be packed with ZIP or 7Z, no rars, no crappy UHA or else unknown archiving formats or paid such as RAR.


++++++

Quote:
11. When u release a news story about your work, provide accurate mirroring on SourceFore.NET or Google Code, they're not going down like your shared hosting somewhere in Argentina or Mexico or Sudan. Add a link to support thread in forums on this site, ppl can't learn, speak and write in Every language on this planet, nor they to be forced to register everywhere to ask question or to submit bug report.


++++++++

As an comment:
I see a lot of -'blue move'- modules appearing. They are placed within SVN. Bugs and fixes which are applied are sometimes fixed, sometimes not. It is unclear. BUt the module stays within SVN as a rar file.
Look at mymenus. Within topic stated as final, but still some major bugs aren't solved. Why call it final if it is still beta, of RC. ?

As i already mentioned earlier, I am getting more and more confused which modules are blue move ready, bug fixed/debugged after release. I hate SVN. If ready (Final) take it out of the trunk (for off. download), put it on xoops.org within downloadsection Category: Blue Move
No I have to spit through topics and read pages of pages to find the proper/lates grmbl trunk-SVN rar version.

Quote:
Usually is like this, but here someone - just throw release after release without paying attention to discovered bugs or problems with they're work - wont mention nicknames anymore.

Totally agree. And every release gets the status Final. But no attention to given bugs (and sometimes suggested fixes).
And,...... keeping the same name of cloned modules, which results in even more confusion.

9
irmtfan
Re: Propose for Coding Standards and Rules (for last time)
  • 2012/8/11 2:25

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


Quote:

I see a lot of -'blue move'- modules appearing. They are placed within SVN. Bugs and fixes which are applied are sometimes fixed, sometimes not. It is unclear. BUt the module stays within SVN as a rar file.
Look at mymenus. Within topic stated as final, but still some major bugs aren't solved. Why call it final if it is still beta, of RC. ?


Yes i told it many times. The issue is they are not tested properly before goes to final version. Some modules just change to final after removing some typos from definitions.

Also this is the document that i worked on.
XOOPS localization-customization-translation Standard.doc

10
DCrussader
Re: Propose for Coding Standards and Rules (for last time)

Yay shine is back :)
With Cesag can make good Q&A Team and to throw back to beta half or 80% of all modules tagged as Final :)

Login

Username:
Password:

Lost Password? Register now!

Who's Online

67 user(s) are online (38 user(s) are browsing Support Forums)


Members: 0


Guests: 67


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Nov 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits