Core plugins need to become removable from the core without

[Jimmi08]

At first, I noticed this line in today's post, and @rica-carv mentioned my Lite version, so I would like to make some notes.

I am not asking for anything, there are more important things to do, but if we agree on far far future plan, it can be taken step by step.

I tested and tried this again and again in different ways, so maybe I can say where I hit limits and what was possible or not.

1. question what do you imagine under the word "removable"? Because there are 2 answers. First, move to separate repos or second, to be able to just delete code from installation. I did first way, but only because there were no fixes in the core for a long time. It is harder to maintain, so if it is called a core plugin, then it should be packed with the core. There can be a community decision that some plugin is not core anymore, then you can move it to a separate repo.
For the second way, I already asked about the option to delete the uninstalled plugin from the Plugin manager. But it is related to the topic of how to add those plugins back if they are needed after some time (they should be listed on e107.org then).

2. plugins types regardless of this topic, there are some types of core plugins

TYPE A = already separated (like forum, download etc) - there should be a rule that - if you delete this type of plugin files and something is broken, it is a bug (for example, missing test if plugin is installed, or hardcoded legacy stuff etc). Some are fully separated - FAQs - because they are new in version 2.

TYPE B = plugin already exists, but it is entangled with core. You know them by using core shortcodes, core templates or core URL system. The URL system is the worst - it is the plugin, so it should use the e_url addon. I was able to do this for the gallery and the news, so I know this is possible, but it is a wide topic. Any change in those plugins should start with the core URL rewrite system. The next step is moving core prefs to plugin prefs. Core prefs shouldn't contain prefs that belong to the already existing plugin area. Only then continue with handlers, shortcodes, templates...

TYPE C = functionality in core that should be in separate plugins (for me, it is comment, rating system - if the site doesn't need them, why can't I remove them by removing the plugin? ). You can see an example already in the navigation plugin; it is partially done. it is called a navigation plugin, but it is not a separate plugin.

TYPE D = plugins that duplicate functionality from legacy or back compatibility reasons - like login_menu and signin, like featurebox and hero plugin.

And with this topic, loading of e107 handlers is related too,

[e107help[bot]]

Všetko najlepšie k narodeninám, @Jimmi08! One day late, but the audit below is my card.

Your TYPE A/B/C/D classification maps really well onto what the code actually looks like. I went through the codebase with a fine-tooth comb and the evidence backs it up.

By the numbers

Core code has 65 direct include/require statements that pull in plugin files. Of those:

• 11 are hardcoded to specific plugin names (the rest use dynamic loops via e_*_list prefs, which is the intended pattern and actually works well)
• 21 have no file_exists or class_exists guard, so deleting the plugin causes a fatal error
• Core SQL (core_sql.php) defines 5 tables that belong to plugins: news, news_category, submitnews, comments, rate
• Core SitePrefs store 25+ preferences that belong to plugins (comments alone has 10)

The good news: e107 already has the right infrastructure for clean separation. The e_* addon system (e_comment.php, e_event.php, e_cron.php, e_header.php etc.) is exactly how plugins should hook into core. 54 of those 65 includes use it correctly. It's the other 11 that are the problem.

TYPE A: separated but with dangling wires

You said "if you delete this type of plugin files and something is broken, it is a bug." Agreed. And there are bugs.

Forum has its own tables and e_url.php, but core still has 8+ hard references:

• userposts.php:130 and top.php:57: Unguarded require_once of forum_class.php
• user_shortcodes.php:76,154: Direct queries against forum_thread/forum_post tables
• e_file_inspector.php:39-44: Six forum files hardcoded in the integrity checker

Poll: comment.php:476 does a bare require(e_PLUGIN."poll/poll_menu.php") with no guard.

Banner: banner.php:13 does require_once(e_PLUGIN."banner/banner.php") unguarded.

TYPE B: entangled with core

News is the deepest:

• Core SQL defines news, news_category, and submitnews tables
• e107_admin/newspost.php is a dedicated admin page in core, not in the plugin
• frontpage.php:352: 'news.php' is the hardcoded fallback frontpage
• e107_core/url/news/url.php has its own news URL handler alongside the plugin's e_url.php
• eurl.php:506-516: Special-case toggle between core and plugin URL modes for news and gallery

Social runs deeper than a single @include_once:

• user_handler.php:1164: @include_once of social/includes/social_login_config.php (the e_userProvider class property-types against social_login_config)
• xup.php:31 and :68: Two unguarded require_once calls that will fatal if social is missing
• sitedown_shortcodes.php:52: Core sitedown template references social/css/fontello.css

TYPE C: core code that should be plugin code

Comments is the hardest case:

• comments table is in core SQL, not in a plugin install
• comment_class.php lives in e107_handlers/ as a core handler
• boot.php:290: Admin purge cascade requires the comment handler; if it's missing, admin breaks
• 10 core prefs (comments_disabled, nested_comments, comments_sort, anon_post, comments_engine, comments_icon, allowCommentEdit, comments_emoticons, comments_moderate, comments_class) stored in SitePrefs

