Are there any talks of implementing an extension manager and a proper extension repository? Something that will allow new versions to be detected, downloaded, UPGRADE files to be displayed, etc all from one location? Something that could also allow enabling, disabling, installing, and uninstalling extensions?
I would be willing to work on one if there is a demand.
Kasimir
On 08/06/07, Kasimir Gabert kasimir.g@gmail.com wrote:
Are there any talks of implementing an extension manager and a proper extension repository? Something that will allow new versions to be detected, downloaded, UPGRADE files to be displayed, etc all from one location? Something that could also allow enabling, disabling, installing, and uninstalling extensions?
The software would be quite straightforward, the issue here is maintaining a repository; there is a lot of sloppy extension code out there, some of it outright insecure, and we don't really want the hassle of keeping track of it all and checking it's all sane.
Rob Church
Hm...
I am thinking something along the lines of Debian's system. We would have main, which would be approved by WikiMedia, and then contrib, which would be approved by the community (say at least two people have to say "It looks good"), and then non-free where anything goes.
The names could all be changed of course... "Core", "Trusted", "Universe" or something.
Kasimir
On 6/8/07, Rob Church robchur@gmail.com wrote:
On 08/06/07, Kasimir Gabert kasimir.g@gmail.com wrote:
Are there any talks of implementing an extension manager and a proper extension repository? Something that will allow new versions to be detected, downloaded, UPGRADE files to be displayed, etc all from one location? Something that could also allow enabling, disabling, installing, and uninstalling extensions?
The software would be quite straightforward, the issue here is maintaining a repository; there is a lot of sloppy extension code out there, some of it outright insecure, and we don't really want the hassle of keeping track of it all and checking it's all sane.
Rob Church
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On 08/06/07, Kasimir Gabert kasimir.g@gmail.com wrote:
I am thinking something along the lines of Debian's system. We would have main, which would be approved by WikiMedia, and then contrib, which would be approved by the community (say at least two people have to say "It looks good"), and then non-free where anything goes.
Yes, that could work.
Rob Church
I like the idea of an automatic update function!
The software would be quite straightforward, the issue here is maintaining a repository; there is a lot of sloppy extension code out there, some of it outright insecure, and we don't really want the hassle of keeping track of it all and checking it's all sane.
The whole thing could be handled like Mozilla handles extensions; no central code repository, and the user (administrator) would have to confirm each update.
The problem with this, of course, is that every extension would have to provide sort of a CurrentVersion feed. However, most still-maintained extensions would probably quickly provide that once this auto-updater has been established.
-- F.
On Thu, 07 Jun 2007 21:49:26 -0600, Kasimir Gabert wrote:
Are there any talks of implementing an extension manager and a proper extension repository? Something that will allow new versions to be detected, downloaded, UPGRADE files to be displayed, etc all from one location? Something that could also allow enabling, disabling, installing, and uninstalling extensions?
I would be willing to work on one if there is a demand.
Kasimir
It does sound like an interesting idea.
There is an experimental script in the maintenance directory to help download an install extensions.
I'm not sure how well upgrading would work in some cases, since the extension interfaces tend to evolve. I'd be cautious about running new extensions on an old wiki.
But maybe if the install.settings specified which versions the extension would work on, so you could at least getting a warning when trying to install something that's known not to work; maybe even "This will work here, but you'd also get feature X if you upgraded to MediaWiki Y". But an easier way to correlate extension upgrades with the base upgrade would be nice.
I think it'd be useful to bundle a set of known stable extensions (i.e. the ones installed on Wikimedia projects) with the release.
If I understand what you're aiming at here, gallery2 (gallery.menalto.com) does this very thing. I now wish every other open source app I use (MediaWiki, Drupal, WordPress (and WPMU)) offered this capability. But I'm speaking as a code/CSS/PHP rock. Thus, all I can do is cheer, hope and wait.
Hm.... so I am picturing something similar to the following:
HTTP or FTP get requests possible to the server. Structure of files on the server: Top level folders: core trusted universe
In each folder, it is split up into each letter of the alphabet. For example, core/a/anextensionfolder core/a/apples etc.
The extension folder would be downloaded to $IP/extensions/.
And the appropriate UPGRADE or INSTALL file in the directory would be shown.
Then it would search for LocalSettings.php.include file (or something similar), and automatically add its content to LocalSettings.php.
If that file does not exist, then it would add require_once("$IP/extensions/extensionfolder/ExtensionName.php"); to LocalSettings.php.
I could even see it proping for the fields in LocalSettings.php as defined by LocalSettings.php.include, so the user could install it without ever touching the terminal or LocalSettings.php.
Let me know what everyone's opinions are.
Kasimir
On 6/8/07, John Lyon jelyon@jelyon.com wrote:
If I understand what you're aiming at here, gallery2 (gallery.menalto.com) does this very thing. I now wish every other open source app I use (MediaWiki, Drupal, WordPress (and WPMU)) offered this capability. But I'm speaking as a code/CSS/PHP rock. Thus, all I can do is cheer, hope and wait.
-- John Lyon | Austin TX
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Adding and removing things from LocalSettings.php might be troublesome.
Things like svn and cvs, as well as a number of other programs use hidden or dot files. Why not treat every folder with a ".extension" file inside of it as a extension which can be managed with the extension manager. And use a Special:Extensions to disable and enable them.
That Special:Extensions as you said can also do the HTTP or FTP request to download the extension data and by default a extension will be set to enabled if you use the SpecialPage, and will default to disabled if you manually drop the folder into the extensions folder.
This lets us do it without the potential of breaking the LocalSettings.php.
As for LocalSettings.php we could also use a $wgUseExtensionManager to let people disable it if they don't want it, that could also be added to the normal installation(config/index.php) script.
As for what else we could do with dot files we could use .extension to also allow for configuration of various variables through Special:Extensions. ".extension" could also have data such as the title of the extension that would be displayed in Special:Extensions.
Or perhaps we could use a dot folder. extensions/extensionid/.ext/ And inside we'd have various things like .extension which would have the basic data like links to update urls similar to the update url used in Firefox's extension management. We could use a .vars to list special variables for the extension itself and other things about the variable such as what type (bool, int, string, array) and even something like a regex match or enum list of valid values that could be put into the strings or other types of variables. Special:Extensions would use that .vars file to create a form for picking out the values that a user can select to customize the extension. Then a AutoConfig.php could be created by Special:Extensions when it's used to change the configuration. A simple ".enabled" would define what extensions are turned on or off.
As for how to include these extensions without using LocalSettings.php we'd need a includes/SpecialExtensions.php anyways, create something for managing this in includes/Extensions.php. Using that it will search the extensions folder for folders, and for each one it'll consider each one with a .ext folder inside of it an extension and list it on Special:Extensions. And it checks for .enabled and checks it if it's set to enabled or true. If it's not, or it has not been created then it's considered disabled and Special:Extensions can be used to create it.
Checking a list of folders and files in a directory isn't hard, I've used it plenty of times. And since we already need to let php modify the extensions directory to install extensions from the remote sources there's no issue of debating the fact that php will need to write the .enabled and AutoConfig.php files to be used.
~Daniel Friesen of The Gaiapedia and Wikia Graphical Entertainment Project
Kasimir Gabert wrote:
Hm.... so I am picturing something similar to the following:
HTTP or FTP get requests possible to the server. Structure of files on the server: Top level folders: core trusted universe
In each folder, it is split up into each letter of the alphabet. For example, core/a/anextensionfolder core/a/apples etc.
The extension folder would be downloaded to $IP/extensions/.
And the appropriate UPGRADE or INSTALL file in the directory would be shown.
Then it would search for LocalSettings.php.include file (or something similar), and automatically add its content to LocalSettings.php.
If that file does not exist, then it would add require_once("$IP/extensions/extensionfolder/ExtensionName.php"); to LocalSettings.php.
I could even see it proping for the fields in LocalSettings.php as defined by LocalSettings.php.include, so the user could install it without ever touching the terminal or LocalSettings.php.
Let me know what everyone's opinions are.
Kasimir
On 6/8/07, John Lyon jelyon@jelyon.com wrote:
If I understand what you're aiming at here, gallery2 (gallery.menalto.com) does this very thing. I now wish every other open source app I use (MediaWiki, Drupal, WordPress (and WPMU)) offered this capability. But I'm speaking as a code/CSS/PHP rock. Thus, all I can do is cheer, hope and wait.
-- John Lyon | Austin TX
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
I thought this was a proposal for Google SoC '07 but all I can find on the page now is this: http://meta.wikimedia.org/wiki/Summer_of_Code_2007#Site_administration - sort-of similar.
I don't know personally much about the technical implementation of such a system, but I do know it would help me and many others a hell of a lot - my two pence ;)
And Peter - please stop. Just stop.
On 09/06/07, Dantman dan_the_man@telus.net wrote:
Adding and removing things from LocalSettings.php might be troublesome.
Things like svn and cvs, as well as a number of other programs use hidden or dot files. Why not treat every folder with a ".extension" file inside of it as a extension which can be managed with the extension manager. And use a Special:Extensions to disable and enable them.
That Special:Extensions as you said can also do the HTTP or FTP request to download the extension data and by default a extension will be set to enabled if you use the SpecialPage, and will default to disabled if you manually drop the folder into the extensions folder.
This lets us do it without the potential of breaking the LocalSettings.php .
As for LocalSettings.php we could also use a $wgUseExtensionManager to let people disable it if they don't want it, that could also be added to the normal installation(config/index.php) script.
As for what else we could do with dot files we could use .extension to also allow for configuration of various variables through Special:Extensions. ".extension" could also have data such as the title of the extension that would be displayed in Special:Extensions.
Or perhaps we could use a dot folder. extensions/extensionid/.ext/ And inside we'd have various things like .extension which would have the basic data like links to update urls similar to the update url used in Firefox's extension management. We could use a .vars to list special variables for the extension itself and other things about the variable such as what type (bool, int, string, array) and even something like a regex match or enum list of valid values that could be put into the strings or other types of variables. Special:Extensions would use that .vars file to create a form for picking out the values that a user can select to customize the extension. Then a AutoConfig.php could be created by Special:Extensions when it's used to change the configuration. A simple ".enabled" would define what extensions are turned on or off.
As for how to include these extensions without using LocalSettings.php we'd need a includes/SpecialExtensions.php anyways, create something for managing this in includes/Extensions.php. Using that it will search the extensions folder for folders, and for each one it'll consider each one with a .ext folder inside of it an extension and list it on Special:Extensions. And it checks for .enabled and checks it if it's set to enabled or true. If it's not, or it has not been created then it's considered disabled and Special:Extensions can be used to create it.
Checking a list of folders and files in a directory isn't hard, I've used it plenty of times. And since we already need to let php modify the extensions directory to install extensions from the remote sources there's no issue of debating the fact that php will need to write the .enabled and AutoConfig.php files to be used.
~Daniel Friesen of The Gaiapedia and Wikia Graphical Entertainment Project
Kasimir Gabert wrote:
Hm.... so I am picturing something similar to the following:
HTTP or FTP get requests possible to the server. Structure of files on the server: Top level folders: core trusted universe
In each folder, it is split up into each letter of the alphabet. For
example,
core/a/anextensionfolder core/a/apples etc.
The extension folder would be downloaded to $IP/extensions/.
And the appropriate UPGRADE or INSTALL file in the directory would be
shown.
Then it would search for LocalSettings.php.include file (or something similar), and automatically add its content to LocalSettings.php.
If that file does not exist, then it would add require_once("$IP/extensions/extensionfolder/ExtensionName.php"); to LocalSettings.php.
I could even see it proping for the fields in LocalSettings.php as defined by LocalSettings.php.include, so the user could install it without ever touching the terminal or LocalSettings.php.
Let me know what everyone's opinions are.
Kasimir
On 6/8/07, John Lyon jelyon@jelyon.com wrote:
If I understand what you're aiming at here, gallery2 (
gallery.menalto.com)
does this very thing. I now wish every other open source app I use (MediaWiki, Drupal, WordPress (and WPMU)) offered this capability. But
I'm
speaking as a code/CSS/PHP rock. Thus, all I can do is cheer, hope and
wait.
-- John Lyon | Austin TX
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
-- ~Daniel Friesen of The Gaiapedia and Wikia Graphical Entertainment Project
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On Fri, 08 Jun 2007 19:42:49 -0600, Kasimir Gabert wrote:
Hm.... so I am picturing something similar to the following:
HTTP or FTP get requests possible to the server. Structure of files on the server: Top level folders: core trusted universe
I think there is some kind of classification, as to which extensions are installed on the official projects, which are in SVN, and which are third-party extensions with links from mediawiki.org. But splitting the structure this way seems counter productive, since it could take some effort to upgrade an extension if it becomes more trusted, and thus needs to be reloaded.
In each folder, it is split up into each letter of the alphabet. For example, core/a/anextensionfolder core/a/apples etc.
It seems unlikely that anyone would have that many extensions installed. Using the same structure as the SVN should be sufficient.
The extension folder would be downloaded to $IP/extensions/.
And the appropriate UPGRADE or INSTALL file in the directory would be shown.
Then it would search for LocalSettings.php.include file (or something similar), and automatically add its content to LocalSettings.php.
If that file does not exist, then it would add require_once("$IP/extensions/extensionfolder/ExtensionName.php"); to LocalSettings.php.
I could even see it proping for the fields in LocalSettings.php as defined by LocalSettings.php.include, so the user could install it without ever touching the terminal or LocalSettings.php.
Currently, the extensions that use this mechanism have a file called "install.settings" which is added to LocalSettings.php after some simple string substitution.
I think it would be useful to extend this or include a similar file describing configuration options, so Special:Extensions could display it as a web form.
Sorry, I did not make myself clear enough on how each folder would be organized. They would be split up like: core/a/anextension/ On the server, but they would be downloaded to extensions/anextension/
The reason for having the different categories is so that users will know whether it takes extra hacking to get them to work or not. Items in the core category will work by just clicking install. These are the items that are installed on WikiMedia's servers, and are known to work with the latest version. Items in the trusted category should work by just clicking install, but might not work with the latest version of MediaWiki. The universe items will probably be incredibly small, and just contain the extensions that users have not updated since they were created, and therefore do not state "This extension is trusted".
Kasimir
On 6/12/07, Steve Sanbeg ssanbeg@ask.com wrote:
On Fri, 08 Jun 2007 19:42:49 -0600, Kasimir Gabert wrote:
Hm.... so I am picturing something similar to the following:
HTTP or FTP get requests possible to the server. Structure of files on the server: Top level folders: core trusted universe
I think there is some kind of classification, as to which extensions are installed on the official projects, which are in SVN, and which are third-party extensions with links from mediawiki.org. But splitting the structure this way seems counter productive, since it could take some effort to upgrade an extension if it becomes more trusted, and thus needs to be reloaded.
In each folder, it is split up into each letter of the alphabet. For example, core/a/anextensionfolder core/a/apples etc.
It seems unlikely that anyone would have that many extensions installed. Using the same structure as the SVN should be sufficient.
The extension folder would be downloaded to $IP/extensions/.
And the appropriate UPGRADE or INSTALL file in the directory would be shown.
Then it would search for LocalSettings.php.include file (or something similar), and automatically add its content to LocalSettings.php.
If that file does not exist, then it would add require_once("$IP/extensions/extensionfolder/ExtensionName.php"); to LocalSettings.php.
I could even see it proping for the fields in LocalSettings.php as defined by LocalSettings.php.include, so the user could install it without ever touching the terminal or LocalSettings.php.
Currently, the extensions that use this mechanism have a file called "install.settings" which is added to LocalSettings.php after some simple string substitution.
I think it would be useful to extend this or include a similar file describing configuration options, so Special:Extensions could display it as a web form.
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
I've copied this same exact template from Wikipedia (along with connected templates), but its just giving a couple of TD and TH html tags: http://en.wikipedia.org/wiki/Template:Infobox_Biography
I'm sure this is just a configuration issue in the LocalSettings.php, in that the tags are not being parsed properly. Is it possible to see the relevant parts of the LocalSettings.php that Wikipedia is using?
Erik
--------------------------------- Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
On 09/06/07, Eric K ek79501@yahoo.com wrote:
I'm sure this is just a configuration issue in the LocalSettings.php, in that the tags are not being parsed properly. Is it possible to see the relevant parts of the LocalSettings.php that Wikipedia is using?
Wikimedia wikis use HTML Tidy to clean up any perversions in markup left behind by our users. Install it and enable it in LocalSettings.php.
Rob Church
It must be something else because another template also doesnt work and in that too: 1) I'm copy pasting the exact code from the template that is already working in Wikipedia 2) its not using any CSS as well.
I'm going to try step by step trouble shooting to see whats going on.
Rob Church robchur@gmail.com wrote: On 09/06/07, Eric K wrote:
I'm sure this is just a configuration issue in the LocalSettings.php, in that the tags are not being parsed properly. Is it possible to see the relevant parts of the LocalSettings.php that Wikipedia is using?
Wikimedia wikis use HTML Tidy to clean up any perversions in markup left behind by our users. Install it and enable it in LocalSettings.php.
Rob Church
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
--------------------------------- Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
Eric K wrote:
It must be something else because another template also doesnt work and in that too:
- I'm copy pasting the exact code from the template that is already working in Wikipedia
- its not using any CSS as well.
I'm going to try step by step trouble shooting to see whats going on.
As Rob Church told you, install tidy. When tidy is enabled MediaWiki leaves some conversion to tidy, which allows tags open on one template to be closed on another. If not using tidy, MediaWiki will close the tag at the end of the first template.
Ah I see, thanks. I thikn thats the problem, the tags are being closed. I'll try to install Tidy then.
In response to Gary, yes I do have Parserfunctions. I'll try to install Tidy and see if it fixes things, its probably just this then. thanks!
Erik
Platonides Platonides@gmail.com wrote: Eric K wrote:
It must be something else because another template also doesnt work and in that too:
- I'm copy pasting the exact code from the template that is already working in Wikipedia
- its not using any CSS as well.
I'm going to try step by step trouble shooting to see whats going on.
As Rob Church told you, install tidy. When tidy is enabled MediaWiki leaves some conversion to tidy, which allows tags open on one template to be closed on another. If not using tidy, MediaWiki will close the tag at the end of the first template.
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
--------------------------------- You snooze, you lose. Get messages ASAP with AutoCheck in the all-new Yahoo! Mail Beta.
Have you installed ParserFunctions?
http://meta.wikimedia.org/wiki/ParserFunctions#Installation
On 10/06/07, Eric K ek79501@yahoo.com wrote:
It must be something else because another template also doesnt work and in that too:
- I'm copy pasting the exact code from the template that is already
working in Wikipedia 2) its not using any CSS as well.
I'm going to try step by step trouble shooting to see whats going on.
Rob Church robchur@gmail.com wrote: On 09/06/07, Eric K wrote:
I'm sure this is just a configuration issue in the LocalSettings.php, in
that the tags are not being parsed properly. Is it possible to see the relevant parts of the LocalSettings.php that Wikipedia is using?
Wikimedia wikis use HTML Tidy to clean up any perversions in markup left behind by our users. Install it and enable it in LocalSettings.php.
Rob Church
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. _______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
I have an old website which was written in MS Frontpage, and I created the wiki inside the main directory, and made a link to it from the home page. Now that I have the wiki, the old site is pointless. How would I go about removing the old site and setting the wiki as the home page?
Thanks alot! Mike
--------------------------------- The fish are biting. Get more visitors on your site using Yahoo! Search Marketing.
Eric K wrote:
I'm sure this is just a configuration issue in the LocalSettings.php
Further to Rob's advice, make sure you've got all the CSS bits copied over as well. Look in the Infobox tamplate and its included templates and find all the "class=..." statements and see if those are in your main.css file. If not, go to Wikipedia's Common.css (or older Monobook.css) and find them there. Copy the relevant CSS to your Common.css (put any Monobook.css statements into your Common.css too - you shouldn't bother with Monobook.css).
Mike
Eric K wrote:
I've copied this same exact template from Wikipedia (along with connected templates), but its just giving a couple of TD and TH html tags: http://en.wikipedia.org/wiki/Template:Infobox_Biography
I'm sure this is just a configuration issue in the LocalSettings.php, in that the tags are not being parsed properly. Is it possible to see the relevant parts of the LocalSettings.php that Wikipedia is using?
Wikipedia's LocalSettings.php can be found at:
-- Tim Starling
Are there any talks of implementing an extension manager and a proper
extension repository?
Something that will allow new versions to be detected, downloaded, UPGRADE
files to be displayed,
etc all from one location? Something that could also allow enabling,
disabling, installing, >
and uninstalling extensions?
Maintaining an extension is, in and of itself, an on-going and time intensive activity, something which several extension developers may or may not have sufficient resources to devote. Given this, an automatic update might have as many downsides as positives.
As an interim measure however, someone who uses extensions may wish to consider:
1) Adding a "watch" to the extension article. Most extension writers concerned with updates and the common good often post notes, advisories, etc. informing administrators of current and upcoming changes.
2) Add a new custom localhost.php file (e.g., $ip/extensions/mylocalhost.php), where you reference your extensions to isolate and track your local extension list. Then use the single:
require_once("$IP/extensions/mylocalhost.php");
Version tracking remains an obsticle, but until an extension manager is written, these two tips might give you a reasonable workaround.
Jack D. Pond
"Vast and fearsome as the human scene has become, personal contact of the right people, in the right places, at the right time, may yet have a potent and valuable part to play in the cause of peace which is in our hearts." -- Sir Winston Leonard Spencer Churchill(1874-1965) -----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Kasimir Gabert Sent: Thursday, June 07, 2007 11:49 PM To: MediaWiki-l@lists.wikimedia.org Subject: [Mediawiki-l] Extension manager
Are there any talks of implementing an extension manager and a proper extension repository? Something that will allow new versions to be detected, downloaded, UPGRADE files to be displayed, etc all from one location? Something that could also allow enabling, disabling, installing, and uninstalling extensions?
I would be willing to work on one if there is a demand.
Kasimir
-- Kasimir Gabert
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org