teppo

Internal server error could mean a lot of different things, but first of all, double check that you're really not seeing anything in the error logs, Apache or ProcessWire. Also, make sure that you're looking at the right error log files (not sure how XAMPP / it's Apache setup handles these). Error messages are your best bet on finding out what went wrong, after all. I'd also check if a clean installation works, and if that doesn't work, check if a basic PHP application (preferably something that creates a database connection) works instead. That could give you some clues about the issue. If a clean installation won't work either, it's likely to be caused by some error/misconfiguration/change in your environment (XAMPP / Apache / PHP / MySQL). Sorry, not much help from here, but those are the things I'd start with anyway.

Glad to hear it helped

Disregarding your particular issue (which might mean that you serve this site with multiple domains, could be a caching issue, could be connected to your httpHosts setting in /site/config.php, or be something entirely different) for a moment, do you really need httpUrl, or could you use url instead? Relative URLs wouldn't have this issue at all. Just saying.

ProcessWire doesn't store date information with a checkbox field. Your best bet would be using a hook (insert one into /site/tempates/admin.php or write a simple module for this) to automatically populate separate, possibly hidden (unless you want users to tinker with this) datetime field when the checkbox is checked/unchecked. Alternatively you could use the Page Reference with Date Field to achieve similar look and feel; just have one page called "Completed" selectable, and it should handle the rest for you

Thanks for the clarification, Pete. I was pretty sure that there's something like this, but wasn't sure at what state it was. Seems that there are a couple of solutions to this, in fact, and this one by Conclurer seems like the best choice at the moment This, I'd say, would in most (especially "enterprise" scale) cases be intentional. If you can't validate current user via the master server for whatever reason, you can't know for sure if the user still has a valid account.. and thus you definitely shouldn't let her in. Sure, stable connection is a necessity, but this is also the only way to be sure

Glad to hear you like ProcessWire, and hope to be of help here. Also: welcome to the forum! Check out this post by Tom Reno. Apparently they're using Shibboleth, and he even mentioned the idea of turning this into a configurable module. You could always drop him a note and check if he's got any plans regarding this; I'm sure there are others who'd benefit from that kind of module too This depends a lot on how you want to manage your site. Above you mentioned per-user page-specific permissions, which is one approach you could definitely take; there are many examples of something similar floating around the forum, it's surprisingly easy to build yourself, and then there's the Page Edit Per User module by Ryan. On the other hand, if you're interested in a solution that's slightly less "fine-grained" but easier to manage, Ryan's Dynamic Roles module is also worth checking out. I haven't used it that much myself, so won't go into detail on it's inner workings; from what I can tell, it's used on many large-scale sites already. We've been using the UserGroups module for all of our "per-page view/edit" needs, and we're quite happy with it; might be partly because we've been heavily involved in the creation of this module, of course. UserGroups adds a new concept of "user groups", and lets you assign view or edit permissions for each given page to one or more of these groups, which in turn can contain any number of users. Permissions are inherited, so you don't have to specify permissions for each page individually. Wanted to answer this part separately, since the answer (to me) is quite obvious: absolutely not! On the other hand, a few modules here and there are not a problem, and most of the modules you'll find in the Modules Directory are of great quality. While you can't (and shouldn't, even if you could) build a ProcessWire site just by using installing a bunch of modules, you should feel safe to make use of those that do fit your needs. We're not like [insert the name of a very popular blogging platform here], and the answer to every need isn't "there's a plugin for that". With ProcessWire you'll most likely be doing much more hand-crafting, but for many popular needs there's also a handy module – and if there isn't, just ask and often you'll be surprised at how fast the community can answer with a full-fledged solution.

The "PW ! WP" idea is clever, but not exactly my cup of tea. Also, regarding this design in particular I feel that the logo might be too much. Even if it makes it clear that this is a PW shirt, at the same time it feels a bit like having to explain a joke; it's not nearly as funny anymore. Apart from that, it's great to see (more or less) official apparel, and I sincerely wish you sell a bunch of these! A bit off-topic, but if there was a shirt available with nothing but the "ProcessWire" logo text, or the "P" symbol, I'd get one instantly. Of course I could just get a shirt like that myself, and I believe some of us have already done so, but if the proceedings would (even partially) support Ryan / ProcessWire, that'd be even better

Don't even consider getting into this business – or any business at all, for that matter – unless you're going to have water-tight contracts. If you suspect you can't handle that part, have someone else do it for you If you sell software products, you need to be very clear about a) what exactly it is that you're selling, b) what are your responsibilities as a service provider, and c) what are the client's responsibilities. Defining the limits of your liability in the case that something goes wrong is important, especially since the awkward truth is that in the long run something will go wrong, no matter how good or careful or lucky you think you are. Other than that, this post you linked to seems quite opinionated. While such text can often be great for provoking thoughts and discussion, this one is also very naively written. The author seems somewhat prone to oversimplifying things, and many of her "reasons" are easy to debunk or question. Not every situation is the same, not every need is the same, and not all clients are the same. Just saying.

