horst Posted May 26, 2014 Posted May 26, 2014 (edited) If it's going to be a core module maybe you could even add a "modules" section and show if there are updates for your installed modules. Maybe even with a link to the update if there is one. Shouldn't be that hard to write because module updates are included in the core since 2.3 or 2.4. This is already ready with Somas Modules Manager. It can check by a selectable period (lazy cron I think) and email you only if there are updates for you. (named: Modules Manager Notification) Edited May 26, 2014 by horst
Nico Knoll Posted May 26, 2014 Posted May 26, 2014 But as far as I know Soma's Module Manager is not part of the core. And old modules are often a potential security risk so I think it would fit in this Diagnostic page quite well. (I think it's not a huge problem to monitor module status on different places even if there are some overlappings).
Nico Knoll Posted May 26, 2014 Posted May 26, 2014 @netcarver: Just another question: Why do you added "..." everywhere in this module?
netcarver Posted May 26, 2014 Author Posted May 26, 2014 @Nico, I made the collection of diagnostics hookable to allow extension of the core collection and eventually allow all the collection to be outsourced. I already have a proof-of-concept "ExamineDatabase" diagnostic collection module (as yet unpublished) that hooks into this nicely. There's no reason why ProcessDiagnostics can't be extended by Soma's excellent Module Manager or even a "ExamineModules" diagnostic provider. Here's what I plan on adding to ProcessDiagnostics... Verbosity control (Low, Medium & High settings). Low => Only failures are listed, Medium shows failures and warnings while high shows everything. An "Email Report To" button allowing the generated report to be sent to your friendly sysops person. Storage of diagnostic results and detection of diffs between runs. Automatic squawking via a channel (SMS?, Email (yes!), Twitter?) when changes are detected. Move all diagnostic collection out into dedicated "Examine" modules, leaving ProcessDiagnostics to focus on aggregation, storage, diff detection and communication of the results. I hope that makes sense. Let me know if you think of other things to add to ProcessDiagnostics and feel free to work on "ExamineXyz" modules that hook into it. 4
Nico Knoll Posted May 26, 2014 Posted May 26, 2014 I'm not sure if hooking is really the best way. Of course it's well for extended data. But module updates should be always visible - not only if module manager is installed. I take a look and may steal something from soma's code to add this. As Proove-of-concept 1
Nico Knoll Posted May 26, 2014 Posted May 26, 2014 --- Well maybe it's better if Soma's module would hook into your's. It already includes all the needed functions.
netcarver Posted May 26, 2014 Author Posted May 26, 2014 I've pulled horst's image handling diagnostics out into the first external diagnostics collector (ExamineImagehandling.module) for this suite. If anyone else wants to have a go at extending ProcessDiagnostics, you now have an example collector to use as a base. You can also play with the verbosity level by changing ProcessDiagnostics.module line 51 to either "MEDIUM_VERBOSITY" or "LOW_VERBOSITY" - UI control will come. Example medium verbosity output: And the same listing but with low verbosity: 1
Nico Knoll Posted May 26, 2014 Posted May 26, 2014 Should I do module update stuff as a separate module or should it be part of the core? At least here is the code: /** * Returns a diagnostic array about installed modules and looks for updates */ protected function getModulesDiagnostics() { $defaultServiceUrl = 'http://modules.processwire.com/export-json/'; $defaultServiceKey = 'pw231'; $modulesRemoteVersions = (array)$this->session->get('ModulesRemoteVersions'); foreach($this->modules as $module) { $moduleInfo = wire('modules')->getModuleInfo($module->className()); $localVersion = $this->formatVersion($moduleInfo['version']); // check if core module $core = false; $pathParts = explode('/', str_replace($this->config->urls->root, '', $this->config->urls->{$module->className()}), 2); if($pathParts[0] == 'wire') { $core = true; } // only show installes /site/ modules if($core == false) { // if remote ersion is in session use this one otherwise load remote version from ... remote. if(!in_array($module->className(), array_keys($modulesRemoteVersions))) { $url = trim($defaultServiceUrl, '/') . "/".$module->className()."/?apikey=" . $defaultServiceKey; $http = new WireHttp(); $data = json_decode($http->get($url)); if($data->status != 'error') { $remoteVersion = $this->formatVersion($data->module_version); $modulesRemoteVersions[$module->className()] = $remoteVersion; } else { $modulesRemoteVersions[$module->className()] = $localVersion; } } $updatable = ($modulesRemoteVersions[$module->className()] > $localVersion); $updateUrl = $this->config->urls->admin.'module/?update='.$module->className(); $results[] = array( 'title' => $moduleInfo['title'].' ('.$module->className().')', 'value' => $updatable ? $this->_('Update available') : $this->_('Up to date'), 'status' => $updatable ? self::$warn : self::$ok, 'action' => $updatable ? sprintf($this->_('There is a new version available. <a href="%s">Click here to go to update page.</a>'), $updateUrl) : '', ); } } $this->session->set('ModulesRemoteVersions', $modulesRemoteVersions); return $results; } protected function formatVersion($version) { return preg_replace('/(\d)(?=\d)/', '$1.', str_pad( (string)$version, 3, '0', STR_PAD_LEFT)); } 3
netcarver Posted May 26, 2014 Author Posted May 26, 2014 @Nico, Great! Added to the repo as ExamineModules.module. Thank you!
Nico Knoll Posted May 26, 2014 Posted May 26, 2014 I made a pull request. I think my changes are quite good
Manfred62 Posted May 26, 2014 Posted May 26, 2014 ProcessDiagnostics must be in the core! In line 264 'action' => $ht_ok && !$ht_write ? '' : $this->_('.htaccess must exist, must be readable, should <strong>not</strong> be writable.'), //replace <strong> with ** 'action' => $ht_ok && !$ht_write ? '' : $this->_('.htaccess must exist, must be readable, should **not** be writable.'), the double asterisk are for bold text in translation-files. But in this case it's not working?? Maybe one of the pro's can check this? Example in ProcessTemplate.module, line 922, 923 BTW: german translations nearly done... 3
Nico Knoll Posted May 26, 2014 Posted May 26, 2014 I would wrap this translating thing with html_entity_decode(). Should be possible to use normal html after that. 1
netcarver Posted May 26, 2014 Author Posted May 26, 2014 @Nico, Thank you. I've made a few tiny adjustments and just merged your PR. Funnily enough I started out using MarkupAdminDataTable for this but couldn't get the nth-child() CSS working to set the widths so went custom - what an idiot.
netcarver Posted May 26, 2014 Author Posted May 26, 2014 Fancy doing the checks in the background via ajax Nico? Initial version check can take a long time and I'm wondering if users are going to think this has "broken" their admin UI. 1
Nico Knoll Posted May 26, 2014 Posted May 26, 2014 I'll take a look. There has to be an Ajax function somewhere in PW... 1
Nico Knoll Posted May 26, 2014 Posted May 26, 2014 Ajax is working. Deactivated "autoload" stuff (don't need it). New pull request is on it's way 4
netcarver Posted May 27, 2014 Author Posted May 27, 2014 @Nico, Nice blog post Thanks for the idea re the extension module names. 'ExamineXyz' was somewhat weak and disconnected from the 'diagnostics' idea so I have renamed them from 'ExamineThingy' -> 'DiagnoseThingy'. I think this re-establishes the link between the collection modules and the master 'ProcessDiagnostics' module. @all I hope this marks the end of naming instability for this little project and I've bumped the version slightly to reflect it and updated the opening post to reflect the current state of play. 2
Nico Knoll Posted May 27, 2014 Posted May 27, 2014 Another question: What system do you follow for version numbers?
netcarver Posted May 27, 2014 Author Posted May 27, 2014 I'm not fixated by any particular scheme. What had you in mind?
Nico Knoll Posted May 27, 2014 Posted May 27, 2014 I saw that the current version is 20 (or 0.2.0) and some updates before it was 4 (0.0.4) and I thought you may have some kind of system or logical pattern how to choose the version
Soma Posted May 27, 2014 Posted May 27, 2014 I don't think all those module should be Process modules, only the ProcessDiagnostics. But I found many choose Process for every module they make. IMO they're server a purpose and should be used for custom admin pages. Also I'm not sure what the module diagnostics does and what is useful for and if it really belongs here. ModulesManager and core modules are dedicated for that task and this way we scatter it in multiple places instead of having it in one place. 3
Nico Knoll Posted May 27, 2014 Posted May 27, 2014 @soma: I think you're right with not choosing "Process" for all of the submodules. Maybe "Module" would be more appropriated. The module diagnostic shows the current status of the modules (checks if there are new versions available).
horst Posted May 27, 2014 Posted May 27, 2014 Also I'm not sure what the module diagnostics does and what is useful for and if it really belongs here. ModulesManager and core modules are dedicated for that task and this way we scatter it in multiple places instead of having it in one place. I am with Soma here, modules stuff belongs into the Modules Manager. Redundancy is not good. ( https://processwire.com/talk/topic/6480-processdiagnostics/page-2#entry63539 )
Nico Knoll Posted May 27, 2014 Posted May 27, 2014 Maybe Soma's module could hook into processdiagnotics. Then my module would become really redundant. 1
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now