When is a module NOT a module.

[El Patron]

It's not a module people if it can't do any of the following 4 things.

 

1. you have to ftp up the 'module' folder

2. you have to ftp up files in different folders

3. when you disable...it doesn't do anything

4. when you uninstall...it doesn't do anything

5. luckily none can 'not' program for delete

 

modules MUST me click click done...or they are not modules.

 

In the last month I've purchased two modules, both more than $100.00...both from what I thought were reputable developers....it's not the money...it was just a huge waste of my time..they were not modules...

Edited May 28, 2012 by elpatron (see edit history)

[codegrunt]

I'd agree with modules uninstalling and / or disabling properly but keep in mind that Prestashop has changed their module approach over time so depending on when the module was written, the auto-extract function may not have been available then (or documented). Personally I do not like the auto-install function at all as there any number of issues that can go wrong with that type of approach (stict server permissions, lower script execution time, etc.). File permissions also may be left too lax afterwards for some situations when the web daemon does the install versus uploading the files via FTP and setting the permissions explicitly.

 

Keep in mind that files may need to go in multiple directories due to the nature of Prestashop itself. For example, there are cases where for admin modules (at least last time I looked) the *only* way to do it was to copy files to the admin folder due to way security works (token issues related to the unique admin path). Likewise, class overrides always need to be outside of the module directory.

 

This does not exclude poor quality paid modules of course but demanding everything is one click and in a single directory is not reasonable unless the module is fairly simple.

 

Cheers

Edited May 28, 2012 by codegrunt (see edit history)

[El Patron]

Codegrunt, thanks for the interesting reply.

 

In my honest opinion...a lot of the fault is due to the PrestaShop module 'how to' that doesn't cover how to write the install routine, for example the base module demo does not even mention coding enable/disable/un-install. That is our fault (mine included) for not helping to add to module documentation. But I am a newbie addict.

 

Ok, here is where I am going to fire some shots, there is NO excuse for not being able to provide the proper framework to customers, when ones states it's for a particular or wide ranging ps release, and one is not going to provide the necessary module framework, then it's not a module. It's a hack.

 

Here is the code on how one can load an new admin tab, and keep it's class in the module folder. i.e create an admin tab, the class and actual tab.php resides in your module folder and does not need to be copied into the ps class folder or admin tabs.

 

private function adminInstall()
{	
	if (!$idTab = Tab::getIdFromClassName('YourAdminClassName')) {
		$tab = new Tab();
		$tab->class_name = 'YourAdminClassName';
		$tab->module = 'yourmodulenamelowecase';
		$tab->id_parent = 9;  
// note previous hard code as problem experienced obtaining parent tab id by name.
		$languages = Language::getLanguages(false);
		foreach ($languages as $lang)
			$tab->name[$lang['id_lang']] = 'YourNewTabName';
		$res &= $tab->save();
		$tab->name[(int)(Configuration::get('PS_LANG_DEFAULT'))] = $this->l('YourAdminClassName');
	}
	return TRUE;

	to deltete the tab added to admin, you simply use:

	$tab = new Tab(Tab::getIdFromClassName('YourAdminClassName'));
	if (!$tab->delete())

Edited May 28, 2012 by elpatron (see edit history)