This has been the default behaviour in certain server setups, including most Debian and Ubuntu based servers, since ProcessWire 2.5.17. The code responsible for this can be found from index.php: https://github.com/ryancramerdesign/ProcessWire/blob/master/index.php#L183. Most of the time this is intended behaviour, and not something you should be worried about. On Debian-based servers PHP's garbage cleaner wasn't working at all when session files were stored in a custom directory, which is why we let PHP decide where to store them. If this is causing you actual issues please let us know, though!

This module was already introduced in another thread yesterday, but since each module should have a thread of its own, here we go. Login Scheduler adds a couple of new fields to user template(s) and provides support for disabling login for non-superuser accounts either instantly (with a checkbox, "Login disabled") or by specifying a time range ("Login allowed starting from", "Login allowed until"). If a user is already logged in when login access is disabled, logout should be triggered during next session validity check (usually next page load). Starting from version 1.1.0, superuser accounts are not affected by this module at all. This is a safety mechanism and prevents you from locking yourself out of the whole system. You can grab this module from GitHub: https://github.com/teppokoivula/LoginScheduler.

One more solution: https://github.com/teppokoivula/LoginScheduler. This has been on my todo list for a while, this topic just gave me a reason to put it together. Should work, but not 100% guaranteed

From what I've seen and read so far, Cloud Source Repositories and Google Code seem different enough to make moving users from one to another impossible. Google Code was built for public hosting, with all sorts of bells and whistles to lure in users looking for free hosting, while Cloud Source Repositories is a straightforward code repository for (private) Google Cloud Platform projects. It seems that Google has finally realised that competing head-on with GitHub is, and always was, a bad idea

Some parts of this module, mainly those related to the cleanup features and settings, have been completely rewritten recently. I've also removed some old hacks, mainly from the UI side, that were carried over from Version Control for Text Fields. Test suite has been updated accordingly, and so far I've been unable to find any further issues, at least in the core features of this module. While some todo items still remain, I've just bumped the version number of the module to 1.0.0, and removed the "beta" status from the modules directory and from the first post in this thread. 1.0.0 should be considered the first stable release of this module, but of course if anyone spots any issues, I'd be more than happy to hear about them, either here or via GitHub. Big thanks to anyone who's been using this module, reporting issues, etc.!

I'm not too familiar with the whole concept of predictive analytics, or big data for that matter, but taking a look at the tools you mentioned they seem to focus on visualising collected data (D3.js, scikit-learn) and making mathematical predictions based on it (scikit-learn). Please correct me if I'm wrong, though; the thick cloud of buzzwords surrounding some of these tools and concepts makes it very hard to figure out what it is that they actually do/mean. As such, I'd say that "compatibility with ProcessWire" as a question makes little sense. ProcessWire is a great tool for defining data types and storing huge amounts of data, if that's what you're looking for. It's also a great tool for formatting and outputting said data in any way you – or another application – needs it. What it isn't, though, is an out-of-the-box tool for collecting data (but you could always build something like that yourself). I'm not sure what kind of data you want to collect and analyse, so that's just about the extent I can go into this topic If you're looking into technical details regarding the tools you've mentioned above, scikit-learn is based on Python, so you'd need hosting that supports that. I'm not sure if the "python" you mentioned is a specific tool or the Python language, but I'm assuming you mean the latter, which again leads to the conclusion that you need to look for a web host offering Python support. D3.js is a JavaScript library running client-side, and thus server-side considerations don't apply there. Note: I've just moved this topic to the Off Topic / Dev Talk area of the forum, which seems like a better fit here. This question is very loosely related to ProcessWire itself, and has a lot more to do with other tools.

Just for the record, this is also discussed here: https://github.com/ryancramerdesign/ProcessWire/issues/263. In that issue Ryan explains why it works like it does. Generally speaking I'd suggest avoiding changing templates of existing pages, and explaining to clients that this is a) a special case, and b) potentially dangerous. Changing template could result in loss of data (though ProcessWire does attempt to warn you before anything irreversible can happen), and it might also cause unexpected side-effects on the site, if something somewhere assumes that a specific page exists and is of certain type, etc.

Added. You can add fields there locally via module settings too. I'll have to think about this a bit more. Current behaviour (closing on click) is intentional, partly to prevent weird things happening when something on the previewed page is clicked, can't remember if there were other reasons too. I'm getting some errors also; I'll take a closer look at those first Edit: forget that last part. Errors were a result of local changes, the feature is working as expected again. @LostKobrakai, any chance you could tell more about the error(s) you were getting? Either way, the click-to-close thing is something I'll take into consideration, but changing this just to make system notifications work doesn't seem reasonable. Displaying admin views in preview mode is something that shouldn't ever happen, after all

