Meta Extension (does it make sense?)

michaelontheroof

I finally got 0.9.3 running an now created the Meta Extension I was thinking about disucssing the User Export extension. The Meta Extension is available in the Add Ons Directroy. It handles Extension Settings which are written to an extra table in the database and makes it easy to have Install and Uninstall Routines when an extension is enabled or disabled.

1) I like the idea of having (Un)Installation routines when extensions are dis/enabled. With the Meta Extension you just need to place a function called YourExtensionDirectoryName_Install() in your extension file to make it possible. If your extension requires a new db table or extra field you may check if table allready exists or create it there.
2) I think it's best to have one place to store all settings from different extensions cause it keeps administration and maintenance simple. Therefore the Meta Extension creates an simple Property-Value table and provides Get, Set and Remove functions.
3) Thinking forward a unique directory (with subfolders) for files would be great, too. Admins only have to set write permissions once.

I'm intresting in your opinon, if such an extensions makes life easier or even more complicated.

NickE

Sounds good to me. Although will you also be providing an Edit routine for extensions to edit settings?

ithcy

it will make life easier if it becomes a standard. otherwise it will make things more complicated, because you'll have to deal with both the extensions that use this method and the extensions that don't.

Mark

I was thinking about install procedures last night, and I had this idea:

When you install an extension that requires extra database tables or columns, there should be a configuration parameter for that extension that is '0' by default. The extension, even if enabled, will never work unless that setting is changed to '1'. So, the extension file itself would go something like this:

if ($Configuration['MY_EXTENSION_NAME_INSTALLED'] == '0') { // Only attempt to install the extension if you are on the settings tab and there is a related PostBackAction. // You do this because if there are errors installing the extensions extra db structure, you don't want it // to completely kill the site or management thereof. $PostBackAction = ForceIncomingString('PostBackAction', ''); if ($Context->SelfUrl == 'settings.php' && $PostBackAction == 'SetUpMyExtensionName') { // Execute any sql necessary to install the database structure required for the extension. // I'd make sure to check to see that the structure doesn't already exist before brute forcing the changes. // ... // Now set the configuration option to 1 and save it in the conf/settings.php file. } } else { // Standard extension code goes here and the extension is used. }

Finally, I'd either like to allow html in the description and allow the extension description to contain a link to the correct postbackaction, or just explain what the postbackaction should be in the description or readme that accompanies the extension.

Thoughts?

Bergamot

When an extension is loaded, can't it check for itself whether the relevant tables/columns exist, and create them if they don't? It's not really a complicated query.

As far as the other part goes, I'm not convinced that the extra tables/columns should be removed when an extension is disabled. They don't really hurt anything, and could contain useful data that I want to keep.

michaelontheroof

// Now set the configuration option to 1 and save it in the conf/settings.php file.
Is it eays to set the configuration option automatically or has it to be done by hand?
I like the idea of an installation routine, cause I want extensions to work for administrators without doing changes in files or database directly.

What about including the extensions default.php checking if an installation function exists and then calling the function after the extension has been enabled? Mhh: On errors and warnings this would cause some problems with the Ajax switch option..

@Bergamont: Yes, it's eays to check if a table exists or not. But its one more database operation each time the extension is loaded. Querying this only when the extension is enabled or (when $Configuration['MY_EXTENSION_NAME_INSTALLED'] == 0 in Marks idea) seems to be more elegant for me. As you I don't think, that columns/tables should be removed, when disabling an extension. I doesn't hurt.

Mark

When an extension is loaded, can't it check for itself whether the relevant tables/columns exist

You really want this extra query on every single page-load, forever and ever amen? That's a huge waste of resources.

Is it eays to set the configuration option automatically or has it to be done by hand?

There is a configuration manager that allows you to do it pretty easily. I can document it easily enough, too.

Minisweeper

i've a feeling (or hope, atleast, or he's a bit silly) that when bergamot refers to loaded he means loaded into the system i.e. enabled. I could be wrong, though.

michaelontheroof

I'll check out the ConfigurationManager. You don't need to document.
And I would like to have html allowed in the description to link to a postback action.

