Code Analyzer v1.0.1

Release Notes

  • Fixed static methods false positive detection
  • Removed max execution time limit
  •  
    Fatal error: Undefined class constant 'SKIP_DOTS' in ........../www/root/mod/code_review/classes/code_review.php on line 42

  • What php version do you have?

  • It's definitely PHP versioin problem (iterator implementatioin changed since 5.2). I'll try to fix it. In the meantime note that any 5.3.x version should work fine.

  • @Michele I just noticed your reply.

    Note that problems are not immediate errors. If your site works, that's great, but you need to address these problems if you wish to upgrade to Elgg 1.9 at some point.

  • Most of these problems should be just functions replaced by different version. Most of changes should be doable using regular expressions and actually I'm thinking about automating this task.

  • @Michele: why not tell the developers of the reported plugins about the deprecation issues? The Code analyzer will give you the info about the files that use deprecated functions. You could make a list of the plugins that might need to be upgraded and then comment on the corresponding plugin pages referring to the Code analyzer plugin.

    If a function is used that has been deprecated in Elgg 1.8, the plugin should continue to work on Elgg 1.9 with these functions. Only on Elgg 1.10 it will no longer work. Though I have to say "should continue to work" and not "will definitely work". I've only tested out a few of my plugins on Elgg 1.9 so far. Unfortunately, it's not necessarily due to deprecated functions that a plugin will not work without updates on Elgg 1.9. Some more complex modifications might be necessary (e,g, Tidypics) or Elgg 1.9 might silently break backward compatibility. The break of backward compatibility might be unintended though, so it surely is helpful to already start testing existing plugins on Elgg 1.9 and report possible issues with broken backward compatibilty in Elgg core on github.

  • Very useful plugin. I didn't know there was something like this here... thanks a lot

  • Simplest case is to write RegExps that make renames in case of basic renames, or rename + parameters rewrite in case of more complex ones. Most tricky is to write it in a way that won't modify code in not intended places. Ie. renaming core_function to elgg_core_function could hit already correct syntax and make elgg_elgg_core_function. You get the idea.

    Trick is to write RegExps that will catch only intended places. In this example doing preg_replace from [^_a-zA-Z0-9])core_function([^_a-zA-Z0-9] to $1elgg_core_function$2 is quite safe.

    I'm attempting to introduce this automatic rewrites, so if you have some old plugins on community that could get upgraded, paste me links to them here. I'll try to use them as reference point when coding fixes.

  • I'm moving slowly towards new version. I already have code to fix basic renames in safer way than regular expressions, but more complex ones require more work to be made safely. I'm also introducing unit tests as it started to be easier to miss a bug.

    I've also removed reporting of deprecated functions called from the deprecated ones themselves (reported from the core).

    I wonder about user interface that would be useful? Nearest version will probably have checkbox "fix what you can", but it might make sense to let user choose what to replace and what not to. Thoughts?

  • @Pawel: please make the fixing of deprecated issues an option. Your plugin is great to find any usages of deprecated function in plugin when working on upgrading plugins (I'm using it already on Elgg 1.9 to verify my work) but at least I prefer to update the code on my own. A "Report only" run could still display the "How the code would need to be changed" info within the list of found deprecated functions (maybe as an popup?).

    Sidenote: getting the plugin to work on Elgg 1.9 is not too difficult. The main modification necessary results from the  elgg_get_plugin_ids_in_dir() no longer available. I simply added this function as code_review_get_plugin_ids_in_dir() within the plugin itself. This should also be BC to Elgg 1.8.

  • Option to analyze code without making modifications will always be there.

    I'm just wondering about the shape of this optional modification. Making one "fix as you go" flag is easier than finding problems, asking user what to fix and fixing while checking if noone was messing with the files in the meantime.

    elgg_get_plugin_ids_in_dir problem is fixed in current master. I'm testing it on 1.9 installs, so I'd be rather worried about me missing problems in Elgg 1.8 ;-)

    Popups are nice idea. I've added similar solution with summary of all deprecated functions with data extrected from the comments + info about possible fix if implemented. They're very basic though.

    Feel free to check Github version https://github.com/Srokap/code_review. I keep it stable and safe.

  • As long as the option to analyze the code without making any modifications stays there I think the changes that you think are safe to be done could be applied all at once automatically to keep the analyzer plugin simple. Afterwards you would most likely check out the differences for example with a diff tool anyway (if you are a developer of some kind). If a user without any experience in coding uses this plugin it might not help much to offer a step-by-step run with confirming every single modification. In this case it's most likely rather a trial and error approach anyway: either the plugin will work afterwards on the new Elgg version or it still won't work due to more complicated changes necessary that are beyong the scope of the analyzer plugin.

Paweł Sroka

Former Core Elgg team member, freelance developer.

Stats

  • Category: Tools
  • License: Expat (MIT) License
  • Updated: 2016-9-25
  • Downloads: 2302
  • Recommendations: 29

Other Projects

View Paweł Sroka's plugins