Google has killed off one of their pre-oAuth authentication methods, and the popular GAPI library is still relying on it. In case that anyone here happens to use said library for communicating with Google Analytics, please make sure that you're not running it in an environment where errors are publicly displayed. This is especially important if the GAPI authentication request isn't properly wrapped with try..catch, since the stack trace will contain Google credentials as-is, i.e. unencoded and publicly visible. Just a word of warning, since currently a simple Google search will result in a whole lot of sites with exactly this issue, and with plain-text credentials (partly or completely) visible.

@Craig: just wanted to say that this looks great; going to give it a proper try soon! How 'bout adding this to the modules directory? There's a "beta" option there, if you're hesitant about calling it "stable"

Another option is to call $pages->uncacheAll() at a regular interval. This helps you avoid memory issues in most cases, and allows you to run the whole query at once. For a rough example, see how it's done in VersionControl.module. If you do take this route, make sure that your maximum execution time isn't an issue here either. If your script takes a long time to run, you'll usually want to increase the max execution time using set_time_limit() first. The default value is typically 30 seconds, and a script running longer than that gets killed. First things first, though: you mentioned that the page goes blank supposedly because of a memory issue. If you're not 100% sure of the reason for the issue, the very first thing you should do is checking why it actually happens. Do the same thing in a test environment with $config->debug = true, or see your error logs on the live site. Assuming is never a good strategy

@lpa: looks like an issue with the Helper Field Links module, you might want to report it to Soma in the appropriate thread. It's incorrect behaviour to expect REQUEST_URI to always be present.

Some additional observations: The way a version number is appended to module name in the docblock at the top of the file feels weird. It's a small thing and I can always remove it manually, but if the purpose is to mention the version of the module, I'd suggest using @version tag instead. (A question with both approaches is whether module authors will remember to keep this up to date with the module version recognised by ProcessWire, though.) Seems like basic docblocks for methods such as getModuleConfig() would make sense too, otherwise they'll have to be added manually for every new module (or worse, they'll be left out altogether). It would be awesome if the generator could make it easy to choose and include a license, preferably as a combination of @license tag + LICENSE file. A few common license types would suffice for starters; GPL, LGPL, BSD, MIT, and perhaps something like WTFPL too. I've seen many modules lately that haven't specified a license, and to me this is a huge red flag, as it literally means that I can't know how, where, and for what I can legally use said module. I was a bit surprised to see that implementing ConfigurableModule didn't enforce "include configuration page", as it seems like an obvious choice. Part of the confusion was that "configuration page" made me think it would add an actual page somewhere to contain configuration settings, which is why I left it unchecked in the first place.. For some reason I'm also getting blank array items in module config. Not sure if those are intentional or not, but they do look a bit strange: 'requires' => array("PHP>=5.4.0", "ProcessWire>=2.5.3", ""), 'installs' => array(""),

Nico, I'm having an issue you might want to take a look at: if the summary contains non-ASCII characters (in this case "ä" and "ö"), they seem to get stripped from the final file. Doesn't seem intentional. Another thing I noticed, and this is more a gotcha than a real bug, is the optional "implements" setting. It's true that "implements Module" can be disregarded if you're extending something that already implements Module or ConfigurableModule, but leaving it out unintentionally will result in weird errors, and currently the UI seems to suggest that this would be optional in all cases. This could be confusing, especially to beginners. Your default configuration options "+" UI made me wonder whether it would make sense to allow creating and bundling multiple module files at once? Most of my modules seem to actually consist of more than one module – a Process module for UI or API, another module for hooks, perhaps a third one for optional features, etc. This could be a border-case and would require some sensible server-side limits either way, so perhaps not worth the effort though. I'm also wondering if the source code for this tool is something you'd like to share and/or open-source. Not sure what your long-term plans here are, but I'd be happier if I could see how this thing works, perhaps report bugs and send PR's via GitHub, and just overall be sure that if something goes wrong I can have another copy of this very useful tool online (or installed locally for cases where I'm not connected to the Internet at all). .. and finally, I can't select ProcessWire 2.6 as "min. required PW version" yet For the record, I'm currently writing a paper that'll discuss module development in detail, and I'm very happy to be able to suggest this tool as the preferred method of setting things up. Of course I'll mention the "old-school" method of duplicating another module as a starting point (and even starting from the scratch), but IMHO your module generator has made other approaches obsolete in many cases

Agreed. Such things are no deal-breakers, but annoying nevertheless. Additionally, since we're (kind of) discussing smaller details here, what's with the "mod" part -- why not call it "module"? Seems like it's the only thing that gets shortened, and thus looks like another API inconsistency to me. Again: small, but annoying

Agreed with Pete. At this point Flash and Silverlight are nothing more than unnecessary legacy payload and clutter. I'd rather use a clutter-free library than one attempting to cater for the needs of all the old (and outdated) browsers with any means necessary.. so to speak

I'm seeing two settings that could have something to do with this: maxFileSize and loadImageMaxFileSize. Latter seems to be 10MB by default, so not too far from what you've mentioned here.