Great initiative!
I was hoping to remove the mootools modal for the options before decoupling it from the core. I guess I’ll have to make a PR to that repo then!

@dgt41 i hope i can prepare a final PR against the new repo. So i think the easiest would be to send a PR against this repo if my PR is merged into it? I will create a issue on that repo.

@zero-24 I had a PR #4563, which already got some tests etc, but I guess I can make a new one on the new repo. No need for issue.

Good initiative!

I installed your Joomla! version with the Sample data: testing.
When you login the first page you get, is a error page with this error:

 1146 Table 'joomla-cms-patch-13.c15is_messages_cfg' doesn't exist SQL=SELECT * FROM `c15is_messages_cfg` WHERE `user_id` = 101 AND `cfg_name` = 'auto_purge'

Looks like somewhere there is a query still seraching for the message table after login.
No father problems/com_message things found

Thanks @n9iels i will have a look into it.

@n9iels can you retest? This: zero-24@e9e1e9e should fix it

What makes you say new content notification will be deprecated in J4?
Object to removing that functionality.

I think I'd suggest the feature be in a plugin distributed with the com_messages component versus being coupled to a core plugin that won't be removed. Then that feature is deprecated in the core (as it's coupled to what should be a standalone extension) but available via a supported extension.

Object to calling something deprecated as of J4. That sounds if the core supported component messages won't make it to J4. If that is already decided, that should be communicated properly. Moving functionality is ok, it should be part of this exercise. Removing it from the core and adding it to the messages project in core supported.
Moving and deprecating are two different things!

So what do you call a feature that is moved out of core API to another location? By definition, if we're removing a feature from a class, then it's deprecated (even if it's just being moved to another location); support for a specific class and/or method API endpoint is scheduled for removal. Using my suggestion on JApplicationAdministrator::purgeMessages(), we'd deprecate the method call and move what it does to another location. This communicates that the API endpoint will no longer be supported in a future release but not necessarily that the feature is being fully removed.

Consider it not applying to pieces of code of the plugin. The purpose of deprecating is to warn other developers not to use those methods. That doesn't apply here. With the move on messages a new content plugin or any other technical solution should be provided to maintain the functionality.

Same applies to purgeMessages, its content should be changed to cater for the changes with messages component. The method should not be deprecated. It should start to provide the functionality depending on installation of messages and the possible replacement!

Because that is what moving these components to core supported means! Continue to use them or use an alternative. Part missing is what do I need to do to replace notification with something like uddeIM for example.

Personally, I think having our top level APIs bound to specific components or plugins is a bad idea. Just on a glance, I see hardcoded references to com_languages, com_messages, com_users, the language filter plugin, and the database session storage; this couples our application to these components and makes it more complex to use an alternative user management system or database storage engine, for example. Our top level APIs (such as the application classes) should be able to swap out implementation details (which is what the code in purgeMessages is, an implementation detail) with ease; if I want to use APC session management instead of my Joomla database, I should be able to.

In the case of purgeMessages, if we were to refactor it into a more abstract API that isn't bound to a specific extension or implementation, I'd love to see it; but in its current form with it being bound to only the messages component, it should be deprecated.

I think we actually agree on some parts of this, we're just looking at it from different perspectives.

Thanks @mbabker your comments are fixed. regarding JApplicationAdministrator::purgeMessages() I will implemet it via plugin into my PR against the new repo same for the mod_status code. Please let me some time to do it.

Hi zero-24,
I made the first test, but there are still the language files:
/language/en-GB/en-GB.com-messages.ini
/administrator/language/en-GB.com-messages.ini
/administrator/language/en-GB.com-messages.sys.ini
They have to be removed, too, and the test has to be repeated.
In the database were no tables installed.

system test für com_messages noch entfernen

As with weblinks the language files will not be removed

@jehacgn can you point me to the system tests? I can't find it.

Guys can we apply first #4563 and then go on with this? The only thing that will @zero-24 have to change is to NOT to remove this file: administrator/components/com_messages/layouts/toolbar/mysettings.php as that will be removed in the other PR. Thanks!

done @dgt41 2a5efed

system test für com_messages noch entfernen

Thanks @jehacgn just removed the test file zero-24@f0f3ea8

@Worti2 and @jehacgn can you retest the last changes? The language files still there as same for com_weblinks

Hi zero-24,
tested it and everything looks fine.
Greetings from the Möhnesee

Please notice this: #6352 (comment)

com_message is used for messaging e.g. if you have a new article.
https://github.com/joomla/joomla-cms/blob/staging/plugins/content/joomla/joomla.php#L68-94

So should we implement a other solution to implement it outside of com_messages or simple not remove messages?

@zero-24
off the top of my head, I'd just get rid of those lines in https://github.com/joomla/joomla-cms/blob/staging/plugins/content/joomla/joomla.php#L68-94 and add an (optional) plugin acting on ContentAfterSave in the decoupled com_messages.

3rd party extension could implement similar solutions for different messaging systems.

Is this feasible?

Suggestions: the check should not only be for the component being installed, but also to be enabled.
something like

if (!JComponentHelper::getComponent('com_messages', true)->enabled)

Also, it seems that mod_status would need an onContentPrepareForm to not display the email_new_fe field when the component is not installed.

That is if we do not add a new specific plugin.
I wonder how B/C that would be.

Suggestions: the check should not only be for the component being installed, but also to be enabled.
something like if (!JComponentHelper::getComponent('com_messages', true)->enabled)

There is a helper method JComponentHelper::isEnabled('com_messages')

My mistake. forget it. deleting above comment.

@infograf768 @Bakual

There is a helper method JComponentHelper::isEnabled('com_messages')

That breaks B/C

The "is installed check" is allreay implementet. See: https://github.com/joomla/joomla-cms/pull/6352/files#diff-4bec224e62bf4c1a53784d49773e3841R38

But if we check that messages is enabled we break all sites that currently has disabled messages but use the notifications.

And this means a B/C break.

Install 3.4.3 --> Messaging on submiting a article works out of the box
Install 3.5.0 (or other version without messages) --> Messaging on submiting a article don't works.

How does messaging work when com_messages is disabled? I would call that a bug. Or do I miss something?

I'm fine however with keeping existing behavior for now.

Lets call it a hack ;)
https://github.com/joomla/joomla-cms/blob/staging/plugins/content/joomla/joomla.php#L68-94

Currently the plugin don't care if com_messages is enabled or not. It includes the files and send the messages out.

I'd call that a bug, not a hack

But if we change the way we handel that messages we break B/C anyway so this needs to wait for 4.0 but if the PLT decides to do this with 3.5 and disable the mail sending with com_messages this PR can be merged ;)

