Category: News
zeroram recently suggested that we update our Sports Management modules 
So today we're making the first step: I've converted these three modules to XOOPS 2.5.5 Admin GUI, and tested under PHP 5.4.12.
The modules need more work in the sense that they are not using XOOPS API, and would have to be fully converted to "Blue Move", but for the time being it seems like they are doing the job.
But since you can now install and test them on XOOPS 2.5.5 and PHP 5.3/5.4, I hope that we'll have users who will want to work together on improving these modules, and converting them to XOOPS API.
So let me know if there is any interest in improving these modules any further.
Download:
CricketStats 1.20 Beta 1
MatchDart 1.60 Beta 1
TPL League Stats 1.10 Beta 2
Also, we've updated recently the Team module, for playing games on line, so you can test it as well:
- Team 3.02 Beta 1
Follow-up and discussion: in this thread
Our friend from XOOPS France have recently updated a Website focusing on Mountain Biking:![]()
http://www.passionvtt.org/
This is an RC release, please do not use it on a production site!
Mylinks is a XOOPS module that allows an administrator to create a series of website links. The module provides the ability for other users to submit sites for inclusion in the list which can be monitored by the administrator and then approved if desired.
Features:
- Category support to put links into a logical order
- Uses XOOPS search to search the title and description
- Can screen shots stored locally or automatically create them using a 3rd party service
- Create QrCodes for links (requires QrCode module)
- Create link PDF
- Print link Information
- Tell-A-Friend feature to email information about a link to someone else (uses XOOPS Captcha)
- Users can rate links
- Links can be bookmarked using various 3rd party services
- RSS / ATOM feeds
- Flexible display of page headers, menus, etc
- XOOPS blocks - Display random link, most recent links, Display most popular links
- Supports usage of XOOPS Comment and Notification systems
- User can report broken links
- User can submit link for inclusion in the list
Code changes since v3.11 RC:
Added:
- added templates to xoopsversion for rss, atom and pda templates
- added missing files for template administration
Corrected:
- addSlashes issue for a link's description and title
- link count per category calculation routine
- frontside admin link to modify a link (from ./admin/index.php to .admin/main.php)
- do not allow voting on inactive links
- approve/edit/ignore action buttons on listModReq form(s) in Admin panel
- form title on Modified Links page in Admin panel
- missing '< / div >' in ./templates/mylinks_link.html
- incorrect url to view category in Random Link block
- incorrect category displayed when listing Modified Links in Admin panel
Removed:
- admin templates from xoopsversion. They did not exist and were not being used
- "Make this my Homepage" link, security risk and was only supported in IE
Improved:
- html template(s)
- html rendering by moving hard coded English strings to language file(s)
- security in forms - many forms now use XoopsSecurity tokens
Changed:
- Tell-A-Friend to use server mailer form instead of user's email client
- ereg_replace to str_replace in bookmark_qrcode_encoding() function
- revision to RC2
System Requirements:
- PHP 5.2.0
- MySQL 5.0.7
- XOOPS 2.5.0
- Modulesadmin Class 1.1
Special appreciation to Cifug for his assistance in testing and invaluable suggestions for this release. Without his help the time it would have taken to get this release ready would have been increased significantly.
Important Notices:
Please read the INSTALL.TXT file for installation and configuration information. Mylinks 3.11 will be the last release supporting folder relocation.
Backup your existing site before installing/upgrading any new XOOPS module.
Download: XOOPS Mylinks 3.11 RC2
Bugs/Feedback: Please post in this thread on our Forums
It's time to finalize our Module Packs.
Below is the preliminary list of modules, and they place in the proposed Module Packs:
- Basic
- Community
- Company
- eCommerce
- Mega
The requirements for all these modules are as follow:
- XOOPS 2.5.5 Admin GUI
- active development/maintenance
- tested and working on XOOPS 2.5.5 and under PHP 5.4
In Green, modules that are tested and released.
In Yellow, modules that are still being worked on, and if they're finalized on time, they will be included.
I am sure, that we've missed some modules, or some modules might be duplicate, and should be removed. Some modules might be not in all appropriate Packs.
If you don't know some of these modules, you can find descriptions for most of them in this article, or in the "XOOPS Resource Book"
Please let us know what you think in this thread. 
As you might already know, there is an effort to standardize our module development - from using the same module Admin GUI structure, to using the same icons across all modules, from using the same pagination structure for each table, to naming the tables and fields in a consistent way (see this thread).
This tutorial will show you how to modify your module so it can rename the tables on the user site, when the user updates the module. This will follow the scheme suggested by alain01
The new table naming scheme is:
mod_AAA_BBBB
where AAA is the name of the module, and BBB is the name of the table.
For example, when we have in the News module a table called "topics", in the new updated version of News, it will become:
mod_news_topics
Here are few steps to follow, as used recently in the Pedigree module called "animal":
1) The new version should have the tables defined properly in the SQL file, so new installation have the right tables installed right away
2) In the existing installation the users normally copy files over, and then run "update" in the Admin. Therefore we'll need to add a file with the updates. We'll call it "update_function.php" and will place it in /include folder
3) In order for XOOPS to call this file, we'll add in xoops_version.php file following:
$modversion['onUpdate'] = 'include/update_function.php';
4) In that file, we start by adding a function to check if the table that we want to rename, does actually exist. This is done by using a function created by Hervet:
function tableExists($tablename)
{
global $xoopsDB;
$result=$xoopsDB->queryF("SHOW TABLES LIKE '$tablename'");
return($xoopsDB->getRowsNum($result) > 0);
}
5) then we add a following function that will be executed when we click on the Update button:
function xoops_module_update_animal()
{
global $xoopsDB;
if (tableExists($xoopsDB->prefix('eigenaar'))) {
$sql = sprintf(
'ALTER TABLE ' . $xoopsDB->prefix('eigenaar') . ' RENAME ' . $xoopsDB->prefix('mod_pedigree_owner')
);
$result = $xoopsDB->queryF($sql);
if (!$result) {
echo '<br />' . _AM_PED_UPGRADEFAILED . ' ' . _AM_PED_UPGRADEFAILED2;
$errors++;
}
}
return TRUE;
}
In this code above, we are checking if the "eigenaar" does exist, and if it does, then we're renaming it to "mod_pedigree_owner'". Of course, this is done for each table that we want to rename.
6) We also have to rename all occurrences of the tables in the code as well.
a) as a first step, it's easy to just run search & replace using as part of the search the word "prefiix", so in our example, we'll replace:
prefix("eigenaar")
with:
prefix("mod_pedigree_owner")
This is for cases where we call the tables in a conventional way.
b) But people are creative, and it might happen that they do it differently, so nothing will save us from testing, and eventually searching for the word "eigenaar" in all files, and then making a judgment call if it is meant as a table and therefore has to be renamed.
The new naming scheme will make it easier two things:
- to see in phpMyAdmin (or any other database tool) all the tables from a module grouped together. It will also distinguish them from the Core tables.
- in the code it will also make it easy to find the tables just by searching "mod_MODULENAME"
In the near future, we'll also consolidate names and characteristics of the typical fields in our modules, and provide them as guidelines.
When you look at our modules, the same field could be named differently in each module. Let's take "Group ID" - it could be: gid, g_id, group_id, gr_id, etc. And if you are trying to maintain a module from somebody else, we are wasting too much time trying to figure out what a particular field is actually for.
If you have improvements for this tutorial, please let us know.
And most importantly:
- If you can help us to streamline and standardize module development, we would very much appreciate it.
- If you like how a particular module does something and think that other modules should do the same, let us know.
- If you see something cool being done by other Open Source Projects that XOOPS could benefit from, please let us know too.
Please follow up in this thread


