Elxis CMS Forum

Extensions => Components => Topic started by: Reza Faghihi on March 30, 2007, 13:45:51

Title: porting project
Post by: Reza Faghihi on March 30, 2007, 13:45:51
hi guys i started to port some components to elxis here is the first one
YANC (yet another newsletter component)
there is some changes first of all implementing elxis access level  now Yanc works with elxis access level
2- add some javascript in admin.yanc.html.php to validate the form
3- change the default access list in the admin.yanc.php to apply the acces level correctly
4- modify the subscription module to use the elxis access level its a little bit complicated cause in elxis publicfront end and backend group id is 29 and 30 and i think there should be some changes in group id in next release of elxis
i used $my->gid and if you use this you cant just use <= or => cause there is no order also you can use $my->Allowed and it works but i dont know the reason why that 2 groups id is 29 ,30 ???
download attachment and report bugs please
also about update issue in Yanc i changed mosReadDirectory to $fmanager but and it worked but i changed the server name cause the version update check it against the joomla-addons site and the version we use is different so please maybe i added updated files on parsref.com later for updating

[old attachment deleted by admin]
Title: Re: porting project
Post by: Reza Faghihi on March 30, 2007, 13:48:09
http://www.gnuteams.com/elxis/com_yanc_1.5_beta2-4elxis.zip
this the link for component the file size is bigger than allowed size to attach on the post
Title: Re: porting project
Post by: datahell on March 30, 2007, 18:34:00
Group 29 belongs to a different access tree branch than the group 30. There are not the same!


ROOT
|
USERS
|_PublicFrontend
|     |.... groups with access to frontend
|
|
|_Public Backend
      |... groups with access to backend
Title: Re: porting project
Post by: Reza Faghihi on April 03, 2007, 12:47:36
does any one test this component with elxis? i want to know if there is the problem or not and if it works fine maybe its not bad to add it on the elxis directory
Title: Re: porting project
Post by: datahell on April 03, 2007, 17:40:32
I will do a fast check now and I will reply you in a few minutes. Notice: Elxis 2007 has included newsletter capabilites...
Title: Re: porting project
Post by: datahell on April 03, 2007, 18:22:35
I did a fast check on the most crucial files without installing the component.  It is not recommended by me to use it with Elxis. Use it with your own risk.

Problems I found:
- Many database querries are not ADODB safe. Most probably this wont cause many problems if Elxis runs under MySQL database.

- Access and user groups. Component lists groups without checking who is calling the script. Elxis uses for the access control lists a special function named "Access" which filters out groups that you have no access to see/manage. (ie it does not allows Publishers to manage super administrators). If you want to get the users access list just use:

$lists['access'] = mosAdminMenus::Access( $row );

A relative error. This is dangerous for Elxis:

WHERE access <= ' . $my->gid . '

- UTF-8. Many utf-8 incompatibilities. For example the extended usage of the str_replace function. Use eUTF::utf8_str_replace instead (ie in mailing.php).

- Security. Update procedure requires opening of remote files which is very insecure function and is disabled in most (serious) hosts. Elxis has a build-in solution for this. Use snoopy. (file update.php)

- Fatal errors:
Column fulltext does not exist in Elxis. This column has been renamed to maintext. (file mambots/core.php)

- XML. Yanc xml file does not contain Elxis version. Also querries contain not acceptable value for the default dates (0000-00-00 00:00:00). Elxis "likes" the usage of XML schema files for the installation procedure.

- File management. Except from a short part everything regarding to files is done using the native php function which is bad because it misses Elxis build-in function and FTP support. Use fmanager instead. A relative issue: In update.php it uses native ftp function where there is no need as fmanger has build-in FTP support.

Examples:
instead of unlink(), use $fmanager->deleteFile()

instead of fopen... fwrite()... fclose, use $fmanager->writeFile($file, $data)

- Language. It is not multilingual. It only accepts the site's default language. Also misses any language filtering by the querries.

I also did nt found any access check.

Besides all the above it is a well written component.