Loading...
 
Skip to main content

History: Addons Cleanup

View published page Collapse Into Edit Sessions

Comparing version 70 with version 76

Go to current version
Lines: 6-13Lines: 6-13
 But because it has not been used much, it has been put on the ((Endangered Features)) list and its removal has been added as a TODO for ((Tiki20)). The rationale is not only to avoid maintaining code that is not used much, but also to avoid providing too many ways of ((doc:Extending Tiki)), as that can be confusing to users of Tiki. But because it has not been used much, it has been put on the ((Endangered Features)) list and its removal has been added as a TODO for ((Tiki20)). The rationale is not only to avoid maintaining code that is not used much, but also to avoid providing too many ways of ((doc:Extending Tiki)), as that can be confusing to users of Tiki.
-Since the company where Nelson works at uses Addons, he had a look at how useful functionality can be preserved while the Addons feature is removed. The result of that earlier exercise is a now outdated ((AddonsCleanupOriginalRequirements)) which was discussed by Nelson with [https://tiki.org/userpagemarclaporte|Marc] in December 2018, and then subsequently with [https://github.com/rjsmelo|Ricardo] in February 2019 to see if he could do the work after Nelson secured a budget from his company to fund it. After more in-depth discussions with Ricardo who did an investigation into the Addons code and also looked at some of the Addons that were developed at Nelson's workplace, the outcome is this document requesting comments from everyone. +Since the company where Nelson works at uses Addons, he had a look at how useful functionality can be preserved while the Addons feature is removed. The result of that earlier exercise is a now outdated ((Addons Cleanup Original Requirements)) which was discussed by Nelson with [https://tiki.org/userpagemarclaporte|Marc] in December 2018, and then subsequently with [https://github.com/rjsmelo|Ricardo] in February 2019 to see if he could do the work after Nelson secured a budget from his company to fund it. After more in-depth discussions with Ricardo who did an investigation into the Addons code and also looked at some of the Addons that were developed at Nelson's workplace, the outcome is this document requesting comments from everyone.
 !Overall Strategy !Overall Strategy
-First, we consider the general topic of ((doc:Extending Tiki)). Right now, if you want to modify the way that Tiki looks and feels, it is clear that you use ((doc:Themes)). If you want to add __code__, then ((doc:Packages)) is the main way. +First, we consider the general topic of ((doc:Extending Tiki)). Right now, if you want to modify the way that Tiki looks and feels, it is clear that you use ((doc:Themes)). If you want to add third-party __code__, then ((doc:Packages)) is the main way.
 However, even though ((doc:Packages)) is great for adding code dependencies for Tiki, it is lacking bindings with Tiki core to facilitate installing __custom code extensions to Tiki__ without introducing hacks that touch Tiki core folders and files.  However, even though ((doc:Packages)) is great for adding code dependencies for Tiki, it is lacking bindings with Tiki core to facilitate installing __custom code extensions to Tiki__ without introducing hacks that touch Tiki core folders and files.
Lines: 21-61Lines: 21-65
 As for the vision of the Addons Marketplace, I think it will have to be put to rest for now. However, if in the future it makes sense to revive the vision it can always be done as a Packages Marketplace, which actually makes much more sense anyway since Packages uses Composer which is a standard for PHP. As for the vision of the Addons Marketplace, I think it will have to be put to rest for now. However, if in the future it makes sense to revive the vision it can always be done as a Packages Marketplace, which actually makes much more sense anyway since Packages uses Composer which is a standard for PHP.
-!Details +! Details
 The following describes each of the functionality that currently exists in Addons and how it will handled as part of the cleanup. The following describes each of the functionality that currently exists in Addons and how it will handled as part of the cleanup.
-!!Ability to specify dependency addons +!! Ability to specify dependency addons
 In Addons, it is possible to specify that an addon is a dependency on another addon. ((Packages)) is using Composer which already support specifying dependencies. In Addons, it is possible to specify that an addon is a dependency on another addon. ((Packages)) is using Composer which already support specifying dependencies.
 ^To remove this Addon functionality together with the removal of Addons^ ^To remove this Addon functionality together with the removal of Addons^
-!!Ability to version Addons and keep track which version is currently installed. +!! Ability to version Addons and keep track which version is currently installed.
 Packages uses Composer which basically does this. Addons has a db table within Tiki that keeps track of which version is currently installed but this would not be needed using Packages. Packages uses Composer which basically does this. Addons has a db table within Tiki that keeps track of which version is currently installed but this would not be needed using Packages.
 ^To remove this Addon functionality together with the removal of Addons^ ^To remove this Addon functionality together with the removal of Addons^
-!!Ability to run profiles when custom code is added +!! Ability to run profiles when custom code is added
 Right now, this is possible with Addons but not with Packages. When you are adding custom code that extends Tiki, you will often want to set some Tiki configurations or create some Tiki objects that the code depends on using Profiles. It is very neat to be able to package together certain profiles to be executed when custom code is introduced. Right now, this is possible with Addons but not with Packages. When you are adding custom code that extends Tiki, you will often want to set some Tiki configurations or create some Tiki objects that the code depends on using Profiles. It is very neat to be able to package together certain profiles to be executed when custom code is introduced.
 ^Extend Packages to support packaging together Profiles that execute when a package is installed. There should be a way to specify which Profile to execute as the main one (secondary profiles can be included in the main one using existing functionality mentioned below). The installer should not re-run Profiles already executed.^ ^Extend Packages to support packaging together Profiles that execute when a package is installed. There should be a way to specify which Profile to execute as the main one (secondary profiles can be included in the main one using existing functionality mentioned below). The installer should not re-run Profiles already executed.^
-!!!Ability to install a bunch of profiles together +How about make it that profiles launch packages? Profiles already have tons of logic, and extensibility. {sign user="marclaporte" datetime="2019-03-09T14:09:10+00:00"}



!!! Ability to install a bunch of profiles together
 This functionality is already possible within profiles itself. You can already link to other profiles, as part of one profile: [https://profiles.tiki.org/Test_All_Feature This functionality is already possible within profiles itself. You can already link to other profiles, as part of one profile: [https://profiles.tiki.org/Test_All_Feature
 s#Including_a_bunch_of_profiles] s#Including_a_bunch_of_profiles]
 ^To remove this Addon functionality together with the removal of Addons^ ^To remove this Addon functionality together with the removal of Addons^
-!!!Ability to check if a profile is meant for a particular or minimum Tiki version +!!! Ability to check if a profile is meant for a particular or minimum Tiki version
 Right now this is not possible outside of Addons, but it is useful. Right now this is not possible outside of Addons, but it is useful.
 ^To make it possible to add meta information into profiles. This meta information can include specifying particular or minimum Tiki version(s) that the profile can be installed on. The profiles installer will do this check before installing a profile^ ^To make it possible to add meta information into profiles. This meta information can include specifying particular or minimum Tiki version(s) that the profile can be installed on. The profiles installer will do this check before installing a profile^
-!!!Ability to selectively forget or reapply previously installed Profiles when upgrading custom code +This would help cleanup profiles.tiki.org which currently uses categories for this. {sign user="marclaporte" datetime="2019-03-10T16:19:13+00:00"}



!!! Ability to selectively forget or reapply previously installed Profiles when upgrading custom code
 Right now, with Addons, it is possible to specify certain Profiles to reapply or forget when it is upgraded. For security reasons, there is checking to make sure that these are Profiles that came with that Addon. However, there is an easy alternative to "reapply" which is to make a new profile that has the exact same contents as the old one, and "forget" is not really useful. Right now, with Addons, it is possible to specify certain Profiles to reapply or forget when it is upgraded. For security reasons, there is checking to make sure that these are Profiles that came with that Addon. However, there is an easy alternative to "reapply" which is to make a new profile that has the exact same contents as the old one, and "forget" is not really useful.
 ^To remove this Addon functionality together with the removal of Addons^ ^To remove this Addon functionality together with the removal of Addons^
-!!!Ability to specify Tiki objects to delete when upgrading custom code +!!! Ability to specify Tiki objects to delete when upgrading custom code
 Right now in Addons, it is possible to delete objects that have been created by the Profiles in that Addon when it is upgraded. For security reasons, there is checking to make sure that the object being created was in fact previously created by one of the Profiles of that particular Addon. The workaround would be to manually delete those Tiki objects, or to do that using custom code. I think the workaround is acceptable in order to not maintain extra functionality. Right now in Addons, it is possible to delete objects that have been created by the Profiles in that Addon when it is upgraded. For security reasons, there is checking to make sure that the object being created was in fact previously created by one of the Profiles of that particular Addon. The workaround would be to manually delete those Tiki objects, or to do that using custom code. I think the workaround is acceptable in order to not maintain extra functionality.
 ^To remove this Addon functionality together with the removal of Addons^ ^To remove this Addon functionality together with the removal of Addons^
-!!!Ability to remove Tiki objects that were created by that Addon when uninstalled. +!!! Ability to remove Tiki objects that were created by that Addon when uninstalled.
 Addons can be uninstalled and it is possible to specify what Tiki objects to delete as part of uninstall process when this happens. For security reasons, there is checking to make sure that the object being created was in fact previously created by one of the Profiles of that particular Addon. There is already [https://profiles.tiki.org/Profile+Rollback|Profile Rollback] that works through the Action Log which kind of serves that purpose. Addons can be uninstalled and it is possible to specify what Tiki objects to delete as part of uninstall process when this happens. For security reasons, there is checking to make sure that the object being created was in fact previously created by one of the Profiles of that particular Addon. There is already [https://profiles.tiki.org/Profile+Rollback|Profile Rollback] that works through the Action Log which kind of serves that purpose.
 ^To remove this Addon functionality together with the removal of Addons^ ^To remove this Addon functionality together with the removal of Addons^
-!!Ability to avoid unreliable hardcoded object IDs in custom Smarty templates and wiki page content +!! Ability to avoid unreliable hardcoded object IDs in custom Smarty templates and wiki page content
 Hardcoded IDs are unreliable in custom Smarty templates as well as wiki page content (e.g. in ((doc:PluginList|List Plugins))) as they might vary from one instance of Tiki to another. As such, for these to be able to work without modification across different Tiki instances, one should refer to Tiki objects using their Profile Reference rather than their IDs. Hardcoded IDs are unreliable in custom Smarty templates as well as wiki page content (e.g. in ((doc:PluginList|List Plugins))) as they might vary from one instance of Tiki to another. As such, for these to be able to work without modification across different Tiki instances, one should refer to Tiki objects using their Profile Reference rather than their IDs.
Lines: 63-67Lines: 67-73
 ^This functionality is generically useful for Tiki as a whole and so should be moved to Tiki core in a simplified form. A wiki plugin in addition to the Smarty function should be created so that it can be used in Wiki Page content as well.^ ^This functionality is generically useful for Tiki as a whole and so should be moved to Tiki core in a simplified form. A wiki plugin in addition to the Smarty function should be created so that it can be used in Wiki Page content as well.^
-!!Ability to include templates, css, img etc within custom code packages +Indeed, this is a challenge: ((Divergent Preferences in Staging Development Production)) and some work was done: https://sourceforge.net/p/tikiwiki/code/67442



!! Ability to include templates, css, img etc within custom code packages
 While it may appear that these things belong in a Theme rather than in Packages, there are situations where they indeed belong in Packages rather than in a Theme. This is because templates, css, img etc might be part and parcel of the __functionality__ of the custom code that you are installing, similar to templates, css and img in out-of-the-box Tiki core. In contrast, the purpose of the Theme controls the __look and feel__ of the site. The following is critical to understand: While it may appear that these things belong in a Theme rather than in Packages, there are situations where they indeed belong in Packages rather than in a Theme. This is because templates, css, img etc might be part and parcel of the __functionality__ of the custom code that you are installing, similar to templates, css and img in out-of-the-box Tiki core. In contrast, the purpose of the Theme controls the __look and feel__ of the site. The following is critical to understand:
 *It needs to be possible to install and use multiple different Packages at the same time, since they add functionality, but you can only use one Theme any point in time. *It needs to be possible to install and use multiple different Packages at the same time, since they add functionality, but you can only use one Theme any point in time.
Lines: 75-83Lines: 81-89
 ^To refactor everything into shared code for both Packages and Theme Install to avoid duplication. Packages will be able to contain Themes too, so it would be possible to install a theme through Composer by putting it in a Package if you want to take advantage of versioning or to package custom code with it. Themes Install will be retained as a simpler Composer-less method to install Themes from a zip file but it will not support custom code, as it is important that code is versioned (and Composer provides that).^ ^To refactor everything into shared code for both Packages and Theme Install to avoid duplication. Packages will be able to contain Themes too, so it would be possible to install a theme through Composer by putting it in a Package if you want to take advantage of versioning or to package custom code with it. Themes Install will be retained as a simpler Composer-less method to install Themes from a zip file but it will not support custom code, as it is important that code is versioned (and Composer provides that).^
-!!Ability to include lang files within custom code packages +!! Ability to include lang files within custom code packages
 It would be convenient to be able to include a lang file within a Package, since __custom code that extends Tiki__ for a multilingual site will always contain language strings that need to be translated. It is much neater and makes it unnecessary to separately provide instructions how to add language strings into lang/xx/custom.php when installing __custom code that extends Tiki__.  It would be convenient to be able to include a lang file within a Package, since __custom code that extends Tiki__ for a multilingual site will always contain language strings that need to be translated. It is much neater and makes it unnecessary to separately provide instructions how to add language strings into lang/xx/custom.php when installing __custom code that extends Tiki__.
 ^To move this functionality to Packages^ ^To move this functionality to Packages^
-!!Ability to add custom prefs to custom code packages +!! Ability to add custom prefs to custom code packages
 Not just setting preferences (which can be done through Profiles), but extending Tiki with totally new preferences that control settings for how the custom code behaves, etc. Actually, Themes might benefit from this too as you might want to add preferences within Themes to be able to set different look and feel options, e.g. "show something or not, different layout options", in a more fine-grained way than just using ((themes:Theme Option)). Not just setting preferences (which can be done through Profiles), but extending Tiki with totally new preferences that control settings for how the custom code behaves, etc. Actually, Themes might benefit from this too as you might want to add preferences within Themes to be able to set different look and feel options, e.g. "show something or not, different layout options", in a more fine-grained way than just using ((themes:Theme Option)).
Lines: 85-105Lines: 91-111
 ^To move this functionality over to Packages, as well as make it possible for Themes to be able to make use of this functionality too. To refactor into shared code whatever shared functionality between Packages and Themes to avoid duplication^ ^To move this functionality over to Packages, as well as make it possible for Themes to be able to make use of this functionality too. To refactor into shared code whatever shared functionality between Packages and Themes to avoid duplication^
-!!PHP Namespaces handling for custom code packages +!! PHP Namespaces handling for custom code packages
 There is some PHP namespace (http://php.net/manual/en/language.namespaces.php) management functionality in Addons so that when you add PHP code you can't clobber any Tiki core variables. Right now it is very prescriptive how the namespacing is done based on the Addon name, and there is code that enforces using the right namespace. However, so long a people writing custom code follow best practices in using PHP Namespaces, there should not be a need to be so prescriptive/restrictive. There is some PHP namespace (http://php.net/manual/en/language.namespaces.php) management functionality in Addons so that when you add PHP code you can't clobber any Tiki core variables. Right now it is very prescriptive how the namespacing is done based on the Addon name, and there is code that enforces using the right namespace. However, so long a people writing custom code follow best practices in using PHP Namespaces, there should not be a need to be so prescriptive/restrictive.
 ^To remove this Addon functionality together with the removal of Addons but make sure that best practices when writing custom code that extends Tiki is documented well^ ^To remove this Addon functionality together with the removal of Addons but make sure that best practices when writing custom code that extends Tiki is documented well^
-!!Ability to have own isolated Smarty instance within custom code packages +!! Ability to have own isolated Smarty instance within custom code packages
 As Smarty doesn't support any equivalent of PHP namespaces, this was an attempt in Addons to achieve the same kind of isolation for Smarty variables, so that when you add custom Tiki templates you can't clobber any Tiki core Smarty variables. However, this is not supported in Themes either so if it's in Addons only it kind of creates a two-class situation. Moreover, this is the kind of functionality that Smarty should provide really and shouldn't need to be handled within Tiki. Also, there is a workaround that developers can use which is to use exclusively variables like $custompackagename.variable within the templates that they introduce if they are paranoid. As Smarty doesn't support any equivalent of PHP namespaces, this was an attempt in Addons to achieve the same kind of isolation for Smarty variables, so that when you add custom Tiki templates you can't clobber any Tiki core Smarty variables. However, this is not supported in Themes either so if it's in Addons only it kind of creates a two-class situation. Moreover, this is the kind of functionality that Smarty should provide really and shouldn't need to be handled within Tiki. Also, there is a workaround that developers can use which is to use exclusively variables like $custompackagename.variable within the templates that they introduce if they are paranoid.
 ^To remove this Addon functionality together with the removal of Addons but make sure that best practices when writing custom code that extends Tiki is documented well^ ^To remove this Addon functionality together with the removal of Addons but make sure that best practices when writing custom code that extends Tiki is documented well^
-!!Ability to add custom Events to trigger on certain actions +!! Ability to add custom Events to trigger on certain actions
 Tiki has a pretty powerful ((Events)) handling system. When adding custom code, it will be really useful to be able to bind to it. For example, if a certain tracker is saved you can run your own custom code to do some custom functionality, integrate with external systems etc. Tiki has a pretty powerful ((Events)) handling system. When adding custom code, it will be really useful to be able to bind to it. For example, if a certain tracker is saved you can run your own custom code to do some custom functionality, integrate with external systems etc.
 ^To move this functionality to Packages^ ^To move this functionality to Packages^
-!!Ability to add custom Search sources
Tiki has a really powerful ability to index all sorts of ((doc:Unified Index|Search)) sources into whatever search engine it supports, e.g. ElasticSearch. When adding custom code, it will be really useful to be able to index anything you want and in any way into search, essentially adding a "Content Source" to "lib/core/Search/ContentSource. Of course it is possible to manually add files there and hack the core to bind it manually, but this kind of binding should be provided through a stable API.		 +!! Ability to add custom Search sources
Tiki has a really powerful ability to index all sorts of ((doc:Unified Index|Search)) sources into whatever search engine it supports, e.g. Elasticsearch. When adding custom code, it will be really useful to be able to index anything you want and in any way into search, essentially adding a "Content Source" to "lib/core/Search/ContentSource. Of course it is possible to manually add files there and hack the core to bind it manually, but this kind of binding should be provided through a stable API.
 ^To move this functionality to Packages^ ^To move this functionality to Packages^
-!!Tracker/Token based Groups that can have unlimited Group information and other Tiki objects that belong to it +!! Tracker/Token based Groups that can have unlimited Group information and other Tiki objects that belong to it
 This functionality is used right now to enable ((doc:Organic Groups)), but it can conceivably be used in endless other use-cases as well. This functionality is used right now to enable ((doc:Organic Groups)), but it can conceivably be used in endless other use-cases as well.
Lines: 116-125Lines: 122-151
 ^To make the functionality generic and well-documented so that it can be used in other use cases, even if you are not introducing any custom code or templates. ^ ^To make the functionality generic and well-documented so that it can be used in other use cases, even if you are not introducing any custom code or templates. ^
-!!!Ability to add custom Navbar(s) for each Tracker/token-based group. +!!! Ability to add custom Navbar(s) for each Tracker/token-based group.
 In addition to the other Tiki objects mentioned above that can be linked to "belong" to a Tracker/Token-based group, it is useful for each group to be able to have Navbars that can be used in Custom Smarty templates or elsewhere. For example, the Navbar for "John's Group" might have links to "John's Forum", "John's File Gallery", etc. Right now though, Addons do not use the ((doc:Menu)) feature to implement Navbars but instead expects you to design the Navbar in a custom Smarty template. This is not good. It should just allow linking in Tiki Menus instead. In addition to the other Tiki objects mentioned above that can be linked to "belong" to a Tracker/Token-based group, it is useful for each group to be able to have Navbars that can be used in Custom Smarty templates or elsewhere. For example, the Navbar for "John's Group" might have links to "John's Forum", "John's File Gallery", etc. Right now though, Addons do not use the ((doc:Menu)) feature to implement Navbars but instead expects you to design the Navbar in a custom Smarty template. This is not good. It should just allow linking in Tiki Menus instead.
 ^Refactor to use Tiki Menus instead^ ^Refactor to use Tiki Menus instead^
-!!Ability to easily create variants of shared custom code extensions to Tiki +!! Ability to easily create variants of shared custom code extensions to Tiki
 The ((doc:Organic Groups)) feature is a good example of something that everyone who is using it might want to customize it in their own way. As such, it would be more amenable to keep it as a Package (right now it's an Addon) rather than have it in Tiki core. The challenge is to be able to make it as easy to install as possible. Either we could push it to packagist (or composer.tiki.org) or give the instructions (add url to composer.json pointing to git) for people to install the composer package. Right now, I'm leading towards composer.tiki.org as it makes it official and potentially opens up possibilities for a UI that can look there for such packages to install. However, access to composer.tiki.org is limited right now as there is no easy way to contribute a package there. Packagist would be my close 2nd choice. Any ideas? The ((doc:Organic Groups)) feature is a good example of something that everyone who is using it might want to customize it in their own way. As such, it would be more amenable to keep it as a Package (right now it's an Addon) rather than have it in Tiki core. The challenge is to be able to make it as easy to install as possible. Either we could push it to packagist (or composer.tiki.org) or give the instructions (add url to composer.json pointing to git) for people to install the composer package. Right now, I'm leading towards composer.tiki.org as it makes it official and potentially opens up possibilities for a UI that can look there for such packages to install. However, access to composer.tiki.org is limited right now as there is no easy way to contribute a package there. Packagist would be my close 2nd choice. Any ideas?
 ^Convert Organic Groups from Addon to Package. To decide where to host it (composer.tiki.org? Packagist? Other?)^ ^Convert Organic Groups from Addon to Package. To decide where to host it (composer.tiki.org? Packagist? Other?)^
 +^ I agree that we should have a common and documented way to deploy and override PHP code. Here is what I know of:
 +* "Currently any custom PHP code required for your site can now be added to _custom/lib/setup/custom.php."
 +** https://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/_custom/readme.txt
 +** And at https://dev.tiki.org/File-and-directory-structure-revamp, it is mentioned "src/ (for most of the .php files (no consensus: tiki-read_articles.php, etc renames as read_articles.php)"
 +But I disagree strongly to convert Organic Groups to a Package. __Because__ it touches on many things and it's configurable, it __should__ be part of Tiki core. Non core Organic Groups in Tiki have never worked. I have had this discussion with various people for over 10 years. Everyone who has tried has failed:
 +* ((tw:AulaWiki)) with Javier Reyes
 +* ((tw:TikiProject)) with Damian Parker
 +* ((doc:Organic Groups Addon Proof of Concept)) with Nelson Ko. Nelson wrote [https://dev.tiki.org/item5864-Organicgrp-install-problem|"Unfortunately the Organic Groups feature will have to wait till tiki 16, as we plan to do implementation of Roles feature in Tiki before pursuing organic groups again. Organic groups addon is currently not ready for production use, as it will be undergoing major revamp after Roles feature is developed. The dependency is important to ensure long term viability of this project because without core Roles capabilities in Tiki, organic groups will be a nightmare to manage."].
 +And even if you did succeed in having Organic Groups as a Package. It would be utterly fragile. Inexorably, some of the features there will be added to the core. And then, you will end up with code/data which diverges from Tiki. As explained at https://community.redhat.com/blog/2015/03/upstream-first-turning-openstack-into-an-nfv-platform/, it's will be harder and harder to maintain.
 +So the first thing to do is solve roles / organic groups for the base / common use case. Have one common solution that everyone can use out-of-the-box. As a reference, we can look at what was done in the Tiki community, but also beyond, with projects such as https://elgg.org/showcase/ And then, it makes sense to override / extend via themes, profiles, Smarty Templates or even PHP code.
 +Here is some related work: [https://sourceforge.net/p/tikiwiki/code/42685/]
 +{sign user="marclaporte" datetime="2019-03-10T16:19:13+00:00"}
 +^
 +~tc~ (alias(AddonsCleanup)) ~/tc~

History

Information Version
20 Oct 25 09:37 UTC Baraka Kinywa 95
09 Aug 19 23:58 UTC Nelson Ko 94
05 Aug 19 20:56 UTC Jean-Marc Libs 93
05 Aug 19 20:44 UTC Jean-Marc Libs 92
05 Aug 19 20:43 UTC Jean-Marc Libs 91
05 Aug 19 18:47 UTC Jean-Marc Libs 90
24 Jul 19 10:53 UTC Nelson Ko 89
24 Jul 19 10:52 UTC Nelson Ko 88
24 Jul 19 10:48 UTC Nelson Ko 87
24 Jul 19 10:40 UTC Nelson Ko 86
24 Jul 19 10:12 UTC Nelson Ko 85
24 Jul 19 10:03 UTC Nelson Ko 84
24 Jul 19 08:39 UTC Marc Laporte 83
24 Jul 19 08:02 UTC Marc Laporte Another idea 82
23 Jul 19 13:05 UTC Marc Laporte Cartograf is a sort of organic group around a map 81
03 Jul 19 14:04 UTC Marc Laporte 80
15 May 19 08:54 UTC Marc Laporte 79
05 Apr 19 20:35 UTC Nelson Ko 78
11 Mar 19 00:52 UTC Jonny Bradley my 3¢ 77
10 Mar 19 16:19 UTC Marc Laporte 76
10 Mar 19 16:19 UTC Marc Laporte My general support to this project, except for the part about keeping "Organic Groups" out of core. 75
10 Mar 19 15:06 UTC Marc Laporte 74
10 Mar 19 05:39 UTC Marc Laporte Page renamed from AddonsCleanup to Addons Cleanup. Semantic alias redirect created 73
09 Mar 19 14:12 UTC Marc Laporte Roles 72
09 Mar 19 14:09 UTC Marc Laporte An idea in a unfinished discussion with Jonny 71
  • «
  • 1 (current)
  • 2
Show PHP error messages