cash wrote on 42020079-09-13

The larger story is that in Elgg 1.5 the core developers added a new security feature (the tokens for forms) and would write an error message to the log whenever the token was not passed. The idea being that developers/administrators would notice all these errors and fix their plugins.

Elgg 1.7 was released with the hard requirement that the forms have tokens. There was weeping and wailing from Elgg users because almost none of the plugins from community developers had implemented the security feature.

The whole point of the new deprecation notices is to slowly increase the pressure on the developers/administrators to update their plugins. In the first version after something is deprecated, the messages are sent to the log or as inline debug messages if the trace level is set to WARNING. In the second version after a deprecation, we start using system messages.

In this case, get_entities() was deprecated one and half years ago and plugin developers still have not updated their plugins.

I think the biggest problem is that the deprecation notice doesn't tell you what plugin is causing the problem.

How about:

1. First version gets logged like current
2. Second version gets system message for admins with more information
3. Third version gets system message for everyone
4. Fourth version the deprecated function is removed and the plugin crashes

trac user ismayil.khayredinov wrote on 42020145-10-09

I don't think it makes sense involved "everyone". I think it's admin's responsibility to keep the site and plugins up to date. When something crashes because of deprecation, it's his sole fault for ignoring 1 and 2. I don't think it is a good practice to system information and incompatibilities to site users...

Is there a possibility to scan the plugin for deprecated functions and handle it similar to manifest compatibility requirements? I think that way the admins will see the "risk" before enabling the plugin.

cash wrote on 42020313-01-22

That's fair - I think we've just been frustrated in the past by this. It will lead to posts like "I enabled xxx plugin and now my site is all white".

To support a scan function, we would have to keep a list of all functions ever disabled.

Maybe the best option is to only show these deprecation warnings to admin and have display_errors turned on for admins. That way they don't get a WSoD but a useful error message when they enable an old plugin.

We can also improve the plugin repository. We'll be releasing something that allows people to check for new versions of plugins. One advantage to that is that we'll know what plugins are being used with what versions of Elgg.

trac user ismayil.khayredinov wrote on 42020633-10-12

One things that might help is better front-end documentation of developer tools - we can't always assume that the admin knows what he/she is doing

cash wrote on 42022273-03-13

I'm interested in your thoughts on documentation of developer tools.

Meanwhile, I'm following your advice and only making the notices visual if an admin is logged in.

Milestone changed to Elgg 1.8.3 by cash on 42022273-03-13

trac user Cash Costello wrote on 42022278-01-28

Fixes #4278 deprecation notices ignore debug level but do respect whether the admin is logged in
Changeset: 05cfa91

trac user ismayil.khayredinov wrote on 42022306-08-07

I think adding non-technical explanation to each feature would help. Of course, developer tools are tech-savvy people, but it seems that many admins enable them nevertheless.

So, my thinking is add basic definitions and use cases, e.g. WARNING is ... Using this type of debuggin is helpful when ...
or
Wrapping views will create hidden html markup that will allow you to locate the view responsible for rendering a specific html code. Enabling this feature is helpful when you are unsure what view needs to be edited, if, for example, you need to add additional html markup.

trac user ismayil.khayredinov wrote on 42024903-12-19

One more thing that came to mind. One thing that Elgg lacks is the functionality to enable the development mode (e.g. Joomla-like Site is Offline). It seems there are hundreds of sites on the net that are based on Elgg but haven't really been worked upon. Perhaps it would be good to have a walled-garden like feature, where admins could hide the site from public and search engines until it's not complete. By default, the site should probably be in development mode after installation, and it has to be a conscious decision of the admin to make it live.

cash wrote on 42025147-08-03

1. I think adding documentation to the developers plugin is a good idea. I'm thinking that we can improve the README and then provide links to it from developer plugin's pages.
2. We do provide a walled garden option starting with 1.8. Should that come turned on by default? Should we provide an additional "site is offline" capability (I say yes to the second question.)

trac user Cash Costello wrote on 42050554-04-26

Fixes #4278 deprecation notices ignore debug level but do respect whether the admin is logged in
Changeset: 05cfa91

adayth wrote on 42052364-01-12

I updated my site to 1.8.3 and I'm annoyed by a lot of deprecation messages in middle of activity views, users views... so I can use my account

I know that deprecated plugins are a source of problems, but if I want to use them, I don't need to view this messages.

I think that we need an option to don't show deprecation to admins. Actually, I just replaced these lines in elgg_deprecated_notice:

- elgg_dump($msg, elgg_is_admin_logged_in(), 'WARNING');
+ elgg_log($msg, 'WARNING');