For now I'm still a bit confused:
When is the ['MY_EXTENSION_NAME_INSTALLED'] in the configuration first set for new extensions? Or should we just check it this way?
if (!in_array('MY_EXTENSION_NAME_INSTALLED', $Configuration)) { //Installation //Set 'MY_EXTENSION_NAME_INSTALLED' via configuration manager } else { //extension }

When your idea works in the new version, I'll remove the installation support hack from the Met a Extension. ithcy is right: if its not a standard it is confusing.

Mark

You're right michael... That's a solid plan.

ithcy

*extends meat

oops... misread thread title

Minisweeper

You know, that comment and your 'that Wink looks pretty cool' comment could both be taken really the wrong way...

Bergamot

Mini! Mind out of the gutter!

Minisweeper

Dude its nearly midnight i'm meant to be thinking like that.
Plus i'm a dirty sex deprived teenager.

michaelontheroof

That's what I did for the PredefinedAttributes Extension which get their own column in the user table in next version:

/* =Installation Check
--------- --------- --------- --------- --------- --------- --------- */
if(!array_key_exists('PredefinedAttributes_INSTALLED', $Context->Configuration)) {
	if ($Context->SelfUrl == 'settings.php' && $PostBackAction == 'InstallPredefinedAttributes') {
		$pa = new PredefinedAttributes($Context);
		$pa->Install();
	}
} else {
/* =Delegates to follow

And the Install() function in the PredefinedAttributes Class:

/*////////////////////////////////
//  @name:  		Install
//  @description:   Adds a new Column to the User Table to save Predefined Attributes
*/
function Install() {
	$sql = "SHOW COLUMNS FROM ".$this->Context->DatabaseTables['User']." LIKE '".$this->ColumnName."'";
	$DataSet = $this->Context->Database->Execute($sql, $this->Name, "Install", "An error occurred while checking if column ".$this->ColumnName." exits in ".$this->Context->DatabaseColumns['User']);
	if($DataSet) {
		$Data = mysql_fetch_row($DataSet);		
		if ($Data[0] != $this->ColumnName) { //check if table allready exists
			$sql = "ALTER TABLE ".$this->Context->DatabaseTables['User']."
							ADD ".$this->ColumnName." TEXT NULL
							COMMENT 'Created by Predefined Attributes Extension'
							AFTER Attributes;";
			$this->Context->Database->Execute($sql, $this->Name, "Install", "An error occurred while creating a column");
		}
		$cm = $this->Context->ObjectFactory->NewContextObject($this->Context, 'ConfigurationManager');
		$cm->DefineSetting('PredefinedAttributes_INSTALLED', 1);
		$cm->Settings['PredefinedAttributes_INSTALLED'] = 0;
		$SettingsFile = $this->Context->Configuration['APPLICATION_PATH'].'conf/settings.php';
		$cm->SaveSettingsToFile($SettingsFile);

	}
}

Is that the way to go?

folletto

Pardon if I up this topic, but since I was starting something really similar, I wanted to check out before the actual "state of art"

I'm developing an "easy" way to plug Settings Panels into... well... the Settings page.

I'm quite there, the next *must* step is something like the Meta Extension.


I'm building every component in my extension (FeedReader), where possible and with time constraint, as a class.

So I've got a class to fetch the feed (Snoopy, not mine), a class to cache it (RSSCache, not mine), a class to parse it (XMLPlainParser for PHP4/5, mine) and I was doing the class above (VanillaEasySettingsPanel, mine).

So, I was now doing searches to allow virtually any extension to add some configuration data to Vanilla. I noticed that a table like that doesn't exists, so I found this extension.

The problem is: this is an extension. It's an usability problem if anyone that wanted to use my extension should also use this Meta one. I'd like to *port* this one (or make something similar) in order to have a class, simple, to be included in my estension (and in any extension).

I think that the 'burden' of a few kbytes for each extension is payed back from the removal of an "extensions requirement".

What do you think about it?

The original developer for this class is still on it?

michaelontheroof

Hi folletto,

interesting thoughts.
I'm not working on this extension anymore, cause as not being a standard it makes things more complicated as itchy points out.
Please read the comments by Mark (developer of vanilla) carefully.
Especially the way of setting the ExtensionName_INSTALLED variable to the configuration file.

So I think the best thing is to put the class (or a ported version) in your extension and handle the installation stuff by your own (as in the PredefinedAttributes example code above).

Hope this works for you.

folletto

Thank you for the avail to proceed using your code as the base for the new standalone class.

I'll work on it asap... I'll post some news here when I've got something working.

Pol

Should the current version of the Meta Extension still work with Vanilla 1.0.1? I installed it in the usual way, but it doesn't show up in the extension installer list.