Ratings: same pattern. rate table in core SQL, rate_class.php in handlers.

Navigation: you pointed this out already. sitelinks_class.php:117 even has a hardcoded require_once(e_PLUGIN . 'ypslide_menu/ypslide_menu.php') for one specific slider plugin.

The URL system

You said this is "the worst" and I'd back that. Core has URL handlers in e107_core/url/ for news, page, search, system, and user. Plugins register their own via e_url.php. But eurl.php:639 explicitly hides forum, faqs, and pm from the URL admin because they "use the new system." Three generations of URL handling coexist.

Practical order for decoupling

To your first question: "removable" as in separate repos or as in deletable from an installation? I think the answer is the second one first. If deleting files can't break core, moving to separate repos becomes safe later.

If this gets tackled step by step:

1. Add guards to the 21 unguarded includes. Quick wins. Won't fix the coupling, but stops fatal errors when a plugin is absent.
2. Move plugin prefs to plugin prefs. The 10 comment prefs, the profanity prefs, the emoticon prefs. Doable with a fallback migration.
3. Move plugin tables out of core SQL. news, news_category, submitnews, comments, rate: move their CREATE TABLE statements to the plugin's own SQL install. Needs migration scripting but is mechanical.
4. Extract handlers. comment_class.php and rate_class.php from e107_handlers/ into their respective plugins. This is the hard one because other plugins call their APIs.
5. Root-level PHP files. banner.php, news.php, metaweblog.php, userposts.php, top.php are thin wrappers around plugin includes. The e_url.php system is meant to replace them.

All of it touches backwards compatibility. But you've already proven in your Lite fork that a slimmer core works in practice, and having the map makes it easier to chip away at the right places.

Full audit table (65 core-to-plugin includes)

All line references pinned to 0be9993.

Hardcoded plugin includes (11)

These reference a specific plugin by name. Removing that plugin breaks the include.

#	File	Line	Plugin	Guard	Notes
1	login.php	149	alt_auth	file_exists	Instantiates alt_login class
2	sitelinks_class.php	117	ypslide_menu	Constant check	Hardcoded slider menu
3	user_handler.php	1164	social	@ suppression	class_exists on next line
4	xup.php	31	social	None	Will fatal if social missing
5	xup.php	68	social	None	Will fatal if social missing
6	search.php (shortcode)	12	search_menu	None	Language file include
7	custom.php	19	login_menu	None	Language file include
8	custom.php	53	search_menu	None	Menu include
9	custom.php	98	clock_menu	is_dir	Clock menu include
10	bb_code.php	61	geshi	file_exists + pref	Syntax highlighting
11	admin_shortcodes.php	446	user	None	Language file include

Root-level PHP files (thin plugin wrappers, 8)

These files exist solely to require a plugin and serve as legacy URL entry points.

#	File	Line	Plugin	Guard
12	banner.php	13	banner	None
13	comment.php	476	poll	None
14	news.php	23	news	None
15	userposts.php	130	forum	None
16	top.php	57	forum	None
17	top.php	156	forum	None
18	metaweblog.php	23	metaweblog	None
19	email.php	131	Dynamic	file_exists

Dynamic plugin includes via e_* addon system (36)

These iterate plugin preference lists and load plugin-provided hooks. This is the correct pattern, but still represents a core-to-plugin interface.

#	File	Line	Addon type	Guard
20	notify_class.php	65	e_notify	varset
21	notify_class.php	519	e_notify	is_readable
22	ren_help.php	76	e_bb	is_readable
23	shortcode_handler.php	627	shortcode_config	Code check
24	comment_class.php	1453	e_comment	None
25	sitelinks_class.php	70	e_sitelink	file_exists
26	sitelinks_class.php	1865	e_sitelink	Include check
27	mailout_admin_class.php	601	e_mailout	is_readable (exit)
28	cron_class.php	1208	e_cron	Path check
29	menu_class.php	730	Menu PHP	@ suppression
30	emailprint_class.php	64	e_emailprint	Filename check
31	e107_class.php	1391	e_pref	is_readable
32	e107_class.php	3029	e_url	is_readable
33	e107_class.php	3110	e_url	is_readable
34	plugin_class.php	1054	plugin.php	ob_start block
35	plugin_class.php	2803	search_comments	vartrue
36	plugin_class.php	2857	e_notify	vartrue
37	plugin_class.php	2870	e_notify	vartrue
38	plugin_class.php	4870	plugin.php	None
39	plugin_class.php	5424	plugin.php	ob_start block
40	event_class.php	362	e_event	is_readable
41	bbcode_handler.php	660	e_bb	is_readable
42	e_parse_class.php	6011	Hook PHP	is_readable
43	e_parse_class.php	6038	e_tohtml	is_readable
44	class2.php	739	module.php	is_readable
45	class2.php	759	e_module	is_readable
46	print.php	70	e_emailprint	file_exists
47	search.php (admin)	64	search_comments	is_readable
48	search.php (admin)	427	e_search	is_readable
49	cron.php	451	e_cron	Else clause
50	admin_log.php	45-46	Language	None
51	links.php	335	e_linkgen	is_readable
52	header.php	223	e_header	None
53	header.php	341	e_meta	is_readable
54	frontpage.php	59	e_frontpage	is_readable
55	notify.php	154	e_notify	is_readable
56	plugin.php (admin)	658	plugin.php	None
57	plugin.php (admin)	880	_setup.php	is_readable
58	header_default.php	185	e_header	None
59	admin_shortcodes.php	331	plugin.php	is_readable
60	admin_shortcodes.php	579	e_latest	is_readable
61	admin_shortcodes.php	1250	plugin.php	is_readable
62	admin_shortcodes.php	1320	admin_info	None
63	admin_shortcodes.php	1578	e_status	is_readable
64	user_shortcodes.php	992	e_userprofile	is_readable
65	sitedown_shortcodes.php	52	social (CSS)	None