Honestly? It's a bug which should be fixed. And chances are low that somebody disabled com_messages. Especially since it's protected and can't be disabled without hacking the database

And chances are low that somebody disabled com_messages. Especially since it's protected and can't be disabled without hacking the database

Agree.

@zero-24
Also, please do not forget

Also, it seems that mod_status would need an onContentPrepareForm to not display the email_new_fe field when the component is not installed.

@infograf768

Also, it seems that mod_status would need an onContentPrepareForm to not display the email_new_fe field when the component is not installed.

I'm not sure how to do this?

@Bakual

Especially since it's protected and can't be disabled without hacking the database

Oh. I don't know. This way it can't be uninstalled and i think should not decoupled.

Personaly I think we should close here and dont decouple it with 3.5 and wait for 4.0 to decouple it. We have much more easy components to decouple. And have some issues on decoupeling (e.g. the SSL issue and the others that was show by the PLT). If we decouple this extension we break B/C and have one more extension that makes the same problems as weblinks.

If someone what to take the work I will leave my branch. But personaly i think we should wait with messages for 4.0 and first fixes the issues that was pointed out by the PLT.

@zero-24 This one imho would be fine to decouple. It is currently protected because there are issues if you uninstall it. Exactly those we discussed here.
There is no B/C with this PR and Weblinks has no issues beside the SSL one which isn't a weblinks issue.

For email_new_fe , I meant plugins/content/joomla/joomla.php
In mod_status we need to deal with show_messages

I understand what @infograf768 means. Those fields (options) should not be visible in the settings if the component is not installed and enabled.

@Bakual Do you have an idea how to do the checks? Maybe a new extra field for the check with the combination of "showon"?

showon would be to complicate. Just create a new custom field which extends from JFormFieldRadio where you add the check. If it fails, you could either show a message indicating com_messages is disabled/uninstalled, make the field readonly or you just hide the field completely. Just pick something that makes sense :)

Personaly I think we should close here and dont decouple it with 3.5 and wait for 4.0 to decouple it. We have much more easy components to decouple. And have some issues on decoupeling (e.g. the SSL issue and the others that was show by the PLT). If we decouple this extension we break B/C and have one more extension that makes the same problems as weblinks.

Could we just unprotected this component that I can remove it in 3.5?

Could we just unprotected this component that I can remove it in 3.5?

Yes we can. But i still don't think this is the best extension to start with ;)

And we change the behavior for all new installs that I recommend to do with Joomla 4.0 and not with 3.5. If we want to do it B/C we also need much "is installed" / "is enabled" checks.

And something very special (i don't know to implement) for mod_status as noted above by JM.

Feel free to fork: https://github.com/zero-24/joomla-cms/tree/patch-13

@zero-24
Bakual's proposal is indeed the simplest. We just have to add in the module and in the plugin a new field type and change in the xml to this new field type.
Somethng like this:

<?php
/**
 * @package     Joomla.Platform
 * @subpackage  Form
 *
 * @copyright   Copyright (C) 2005 - 2015 Open Source Matters, Inc. All rights reserved.
 * @license     GNU General Public License version 2 or later; see LICENSE
 */

defined('JPATH_PLATFORM') or die;

/**
 * Form Field class for the Joomla Platform.
 * Provides radio button inputs checking if com_messages is enabled
 *
 * @link   http://www.w3.org/TR/html-markup/command.radio.html#command.radio
 * @since  11.1
 */
class JFormFieldRadioMessages extends JFormFieldRadio
{
    /**
     * The form field type.
     *
     * @var    string
     * @since  11.1
     */
    protected $type = 'RadioMessages';

    /**
     * Method to get the radio button field input markup.
     *
     * @return  string  The field input markup.
     *
     * @since   11.1
     */
    protected function getInput()
    {
        if (JComponentHelper::isEnabled('com_messages'))
        {
            return parent::getInput();
        }
        else
        {
            return false;
        }
    }

    /**
     * Method to get the field label markup.
     *
     * @return  string  The field label markup.
     *
     * @since   3.4
     */
    protected function getLabel()
    {
        if (JComponentHelper::isEnabled('com_messages'))
        {
            return parent::getLabel();
        }
        else
        {
            return false;
        }
    }
}