netcarver

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

@kongondo Done and done as v0.0.3. Initial post updated to show output.

As of v0.0.2 you should be able to hook ProcessDiagnostics::CollectDiagnostics() to either append or modify collected diagnostic data as required. Minimal cell highlighting now added for failure lines (see picture in the opening post.)

Introducing ProcessDiagnostics and it's helper module suite. (Is this ProcessWire's first community-created module suite?) Description This suite adds a page under the setup menu that displays information about your installation. Each section's data is provided by a specialist diagnostic helper module but it is all collected and displayed by ProcessDiagnostics. The ProcessDiagnostics module itself does not encode any knowledge about what makes up a good or bad setting in PW - (that's done by the helper modules) - but it does the following... Gather the diagnosics (thanks to PW's hook system) Display the collected diagnostics Provide helper functions for describing some common things Dispatch actions to diagnostic provider modules (again thanks to PW's hook system) And eventually it will: Allow control of the verbosity of the output Allow the output to be emailed to a sysop Store the results between visits to the page Detect differences between results at set times Send a notification on detection of changes Although I am curating the collection, anyone is welcome to fork the repo, make changes in a topic branch, and submit pull requests. I've already had submissions from horst and Nico. Diagnostic Providers The current diagnostic providers include... DiagnosePhp - Simple diagnostics about the PHP envirnoment on the server DiagnoseModules - An ajax based module version checker by @Nico DiagnoseImagehandler - Lets you know about GD + Imagick capabilities by @horst DiagnoseDatabase - Checks each DB table and lets you know what engine and charset are in use DiagnoseWebserver - Checks the webserver setup DiagnoseFilesystem - Looks at how your directory and files are configured and warns of permission issues (currently incomplete) There is also a bare bones demonstration diagnostic module... DiagnoseExample - minimal example to get module authors started. Translations English & German (thank you @Manfred62!) Help translating this suite to other languages is always welcome. On The Net Check out Nico's blog post about this suite on supercode.co!

Ahem, It's been there a pretty long time

Perhaps "RyanCramerDesign" on packagist.org as well?

@JimboJones Welcome to the PW forums. I don't know the answer to your question but I can take a guess: wire/core/autoload.php Hope that helps!

Slightly simpler... $modules->getInstall("Your Module"); Here's what the code comments have to say about this function... /* * Get the requested module and reset cache + install it if necessary. * ... */

Does this work... if (wire('modules')->isInstalled("module name")) { // boleh! } else { // 'tak boleh } ..?

@J1312 Try doing this... $modules->resetCache(); $modules->get("MyModule"); ...and let me know if that fixes the issue for you.

For the benefit of other module authors (or module "bundlers") I've just pushed a new module up to github that allows you to do a "one-click-install" of an entire set of modules. I know about the "installs" option for modules but believe that this offers a neater solution in some scenarios. For instance; it allows all of the sibling modules to be written without the need to define any 'installs' relationship between them - which could be particularly useful for later bundling of otherwise unrelated modules. It also keeps the modules UI clutter to an absolute minimum - all the user sees in the UI is just one module to install rather than all the modules that the package holds. There is a demonstration 'project' here that you can install to see what this module does for you - specifically: how it simplifies the UI for the installation of 5 other modules. Please note: This is an infrastructure module targeted at module authors or folks who otherwise create 'bundles' of modules. It isn't something you will want, of itself, for any site. (Which is why I'm not posting it to the module repository.)

I've never known git lie to me. I've known me mess things up and not realise it for a while. I think Craig has probably identified the culprit in his answer but failing that another possible mess up would be working out of a directory you think is symlinked from your git repo but isn't (been there, done that.) If that's the case you still have all your changed code - just diff them with the files in git and pull over the changes and commit.

@darrenc There are a couple of approaches you could take to set this up. I'll describe one that uses a symlink. As you already know this will only be a change to the repeater module I'd be tempted to create a symlink from the wire/modules directory from #2 into #3 and make sure that I had #2 switched over to what folks call a 'feature' branch. This is a branch of the codebase that you dedicate to adding just one thing which, in this case, would be your changes (or just one change) to the core repeater module. Here it is set out in a little more detail. In the root of your local 'working directory' you'd do... 'git checkout dev' so you have the dev branch checked out 'git checkout -b super-repeaters' (substituting 'super-repeaters' with a better name for your feature) which creates and checks out a new feature branch called "super-repeaters". Make sure your local installation's wire/modules/fieldtype/FieldtypeRepeater/ (the whole dir) is a symlink to your #2's wire/modules/fieldtype/FieldtypeRepeater/ directory. Any changes you make to the repeaters in your installation you are then making to the corresponding files in your working directory. When you've tested your code and are happy with it you 'git add' and 'git commit' as required into your super-repeaters branch. You can then send changes to github with 'git push origin super-repeaters' (or whatever your branch is called) and use github to create a PR to Ryan. A couple of gotcha's to look out for... 1) Make sure your text editor is setup for utf-8 file encoding with no BOM marker. 2) Make sure you setup the editor to use linux style end-of-lines (\n not \r\n or \r.) Hope that helps. Just ask if you need anything else.

@darrenc In addition to adrian's remarks above, I've found that Ryan is great at picking up a good idea from a pull request and making whatever adjustments he feels necessary to slip it into the codebase. Don't worry about dotting every 'i' and crossing every 't' at this point; just get used to git and github and then make sure that your proposed changes make sense and have a good rationale and you have a good chance of seeing the code get accepted even if it is modified along the way.

Thank you both, I've updated the module page - the download link should now work.

@alanfluff, It is primarily for tidying up sloppy spacebar work. CKEditor turns n spaces into a space followed by n-1 non-breaking spaces - which I hope this module takes care of cleaning up .

TextformatterThinspace is a trivial text formatter that removes repeated spaces (either ascii or non-breaking) and repeated newlines, replacing them with just a single instance.

Hi @pwFoo. Like adrian, I'm unsure of what you are actually asking for. Could you clarify please?

@ceberlin, Thank you for letting me know. Could you try changing that line to... if (isset($this->data['debug'])) { ... and let me know if that solves the issue for you.

Updated PR has been merged into the dev branch. https://github.com/ryancramerdesign/ProcessWire/pull/457

@felic, @WinnieB Ah, it might be because PHP version requirements are only supported in Processwire's dev branch code at the moment. Could either of you confirm if switching over to the dev branch of PW fixes this issue for you?

Hello @adrianmac and welcome to the Processwire forums. Take a look at the Shop module for Processwire (http://modules.processwire.com/modules/shopping-cart/) and see if that works for your scenario.

@felic If you are sure you've got a sufficient PHP version, you can edit the files and just remove the version check. It's just a single line delete from each of the .module files you uploaded to your site. Here's a link to the line that needs deleting in TextformatterTextile.module - just delete that, and the same line (might be on a different line number) in whatever formatter you are going to use. Not sure why the test would be failing for you.