Comments

• 

  Plugins bot

  Mon, 29 Feb 2016, 5:46 PM

  Prechecker results: 681 errors/112 warnings
  http://integration.moodle.org/job/Precheck%20remote%20branch/21457/artifact/work/smurf.html
• 

  Dan Marsden

  Wed, 16 Mar 2016, 7:32 AM

  Hi Igor, thanks for providing an updated version - would you mind adding travis-ci support to your plugin? This runs all the automated testing tools and codechecker processes on your code - more info here: https://moodle.org/mod/forum/discuss.php?d=323384 You don't need to fix all the problems it finds (I tend to ignore a lot of the php mess detector violations in my own plugins) but seeing these reports can help a lot with the plugin review process.
• 

  Igor Sazonov

  Wed, 16 Mar 2016, 3:33 PM

  Hi Dan! Thanks for your issue! i've added a travis support: https://travis-ci.org/tigusigalpa/moodle-block_wpfeed. As you tell me, i see php errors but 100% of the ones are should be ignoring (i think so) because i see some trends: no underscores at variables names, but i like it and its not a coding error; no whitespaces at end of line - for some lines its just for pretty code looking; a lot of characters for some lines - hmm. At the code i added a lot of comments for each function and tried to make code pretty view, also i tried to make a good code security, but these messages just looking about code string styles, i think you understand what i mean)
• 

  Dan Marsden

  Thu, 17 Mar 2016, 11:15 AM

  It would be good if you made an effort to resolve some of those errors - particularly the boilerplate/GPL statement that should appear at the top of your PHP files, also you should be aware that some Moodle Partners will not approve your plugin for installation unless it passes many of those tests. (warnings/violations are usually ok but Errors/Failures would be nice to fix.)
• 

  Igor Sazonov

  Thu, 17 Mar 2016, 6:04 PM

  Hi, Dan! You're right, coding style is coding style, agree. So, i fixed a most if the ones (>90%): https://travis-ci.org/tigusigalpa/moodle-block_wpfeed But at the dev mode i need to use print_r() function to show response as a string for developers, var_dump() can't provide string return, but travis says "The use of function print_r() is forbidden". Hope this variant is good)
• 

  Dan Marsden

  Fri, 18 Mar 2016, 3:23 AM

  Great! - print_r() and Moodles print_object() are both ugly ways to display the debug info - it's unlikely to block approval in the db here by leaving it in but here's a function I use in one of my plugins that is basically a "pretty" version of print_r which I'm sure I borrowed from somewhere else:
  https://github.com/danmarsden/moodle-plagiarism_urkund/blob/600144acbadd6ed3c083f009e4a0c33dd3354eef/lib.php#L1632
• 

  Igor Sazonov

  Fri, 18 Mar 2016, 4:23 AM

  Dan, thanks for your solution! its good solution and i added the one with your copyrights
• 

  Igor Sazonov

  Tue, 29 Mar 2016, 8:38 PM

  Dan, hi! so i did all fixes and improvements, but still not approved
• 

  Dan Marsden

  Wed, 30 Mar 2016, 3:37 AM

  The plugin guardians team is quite busy at the moment on a number of tasks including GSOC/Moodle 3.1 freeze/Easter break - hopefully we should get back to this very soon - thanks for your patience so far!
• 

  David Mudrák

  Wed, 6 Apr 2016, 9:43 PM

  Thanks Igor for sharing the block with the community. And thanks Dan for the peer-review. I like the idea of the block and I think there are valid cases where it can be useful. I must admit I was very surprised that this block does not allow for per-instance configuration (as reported by Dan in the issue #5). As a result, if a block is configured in one course with course-specific contents, it can't be then used anywhere else for different feed. I see this as a big limitation in the usability of the block. Please see how other blocks work with block_base::instance_allow_multiple() to allow per-instance configuration.

  Another consequence is that teachers can't really do much with the block, it heavily relies on the site admin. For many sites, this is not natural workflow at all.

  As Dan already commented in the issue #3, the config.ini files really look and feel like aliens in the Moodle world. Why not to follow how other plugins do these things. Consistent user experience is important.

  I am going to mark this as needing more work to encourage you to rethink the current design of the block features and turn it into actually usable and useful feed reader for Wordpress sites.

• 

  Igor Sazonov

  Fri, 22 Apr 2016, 4:47 PM

  Hi, David! Very sorry for delay from me. Thanks for issues and description! i've done the ones with config.ini removal in v1.1.1
• 

  David Mudrák

  Thu, 26 May 2016, 4:41 AM

  Hi Igor. Thanks for sorting out the config.ini issue. Please note that, strictly speaking, the added constants with the B_WPFEED_ prefix violate the naming policy described at https://docs.moodle.org/dev/Plugin_contribution_checklist#Namespace_collisions

  As I can see, the block still does not support per-instance configuration. Let me mention again that this significantly limits the block's usefulness in my opinion. Pity.

  I am going to approve the plugin to give you an opportunity to gather feedback from wider community. Good luck with the maintenance and further development of the block. You are cleared to land, welcome to the Plugins directory!

• 

  Michael Hughes

  Thu, 4 Aug 2016, 6:07 PM

  Hi, we have a request to show a feed from a 'private' wordpress site (using CampusPress). Does anyone know if it is possible with this plugin (or another) to only show a feed to a user in Moodle who is also a user on the blog? It's my understanding that RSS feed will only be delivered from a private blog on CampusPress if a user is authenticated - would this plugin allow that, to authenticate the user? Cheers for help.
• 

  Rajan Sharma

  Thu, 3 Jan 2019, 6:23 PM

  Thanks For this Amazing Plugin. You can visit my website https://phonesremark.com/best-wallpaper-apps-for-android/