In-Portal Issue Tracker

Welcome to the In-Portal Open Source CMS Issue Tracker! This is a central management / tracking tool for all types of tasks / issues / bugs for the In-Portal Project. Before reporting any issues, please make sure to read the Guide into Issue Tracker and How to Properly Test and Report Bugs!

Viewing Issue Simple Details [ Jump to Notes ] [ Wiki ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Type

Reproducibility

Date Submitted

Last Update

0001153

[In-Portal CMS] Refactoring

refactoring

always

2011-11-01 12:27

2011-12-23 11:37

Reporter

Dmitry

View Status

public

Project Name

In-Portal CMS

Assigned To

Developer

Priority

normal

Resolution

open

Fixed in Version

Status

active

Product Version

Target Version

Icebox

Time Estimate

No estimate

Summary

0001153: Minimizing In-Portal CORE

Description

It's quite noticeable that out In-Portal CORE is constantly growing in all directions - both features and code. We should minimize the CORE module and create small modules for other less critical to In-Portal functionality.

Below is a list of tables breakdown:

In-Portal CORE 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. Images (list of images, currently used by categories and catalog items)
17. PageContent (content, that was entered in the pages, using Content Blocks)
18. Cache (system cache when no Memcached installed/used)
19. CachedUrls (list of parsed & cached page mod-rewrite urls)
20. Semaphores (table, used in engine, that protects data from concurrent edit/save attempts by different users)

21. Theme (list of front-end themes)
22. ThemeFiles (list of front-end theme templates, used for mod-rewrite page url parsing)
23. Skins (list admin console skins)

24. PermCache (used only for advanced category-based permissions scheme, that can be disabled by default in future)
25. PermissionConfig (used only for advanced category-based permissions scheme, that can be disabled by default in future)
26. Permissions (list admin section permissions)
27. Agents (list of cronjobs)

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

IdGenerator (table, that keeps track of ResourceIds generated, get rid of it in future. we can use one of existing tablesuch as Cache, and get rid of this at all later on)

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, or Cache table if memcache is not avaialble)

StatItem (delete)

In-Portal tables that can be moved into separate Modules
========================================================

USER BANS
BanRules

LOGS
SessionLogs
ChangeLogs
CurlLog
EmailLog
SlowSqlCapture
StatisticsCapture

CUSTOM FIELDS
CustomField
CategoryCustomData
PortalUserCustomData

MAILING LIST
EmailQueue
MailingLists

CATALOG ITEMS
CategoryItems
Favorites
ImportCache
ImportScripts
ItemFiles
ItemFilters
ItemRating
ItemReview
ItemTypes
SearchLog
RelatedSearches
CountCache
SpamReports
SpamControl
Relationship

SUBMISSION FORMS
Drafts
FormFields
Forms
FormSubmissions
SubmissionLog

MULTI-DOMAINS
SiteDomains

DICTIONARY
Thesaurus
SpellingDictionary
StopWords

Additional Information

========== Info from 0000268: Code Cleanup in 5.2.x branch ===
1. Somehow divide In-Portal into layers, that can be easily turned on/off.

2. Maybe modularize core itself, e.g. "form submissions", "permission system", "various logs", "visits", "site domains".

3. Maybe some parts (within the main module) can be downloaded separately.
============

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.

Issue History
Date Modified	Username	Field	Change
2011-12-23 11:37	Dmitry	Relationship added	related to 0000268
2011-12-23 11:36	Dmitry	Change Log Message	Minimized In-Portal CORE => Minimized In-Portal Core
2011-12-23 11:36	Dmitry	Additional Information Updated	View Revisions
2011-12-18 15:22	Dmitry	Target Version	5.2.0 => Icebox
2011-12-18 15:09	Dmitry	Relationship added	related to 0001011
2011-11-02 03:53	alex	Relationship added	related to 0001154
2011-11-01 12:28	Dmitry	Additional Information Updated	View Revisions
2011-11-01 12:27	Dmitry	New Issue
2011-11-01 12:27	Dmitry	Reference	=> https://groups.google.com/d/topic/in-portal-dev/vuGnrVy25cA/discussion
2011-11-01 12:27	Dmitry	Change Log Message	=> Minimized In-Portal CORE
2011-11-01 12:27	Dmitry	Estimate Points	=> 3