Minimize In-Portal Core with ability to download/update Modules online

[Dmitry A.]

Hello everyone,

It's quite noticeable that out In-Portal CORE is constantly growing in all directions - both features and code. I believe we should consider the option for unloading (making less populated) features from it.

These are the topic I propose to discuss here:

1. Minimize In-Portal CORE

2. Introduce smaller Components (Extensions)

If CORE is minimized we should think about what to do with all these features we are going to Remove from the CORE. One of the ideas is to have Modules (as we have now) which are build from a small Components (or perhaps Extensions is a good word too). At the same time, you can get these Components on it's own, but some of them would have Dependencies (other components).

3. Downloads and Updates over the Web

Guys, this is a long discussion so let's start moving and try stay focused and constructive by expressing your thoughts and ideas.

DA

[Phil -- wbtc.fr --]

Hi Dmitry,

I was about to launch a related discussion, about "updates" and "downloads".

We can find in all moderm platforms (cms, forums...) 2 types of features:

• Updates
• user can select updates retrieved from a list, or directly update to latest version
• file download is entirely made by the script, no user action
• files install is also made by the script, just providing FTP credentials before installing step
• we can add an automatic backup of DB and files, which could be ran in background (no need to keep window open, like Parallels installer do)
  
  
• Downloads & Extensions
  
• "Downloads" are called everywhere "Plugins"
  
• I think custom code should be considered like plugins, and maybe rename the custom folder to Plugin
• Extensions could be handled separatly, but using the same process as below
  
• list of available plugins can be viewed directly from admin (we need to maintain an official and open repository somewhere)
  
• download and install are completly automated via FTP
• because plugin is a third party code
• we can activate/deactivate the plugin any time
• if the plugin fail to launch after install (generate a fatal error), then we display an error message and disable it (just like Wordpress do in a very clean way)
  

P

2011/2/11 Dmitry A. <dand...@gmail.com>

[Alexander Obuhovich]

we can add an automatic backup of DB and files, which could be ran in background (no need to keep window open, like Parallels installer do)

I don't like it. It's hosting control panel who is responsible for automatic backup of database and files, not software itself. You already talked about this in another discussion with no support there during large development time requirements.

if the plugin fail to launch after install (generate a fatal error), then we display an error message and disable it (just like Wordpress do in a very clean way)

If plugin crashes all system, then how we can disable it with all system crashed? It's like somebody shoot somebody in the head. Taking out the bullet won't do any good, since death is inevitable. :)

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Dmitry A.]

Alex, Phil - thanks for sharing your opinions and ideas.

I'll address Phil's ideas first:

• Updates
• user can select updates retrieved from a list, or directly update to latest version (It's okay, but still need to think this through)
• file download is entirely made by the script, no user action (yes, as I described)
• files install is also made by the script, just providing FTP credentials before installing step (good idea with FTP credentials, so we don't need to have 777 permissions to write - Alex, what you think?)
• we can add an automatic backup of DB and files, which could be ran in background (no need to keep window open, like Parallels installer do) (I say - may be in a long run we can add this us, but not so critical now. Somewhat agree with Alex)
  
  
• Downloads & Extensions
  
• "Downloads" are called everywhere "Plugins" (I would call everything Extensions, why we need Plugins and Extensions. In the end it's all the same code, while Modules can be composed from multiple Extensions)
  
• I think custom code should be considered like plugins, and maybe rename the custom folder to Plugin (idea might not as good as you think Phil - a bit confusing, but still considerable - we have to think and discuss this more)
• Extensions could be handled separatly, but using the same process as below (see above)
  
• list of available plugins can be viewed directly from admin (we need to maintain an official and open repository somewhere) (Extensions can have a developer source - In-Portal, or 3rd party)
  

• download and install are completly automated via FTP

• because plugin is a third party code ()

• we can activate/deactivate the plugin any time

• if the plugin fail to launch after install (generate a fatal error), then we display an error message and disable it (just like Wordpress do in a very clean way) (I guess we need to determine if extension installed okay before we start using - self-test if possible). If it's PHP fatal error - there is not much we can do :)

Alex, what do you think about this idea and mostly about separating in a smaller pieces and calling them differently?

DA

[Alexander Obuhovich]

Ok about ftp. I looked into WordPress code and here is what it does:

1. download zip file from wordpress website
2. unpack it into temp folder
3. use ssh/ftp to connect to same website, where wordress is and copy data file by file from temp folder to a website
4. change permissions so files won't be writable (using chmod command of ftp/ssh)

Pretty cool actually. It even support ssh public keys to be used (no password should be specified). It doesn't store passwords in database and only asks them when upgrade will be performed. I suppose it's upgrade system is separated from base code, so it actually can upgrade itself :)

Self testing is good, but it's going to take a while before we could write automated tests from each piece of In-Portal.

In theory extensions/plugins can be placed in modules, but in practice I can't imagine what directory structure of such module+extensions hybrid could be considering, that each module/extension could have:

• install/uninstall sql file
• images
• templates
• language pack

[Dmitry A.]

Hi Alex,

1. Thanks for checking WordPress - yes, I am thinking about the same idea here. SSH Public keys is very nice too. For now I don't have many ideas on how to implement CORE independent Installation/Upgrade system, but we can really discuss it later if we need to go this far at the start. Please feel free to share your thoughts on this is if you have something in mind.

2. Testing, we can start with basic DB version stamp vs. Files stamp to make sure they match and always add more down the road. I wasn't thinking about creating Test Units just for this purpose - something much simpler can be used at the beginning. 

3. Modules/Extensions - yes, I see your point. The more I look at our structure and other software around us I see that we might want to stick to a single terms in terms of what you can install. That means that we can easily break the content of our current CORE/UNITS folder into 4-10 different Modules that are independent (or some might be depended to others) from each other. Even if some have a single Unit in the folder (ie. Article, Links), I think we still can accept that. Let's not be afraid of having more things under the MODULES/ folder.

Basically, what I am saying is let's pretend you create a modules where the smallest part will be a one or more Units. If I decide to create a new functionality I can easily see which other Modules can accommodate it or start creating my own Module. The CORE has to become very very light and be used as a foundation for all other classes.

Alex, what do you think of this? Other guys?

DA

[Phil -- wbtc.fr --]

Alex, you have guessed right, I was talking about Wordpress way of doing ;-)

About testing plugin before use it, Wordpress also have this feature, that's why I talked about it.

2011/2/12 Dmitry A. <dand...@gmail.com>

[Dmitry A.]

Hi Phil,

Not to disappoint you, but WordPress is most likely simulates the self-test - it's not even close to what Alex and I were thinking about :) But it's not that critical I believe.

DA

[Phil -- wbtc.fr --]

I'm not disappointed, but rather very happy to read you guys are interested by this subject.

I'd also recommend the FTP access style for first install, as this could check and/or fix all files permission, and could also do this check on update/extension install.

2011/2/13 Dmitry A. <dand...@gmail.com>

[Alexander Obuhovich]

I didn't find a message on plugin update screen, that says, that plugin has no conflicts or something like that that I can track to actual code, Phil. Where is it?

But I've found "View Details" link near module, which grabbed info from wordpress website and displayed nice popup with:

1. module description
2. specific installation instructions
3. change log

So basically all developed modules should be stored on our server and all issues should tracked in our issue tracker to do that.

I agree about lot of small pieces, so we won't be having 72 tables just in Core module, that most of the users don't even use.

[Phil -- wbtc.fr --]

In one of my install, WordPress 2.8.4, when I try to install a plugin named "Filtered HTML for Editors 1.0", I have the following message:

Plugin could not be activated because it triggered a fatal error.

The functions to "activate/deactivate/install/delete" are very handy.

2011/2/13 Alexander Obuhovich <aik....@gmail.com>

[Dmitry A.]

Hi guys,

Summary of what we have agreed on (so far):

1. We'll remove all Units unnecessary for default In-Portal installation (CORE only) and will group them into separate Modules based on usage logic. Target is to minimize CORE installation to 20-30 tables (at most).

2. Each of the modules will "live" under current modules/ folder and will have the same structure as current modules. Each individual "unit" will NOT be considered as a logic piece NOR a module on it's own.

3. Modules name can contain alpha-numeric + "-" symbols in it, but not necessarily should start with "in-".

Let's move forward and create a list of units from CORE and group them by usage or related logic.

DA

[Alexander Obuhovich]

Here is my info about each core table (each 72 of them):

• Agents - used for regular event storing
• BanRules - user ban rules (rarely used)
• Cache - general data caching (used all the time)
• CachedUrls - mod-rewrite url caching (used only on Front-end)
• Category - site structure (always used, when Front-end is used)
• CategoryCustomData - category custom field values
• CategoryItems - what category item is located in what category (no need at all, when there are none category items)
• ChangeLogs - tracks down changes made to database (can live without it)
• ConfigurationValues - all sort of configuration settings (always used)
• CountCache - caching category item count (maybe in use, but I'm not sure)
• Counters - non-mecache based counters (pretty much useless)
• CountryStates - countries and states (used)
• CustomField - custom fields (used for categories, users, category items). May not be part of default install
• Drafts - form submission drafts
• EmailLog - log of which emails were sent from the site
• EmailQueue - where emails should be sent at specific time, then this table is used
• EmailSubscribers - used?
• Events - definitions of email events
• Favorites - favorite category items and friend list (in in-bulletin)
• FormFields - list of submission form fields
• Forms - submission form fields
• FormSubmissions - submission data, posted by site visitors
• IdGenerator - not ideal, but still needed way of keeping unique IDs across categories, category items and users
• IgnoreKeywords - maybe some stuff that In-Bulletin uses, but I'm not sure
• Images - user/category/category item images
• ImportCache - I don't know what this is for
• ImportScripts - list of scripts for external data import (doesn't make sense, when there are no category items to process)
• ItemFiles - category item files
• ItemRating - category item ratings
• ItemReview - category item review
• ItemTypes - general information about available category items
• Language - list of languages
• LocalesList - list of locales (used in languages)
• MailingLists - way to send single mail to whole user group
• Modules - list of modules installed
• PageContent - content block data, used on cms pages
• PermCache - category-based permission caching (because of inheritance)
• PermissionConfig - list of all possible category-based permissions
• Permissions - what permissions were set
• PersistantSessionData - user specific data, that stays across all user visits to the site
• Phrase - list of labels
• PhraseCache - way of caching label and phrase data based on visited template
• PopupSizes - cached (from TPL files) sizes of all popups being used
• PortalGroup - list of permission groups
• PortalUser - list of users
• PortalUserCustomData - list of user custom fields
• RelatedSearches - category item related searches (can live without it)
• Relationship - category/category item relations
• SearchConfig - front-end search configuration settings
• SearchLog - list of search queries, used on Front-end
• Semaphores - data loss protection system
• SessionData - user session-specific data
• SessionLogs - session usage log
• SiteDomains - multi-domain support
• Skins - admin skinning support
• SlowSqlCapture - list of slow sqls being performed lately
• SpamControl - system for preventing duplicate submits across short periods of time on Front-end
• SpellingDictionary - spelling suggestions for search query on front-end
• StatisticsCapture - database query execution statistics
• StatItem - used (no longer in use now) way of collecting various system information and display it to user
• StopWords - way of narrowing down search criteria on front-end
• Stylesheets - no longer in use, must be deleted
• StylesheetSelectors - no longer in use, must be deleted
• SubmissionLog - list of messages, associated with a form submissions
• SysCache - I don't know what this is
• TagAttributes - no longer in use, must be deleted
• TagLibrary - no longer in use, must be deleted
• Theme - list of front-end themes
• ThemeFiles - list of front-end theme files
• Thesaurus - somehow front-end search related
• UserGroup - what user is in what group
• UserSession - list of active user sessions
• Visits - attempt to create simplified google analytics, but isn't used

[Phil -- wbtc.fr --]

thanks for this great table overview _

2011/2/19 Alexander Obuhovich <aik....@gmail.com>

[Dmitry A.]

I have reviewed your list and here is some preliminary suggestions, please review and comment.

I have counted 34-35 tables if we include all CORE and CORE? tables.

• Agents - used for regular event storing CORE
• BanRules - user ban rules (rarely used) - UserBans
• Cache - general data caching (used all the time) CORE
• CachedUrls - mod-rewrite url caching (used only on Front-end) CORE
• Category - site structure (always used, when Front-end is used) CORE
• CategoryCustomData - category custom field values CORE?
• CategoryItems - what category item is located in what category (no need at all, when there are none category items) - CategoryItems
• ChangeLogs - tracks down changes made to database (can live without it) – Logs or something else
• ConfigurationValues - all sort of configuration settings (always used) CORE
• CountCache - caching category item count (maybe in use, but I'm not sure) NOT USED
• Counters - non-mecache based counters (pretty much useless) - Stores list of SQLs which can be called from 1 single Tag to return counters – I would leave it, not sure in CORE or not. Otherwise you need to have 1+ different tags for each items.
• CountryStates - countries and states (used) CORE
• CustomField - custom fields (used for categories, users, category items). May not be part of default install CORE?
• Drafts - form submission drafts - Forms
• EmailLog - log of which emails were sent from the site CORE?
• EmailQueue - where emails should be sent at specific time, then this table is used – Mailing Lists
• EmailSubscribers - used? Deleted
• Events - definitions of email events CORE?
• Favorites - favorite category items and friend list (in in-bulletin) - CategoryItems
• FormFields - list of submission form fields - Forms
• Forms - submission form fields - Forms
• FormSubmissions - submission data, posted by site visitors - Forms
• IdGenerator - not ideal, but still needed way of keeping unique IDs across categories, category items and users - CORE
• IgnoreKeywords - maybe some stuff that In-Bulletin uses, but I'm not sure - Censorship
• Images - user/category/category item images – CORE?
• ImportCache - I don't know what this is for – used in “/helpers/cat_dbitem_export_helper.php” - CategoryItems
• ImportScripts - list of scripts for external data import (doesn't make sense, when there are no category items to process) - CategoryItems
• ItemFiles - category item files - CategoryItems
• ItemRating - category item ratings - CategoryItems
• ItemReview - category item review - CategoryItems
• ItemTypes - general information about available category items – CORE?, has Users and Categories Type too, not sure if need it there
• Language - list of languages CORE
• LocalesList - list of locales (used in languages) – CORE?
• MailingLists - way to send single mail to whole user group – Mailing Lists
• Modules - list of modules installed - CORE
• PageContent - content block data, used on cms pages - CORE
• PermCache - category-based permission caching (because of inheritance) – CORE?
• PermissionConfig - list of all possible category-based permissions – CORE?
• Permissions - what permissions were set – CORE?
• PersistantSessionData - user specific data, that stays across all user visits to the site - CORE
• Phrase - list of labels - CORE
• PhraseCache - way of caching label and phrase data based on visited template - CORE
• PopupSizes - cached (from TPL files) sizes of all popups being used – Moved it Cache table?
• PortalGroup - list of permission groups – CORE?
• PortalUser - list of users – CORE?
• PortalUserCustomData - list of user custom fields – CORE?
• RelatedSearches - category item related searches (can live without it) – RelatedSearches
• Relationship - category/category item relations – CategoryItems or Relationships
• SearchConfig - front-end search configuration settings – CORE or Search
• SearchLog - list of search queries, used on Front-end - Logs
• Semaphores - data loss protection system - CORE
• SessionData - user session-specific data - CORE
• SessionLogs - session usage log - Logs
• SiteDomains - multi-domain support - SiteDomains
• Skins - admin skinning support - CORE
• SlowSqlCapture - list of slow sqls being performed lately – Logs or something else
• SpamControl - system for preventing duplicate submits across short periods of time on Front-end – Censorship
• SpellingDictionary - spelling suggestions for search query on front-end – Censorship or Search
• StatisticsCapture - database query execution statistics – Logs or something else
• StatItem - used (no longer in use now) way of collecting various system information and display it to user – I would use Counters table for this and delete this one
• StopWords - way of narrowing down search criteria on front-end – Censorship or Search
• Stylesheets - no longer in use, must be deleted - DELETE
• StylesheetSelectors - no longer in use, must be deleted - DELETE
• SubmissionLog - list of messages, associated with a form submissions - Forms
• SysCache - I don't know what this is - DELETE
• TagAttributes - no longer in use, must be deleted - DELETE
• TagLibrary - no longer in use, must be deleted - DELETE
• Theme - list of front-end themes - CORE
• ThemeFiles - list of front-end theme files - CORE
• Thesaurus - somehow front-end search related – Censorship or Search
• UserGroup - what user is in what group - CORE
• UserSession - list of active user sessions - CORE
• Visits - attempt to create simplified google analytics, but isn't used - Logs

 

[Dmitry A.]

Quick update here.

There is a separate discussion ( https://groups.google.com/d/topic/in-portal-bugs/uwfyKB34V7s/discussion ) / task ( http://tracker.in-portal.org/view.php?id=1006 ) where we are going to delete the following tables:

1. Stylesheets - no longer in use, must be deleted - DELETE
2. StylesheetSelectors - no longer in use, must be deleted - DELETE
3. SysCache - I don't know what this is - DELETE
4. TagAttributes - no longer in use, must be deleted - DELETE
5. TagLibrary - no longer in use, must be deleted - DELETE

Alex what do you think on the main list so far?

DA

[Alexander Obuhovich]

Here is another table breakdown, that maybe better, then last one:

Main In-Portal tables

=====================

1. PortalUser (list of users/admins, registered in system)

2. PortalGroup (list of groups, that can be assigned to registered users)

3. UserGroup (user-group associations)

4. PersistantSessionData (list of session-independent user settings; fix grammatical error in table name)

5. UserSession (list of sessions, produced by logged-in site visitors)

6. SessionData (data, associated with created user sessions)

7. Language (list of languages, defined in system)

8. LocalesList (list of supported locales, used for switching website language to user's browser language only)

9. CountryStates (list of countries with their states, used on user registration form)

10. Phrase (list of language labels of every language, defined in system)

11. Events (list of e-mail templates, that can be sent from the system)

12. Modules (list of modules, installed in system)

13. ConfigurationValues (list of configuration settings)

14. SearchConfig (list of search-related settings)

15. Category (list of pages, defined in system)

16. PageContent (content, that was entered in the pages, using Content Blocks)

17. CachedUrls (list of parsed & cached page mod-rewrite urls)

18. Semaphores (table, used in engine, that protects data from concurrent edit/save attempts by different users)

19. Theme (list of front-end themes)

20. ThemeFiles (list of front-end theme templates, used for mod-rewrite page url parsing)

21. Skins (list admin console skins)

22. PermCache (used only for advanced category-based permissions scheme, that can be disabled by default in future)

23. PermissionConfig (used only for advanced category-based permissions scheme, that can be disabled by default in future)

24. Permissions (list admin section permissions)

25. Agents (list of cronjobs)

In-Portal tables, that we can get rid of by peforming refactoring

=================================================================

Cache (no need, when memcache is used)

IdGenerator (table, that keeps track of ResourceIds generated, get rid of it in future)

PhraseCache (merge with CachedUrls somehow)

PopupSizes (store in PortalUser.PopupSizes field/PersistentSessionData table as serialized array, we can have key, like md5(template_path) and popup size)

Counters (we only have 3 counters and can easily transfer them to memcache)

StatItem (delete)

In-Portal tables that can be moved into separate modules

========================================================

BanRules

================================

SessionLogs

ChangeLogs

CurlLog

SlowSqlCapture

StatisticsCapture

================================

CustomField

CategoryCustomData

PortalUserCustomData

================================

EmailQueue

EmailLog

MailingLists

================================

CategoryItems

Favorites

Images

ImportCache

ImportScripts

ItemFiles

ItemFilters

ItemRating

ItemReview

ItemTypes

SearchLog

RelatedSearches

CountCache

SpamReports

SpamControl

Relationship

================================

Drafts

FormFields

Forms

FormSubmissions

SubmissionLog

================================

SiteDomains

================================

Thesaurus

SpellingDictionary

StopWords

[Dmitry Andrejev]

Hi Alex,

Thanks for going through this list again and fine tuning.

I am going to add my comments directly on your post if you don't mind.

Let me know what you think on my comments.

DA

Cache (no need, when memcache is used) - NO, I would KEEP this one since it can be used for all type of System Caching when no Memcache available... we do need this type of table available. At some point, I was thing about having it all saved in PHP files or something, but now imagine we have 2+ Web servers that need to share the same configuration (ie. VIC project). In this case DB is by far the most efficient after the Memcache. 

 

IdGenerator (table, that keeps track of ResourceIds generated, get rid of it in future) - YES, I am sure we can use one of existing table (ie. Cache for now), and get rid of this at all later on?

 

PhraseCache (merge with CachedUrls somehow) - YES, we can quickly get rid of this one

 

PopupSizes (store in PortalUser.PopupSizes field/PersistentSessionData table as serialized array, we can have key, like md5(template_path) and popup size) 

- YES, we can quickly get rid of this one

 

Counters (we only have 3 counters and can easily transfer them to memcache) - YES, we can quickly get rid of this one

StatItem (delete) - YES, we can quickly get rid of this one

In-Portal tables that can be moved into separate modules

========================================================

   ============ USER BANS ====================

BanRules

============ LOGS ====================

SessionLogs

ChangeLogs

CurlLog

SlowSqlCapture

StatisticsCapture 

======= CUSTOM FIELDS =========================

CustomField

CategoryCustomData

PortalUserCustomData

============ MAILING LISTS ====================

EmailQueue

EmailLog - I would move to LOGS module above

MailingLists

=========== CATALOG ITEMS =====================

CategoryItems

Favorites

Images - I would possibly move to CORE since this can be used by ANY of Categories and we don't have a solid replacement for it yet.

ImportCache

ImportScripts

ItemFiles

ItemFilters

ItemRating

ItemReview

ItemTypes

SearchLog

RelatedSearches

CountCache

SpamReports

SpamControl

Relationship

============ SUBMISSION FORMS ====================

Drafts

FormFields

Forms

FormSubmissions

SubmissionLog

============ MULTI-SITE SUPPORT  ====================

SiteDomains

============ NOT SURE ABOUT THIS MODULE NAME ====================

Thesaurus

SpellingDictionary

StopWords

On Mon, Feb 21, 2011 at 9:35 PM, Dmitry A. <dand...@gmail.com> wrote:

Quick update here.

There is a separate discussion ( https://groups.google.com/d/topic/in-portal-bugs/uwfyKB34V7s/discussion ) / task ( http://tracker.in-portal.org/view.php?id=1006 ) where we are going to delete the following tables:

1. Stylesheets - no longer in use, must be deleted - DELETE
2. StylesheetSelectors - no longer in use, must be deleted - DELETE
3. SysCache - I don't know what this is - DELETE
4. TagAttributes - no longer in use, must be deleted - DELETE
5. TagLibrary - no longer in use, must be deleted - DELETE

Alex what do you think on the main list so far?

DA

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

--

Best regards,

Dmitry A.

[Alexander Obuhovich]

Ok for all. Then maybe we can move SearchLog table to logs module too.

Also I've noticed, that we don't have any task for this discussion. Maybe we need to create one in 5.2.0 release.

[Phil -- wbtc.fr --]

Hi guys,

may we also would need a task to prepare a nice interface with strong features to:

- search additional module from a distant server (@inportal)

- import module and install it (using FTP credential is script don't have sufficient rights)

- activate it (with failsafe mode if module cause a crash)

- deactivate it

- delete (again using FTP credentials if needed)

I'm not creating anything here, I just get example on the -nice- wordpress system, have you tested it?

p

2011/10/23 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

Features you're talking about are discussed in a separate discussion: https://groups.google.com/forum/#!topic/in-portal-dev/04YLtmjud1A

[Phil -- wbtc.fr --]

this thread is only about in-portal update is WP style.

I'm talking about a dedicated menu to add plugins.

2011/10/23 Alexander Obuhovich <aik....@gmail.com>

[Dmitry A.]

As much as I want, I don't think we have enough time to push this into 5.2.0 release since we don't even have any interfaces for this.

What if we break this process in multiple phases which can be implemented in different feature releases.

Phase 1

Current 5.2.0 release probably would make more programming effort for breaking In-Portal into smaller modules so you can use only what you really need. Also this would help to faster refactore CORE module and make better, faster and more lightweight.

Of course we'll have to create other smaller Modules so they can be downloaded (preferably automatically via Admin), installed and plugged-in without going to In-Portal.com.

Phase 2

Major interface upgrades and this is much more advanced and system wide change that should include improvements to the above and other sections of the website.

As you can see Phil, at this point, it totally does not make sense to invent and add any more menus, sections, pages to the current interfaces.

Thanks.

DA

[Dmitry A.]

Hi Alex,

1. Yes, Search Log probably can go in Logs module too there since it's more CORE type of logs which makes sense to have along with other Logs. At the same time all future Logs which are Module specific should stay in it's own Modules and not become part of Logs Module.

Do we agree on this?

2. Yes, there no task for this specific Minimizing part, but it was kind of referred to in - 1011: Review and Rename Table Names in CORE task.

DA

[Phil -- wbtc.fr --]

Hi Dmitry,

I was only asking about opportunity to create a thread to discuss this, far away from task and implementation steps :)

I think you are going on the right way by thinking "light", and I just give ideas on how admin could custom this lightweight core to suit their needs. Plugin could also be connectors to other online or offline services, it's a great but big part, surely for later stage.

p

2011/10/23 Dmitry A. <dand...@gmail.com>

[Alexander Obuhovich]

1 - yes, I've only described "Core" module tables here, since we only disassembling it now.

2 - then we miss a task, there are only 2 related tasks in tracker, but not exactly about separating core module into smaller modules.

[Alexander Obuhovich]

Sadly we don't have a task yet, so I post here:

I saw interesting code in WordPress and I got this idea:

Have system-level events, that modules can hook to so it will be easier for us to from module.

For example OnGetTheme event could retrieve theme_id from url and hook to it from SiteDomain module can override that theme with the one, that matches current site domain.

[Dmitry A.]

Here is a task:

1153: Minimizing In-Portal CORE

http://tracker.in-portal.org/view.php?id=1153

DA

[Alexander Obuhovich]

Looking at Drupal - http://drupal.org/project/modules?filters=tid:56, where a lots of modules are created it's not a big problem to have a lots of modules and each of modules can be maintained by it's own maintainer.

Modules can be named as primary unit in them, e.g. users, forms, etc.

[Phil]

What I like with In-Portal is that I don't need to seek for modules, all features are here, ready to use.

Another thing, "Modules" we can find in Drupal or Worpress are third party, which integrate into the system more or less seamlessly, and result in different management approach for each module.

Why not having this "third party module", but I'd prefer to have these separated from "Core modules", which integrate perfectly into system.

[Alexander Obuhovich]

As we said in this discussion we'll have all functionality (that isn't used every day) moved into corresponding new modules.

And we can have "Third-Party: yes/no" field in each module.

This way user will know which module he is about to download: one from In-Portal developers or from a community.

[Phil]

can't we even separate visually in-portal modules from third party? It could confuse users, including me  :)

Envoyé avec Sparrow