[#14958] - [j4] Default custom_data and system_data to an empty string
- Closed
- 28 Mar 2017
- Medium
- Build: 4.0-dev
- # 14958
- Diff
- Digital-Peak:j4/fix/discovery
User tests: Successful: Unsuccessful:
Summary of Changes
Discovery is broken on Joomla 4 becaus of an SQl error that custom_data and system_data don't have to be null.
Honestly I don't know what are this columns for, but they must be initialized with some data as the installer defines them as not nullable. Either way we always write some data into the coumns for an extension or we allow null values. Somebody a clue what these columns are for?
Testing Instructions
- Install Joomla with the 4.0-dev branch.
- Download the override plugin from https://github.com/Digital-Peak-Incubator/plg_system_override/archive/master.zip
- Extract it to plugins/system
- In the back end got to Extensions -> Manage -> Discover
- Click on the Discover button on the top
Expected result
The override plugin should appear in the list.
Actual result
The list is empty.
Documentation Changes Required
None as it is a bug.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries |
I can not reproduce test instruction.
I did:
- Install joomla 4.0-dev (on git) with test data.
- Extract files from above plugin into
plugin/system/overridefolder (I changed name of folder fromplg_system_override-mastertooverride) - Discover
- Install the plugin success
If you had installed an older J4 version with later updated files then Extensions -> Database -> Fix should resolve the problem.
If we do revert it we should do everything in one big PR. So I'm going to close this. If someone wants to do the all in one feel free. But honestly if we are using a database column on a major version upgrade once every 5 years then tbh I think we can do better than that anyhow
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-03-28 10:51:34 |
| Closed_By | ⇒ | wilsonge | |
| Labels |
Added:
?
|
||
But honestly if we are using a database column on a major version upgrade once every 5 years then tbh I think we can do better than that anyhow
Maybe that's true for the system_data field. But what is your arhument when some extension (eg a plugin) uses the custom_data field? Ever since the extension table was created, both fields were present and especially the custom_data one could be used by extensions to store some simple stuff in it without creating own tables (at least I suppose that's the intent of this field).
I don't get why you want to remove those fields. They don't hurt at all and may be helpful for 3rd parties and even core in situational cases.
This should have already been solved with #14750 ?