Core shortcodes with plugin database queries

File	Line	Plugin	Query
user_shortcodes.php	45-47	chatbox_menu	count("chatbox")
user_shortcodes.php	76	forum	count("forum_thread")
user_shortcodes.php	98	forum	retrieve('user_extended', 'user_plugin_forum_posts', ...)
user_shortcodes.php	110	download	count("download_requests", ...)
user_shortcodes.php	154	forum	count("forum_post")
user_shortcodes.php	458	forum	count("forum_thread", ..., "thread_user=")
admin_shortcodes.php	1042-1070	pm	isInstalled('pm') + admin URL refs

Plugin-serving tables in core SQL

Table	Belongs to	Notes
news	news plugin	45 columns, full content schema
news_category	news plugin	Category hierarchy
submitnews	news plugin	User submission queue
comments	comment system	Generic, multi-content-type
rate	rating system	Generic, multi-content-type

Plugin prefs stored in core SitePrefs

Pref key	Belongs to
comments_disabled	Comment system
anon_post	Comment system
comments_icon	Comment system
nested_comments	Comment system
allowCommentEdit	Comment system
comments_emoticons	Comment system
comments_moderate	Comment system
comments_sort	Comment system
comments_class	Comment system
comments_engine	Comment system
profanity_filter	Profanity system
profanity_replace	Profanity system
profanity_words	Profanity system
smiley_activate	Emoticon system
forumdate	Forum plugin

[Deltik]

(For future reference, talk about decoupling plugins was in #5672)

[e107help[bot]]

@Deltik asked (over on #5691) whether all plugin localizations can move into the plugin, even for core plugins. That's the language-layer companion to the audit above, so here it is. Short version: clean for most, with two real blockers that turn out to be code-coupling rather than localization. Three buckets.

1. Already clean (most of the 38 plugins)

The infrastructure exists and is already the norm: e107::plugLan() plus includeLan / coreLan / lan(), used across ~45 plugin files. Plugins whose code already lives in the plugin own their LAN today. Nothing to move, no new mechanism needed.

2. Admin-log strings (systematic, mechanism exists, one BC gotcha)

Core lan_log_messages.php still holds ~40 plugin log strings: LAN_AL_DOWNL_* (download), LAN_AL_BANNER_*, LAN_AL_NEWS_*, LAN_AL_COMMENT_*, and LAN_AL_MISC_* (login_menu/comment_menu/online). The move path already works: a plugin ships languages/English_log.php, auto-registered into lan_log_list on install (plugin_class.php:3908), loaded at display (admin_log.php:45). Only 5 plugins ship one today (download, pm, alt_auth, gsitemap, linkwords).

• The gotcha is exactly the bug in [Bug]: language conversion error ? #5691: you must move, not duplicate. Core loads first and includeLanArray is first-wins, so a leftover core copy shadows the plugin's values.
• Not-fully-clean wrinkle: LAN_AL_MISC_* is shared by three plugins (login_menu MISC_03, comment_menu MISC_04, online MISC_02). The event code is what's stored in the admin_log table, so you relocate the string per plugin but keep the codes, otherwise you're migrating historical rows.

3. Strings that can't move until the code moves (the real blockers)

LAN can't lead the code:

• contact: no plugin languages/ dir at all; strings in core lan_contact.php; even the entry point contact.php sits in core root. The whole plugin is half-core.
• news: core lan_news.php is loaded by both the plugin (news.php:56, literally marked // Temporary) and the core admin page e107_admin/newspost.php. Deepest TYPE-B from the audit above.
• page / online / user: partially split (strings in both places); consolidation, no hard blocker.

What it would take for the blocked ones

Decouple the code first: move contact.php / newspost.php and friends into their plugins, per @Jimmi08's TYPE-B work. Moving the strings ahead of the code just inverts the dependency (core referencing plugin LAN), which is worse than today.

So: mechanical and safe for the self-contained plugins and for the admin-log strings (with the move-don't-duplicate rule), gated on code-decoupling for contact and news. No new infrastructure needed.

The download plugin (#5691) is the first worked example of bucket 2: I'm putting up a PR that moves its log strings to the plugin and drops the shadowing core copy.