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!

Dependency Graph View Issue ] Relation Graph ] Vertical ]
related to child of duplicate of

Viewing Issue Simple Details
ID 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  
Assigned To
Priority normal Resolution open  
Status active      
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.



Web Development by Intechnic
In-Portal Open Source CMS
In-Portal Open Source CMS
Copyright © 2000 - 2009 MantisBT Group

Powered by Mantis Bugtracker