netcarver

I had one of these about a week ago as I was working on the ProcessDiagnostics module. I managed to inadvertently delete just the first line ("<?php") of index.php from the root directory and save the file. Apache started serving the index.php file as plain text - made me think that I'd messed up my apache config or .htaccess but it turned out to be my fat fingered deletion of a line on a file I shouldn't even have been editing. Dumb.

@horst You read my mind. I'm out until tomorrow evening but that happens to be next on my to-do-list for DiagnoseDatabase. @Martijn Thank you! It's really nice to have input from Nico, horst and Manfred62. Hope it is useful to folks!

@Nico, thumbs up, works now. Merged.

Just pushed up some improvements to the DiagnoseDatabase module. It now takes more time poking around with character sets, collations and table information. Here's a couple of screenshots... Hope these might eventually help someone out.

Note to self: Never, I said never, accidentily delete the first line ("<?php") of PW's index.php file and save it! Punishment: On next trip to post office collect, fill out and submit form id10t. In triplicate.

@horst Sorry about that. Just added it to ProcessDiagnostics. Can you let me know if this version fixes it for you? Hmm, well, I messed up something on my server - looks like Apache2 is serving php files as plain text now

Until recently, there has been a limit to the number of pages with images that PW can handle due to the OS per-directory file limit. However, the current development branch has changes in it that removes this previous limitation and effectively allows you to work to the full capacity of the file system. Previous limit was around 32,000 images on ext3 filesystems (if memory serves) but the dev changes blow that out of the water. Hundreds of thousands of images should now be possible but I have not verified this yet. With regard to pages, MySQL is able to handle millions of rows in tables, so I think you should be fine as long as the queries don't try to pull a lot of rows (pagination is your friend) with a lot of fields in each row. Edited to add: Beaten by diogo - again.

Welcome joer80, If you want to look at the query log on the admin side, just turn on debug mode by editing the /site/config.php file and changing $config->debug = false; to $config->debug = true; and saving the file. After that you get a load of debug information at the bottom of every admin page and it includes a list of the queries. With regard to query count: MySQL has a pretty good query cache so just going by the query count might not show the whole picture with regard to where something might be bottlenecked. When accessing the DB and running my own queries directly from modules I've never had to open a connection so either PW does it for you behind the scenes or you get to re-use what it already has open (I'm guessing the later but I haven't stepped through the code to confirm.) Here's an example query from a module I'm working on now... $t = $this->db->query("SHOW CREATE TABLE `$table`"); But you can just do... $t = $db->query("SHOW CREATE TABLE `$table`"); ...from a template file. More details.

@soma Thanks for the catch. Actually, that was me being a bit too liberal with copy-and-paste and remember this was only a proof-of-concept 2 days ago I'll redefine the Diagnostic providers so they all 'extend Wire implement Module' rather than having them be process modules. Having said that, I'll keep Nico's module extending 'Process' as it needs the js and css loading provided by the Process::init() method that I don't want to have to duplicate. I don't think any other diagnostic provider needs this special treatment. @apeisa Yes, there is a naming convention for the diagnostic provider modules. I'll update the opening post and add it to the repo's readme file soon but it goes like this... Firstly: Have your module hook the ProcessDiagnostics::collectDiagnostics() method so it can inject its diagnoses into the results array. Then either: Make your module an autoload module and call it whatever you need to call it. Don't make your module autoload but the name must start with "Diagnose" in order for ProcessDiagnostics to load it when it is initialised. Here's the code from the new "DiagnoseExample" provider module that makes it about as simple as it can... <?php /** * Hooks into ProcessDiagnostics to add additional example information. */ class DiagnoseExample extends Wire implements Module { public static function getModuleInfo() { return array( 'title' => __('Example Diagnostics Provider', __FILE__), 'summary' => __('Demonstrates how to write a simple diagnostics provider module', __FILE__), 'version' => 1, 'permanent' => false, 'autoload' => false, 'singular' => true, 'requires' => 'ProcessDiagnostics', 'installs' => 'ProcessDiagnostics', 'author' => 'Stephen Dickinson, QBox', ); } public function init() { $this->addHookAfter('ProcessDiagnostics::collectDiagnostics', $this, 'AppendDiagnostics'); } /** * Collects Diagnostics. */ public function GetDiagnostics() { $results[] = array( 'title' => $this->_('Thing diagnosed'), 'value' => $this->_('Bad value!'), 'status' => ProcessDiagnostics::$fail, // other valid values are ::$warn and ::$ok. 'action' => $this->_('Describe how to correct the bad value.'), ); return $results; } public function AppendDiagnostics($event) { $results = $event->return; $results[$this->_('Example Diagnostics')] = $this->GetDiagnostics(); $event->return = $results; } } Obviously, it takes the 2nd route I mentioned above (doesn't autoload.) Let me know if you need any more information.

Yes, there's no reason why other modules can't publish appropriate diagnostics via the collection hook.

I'm not fixated by any particular scheme. What had you in mind?

@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.

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.

@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.

Guys, sorry to hear about the issue. I've never used RewriteBase before so I can't simply answer this but it strikes me there must be something @DV-JF can identify that's different between his two test sites. Firstly, how is the neu subdomain .htaccess different from the main domain .htaccess? Are you using RewriteBase in the subdomain case? Secondly, what version of PW are you running? Thirdly, I assume that commenting out RewriteBase in your .htaccess file and restarting the server causes PW's admin interface to stop working? Edited to add 1: It seems to me that RewriteBase only changes how the path part of a url is handled yet you are seeing problems with the domain part. I suspect this is some combination of your site's virtual host entry + file layout problem + .htaccess rather than something major in PW but I could be wrong. Edited to add 2: Are you 100% sure you ftp'd up a .htaccess file into www/sports-vitality.de/? and that it's readable by the webserver process? Also, is there a .htaccess file in www/? I see from Stack Overflow that you can get double domain parts if you are missing a readable .htaccess where you expect it (or it doesn't have mod_rewrite info) but one exists in the parent directory.

@Nico, Great! Added to the repo as ExamineModules.module. Thank you!

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:

@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.

@Nico Done. See opening post image. @horst Done. Ditto.

@Nico Implemented your suggestion. Image updated.

@horst Added your Image diagnostics and implemented sections. I updated the image in the opening post to show the results.

You are right - class process's install() does nothing. I've removed the parent::install() call.

@horst It turns out that the call to parent::init() in the init() method does things like automatically including the ProcessDiagnostics.css file in the page output. Well, at least I know now.

@horst I'm not sure re the call to the parent install routine. Will look into it. In the meantime, you are right about adding a check on the page id before trying to delete the page on uninstall. I do plan on cribbing some of Ryan's pre- and post-install code to see if we can re-use it usefully in the module. BTW, I don't have a windows machine to test this on so anything you turn up will be useful. @Nico Noted. Thank you.

@horst Thanks for taking the time to submit this! Perhaps this can become the first community developed module for PW if others want to get involved too Splitting the results into sections looks like a good idea - I'll work that into the display code. In the meantime, I've added several class variables that we can use for the 'OK', 'Failure' and (new) 'Warning' messages. Going forward, if people could use self::$ok, self::$fail or self::$warn for the 'status' entry that will simplify things. @Manfred62 Thank you for the feedback, I was unaware of the need to separate different strings with linebreaks for the translator to find them. Regarding the location of the diagnostics output page; yes, it should show up under the Setup menu. At least, it does on my fairly recent dev version (not the latest though.) Edited to add: Updated the opening post image.