teppo

You probably know both already, so perhaps you're looking for less well known alternatives, but I'd still suggest looking into Amazon CloudFront and/or CloudFlare. Big players have their benefits, and these guys can definitely "handle a lot of traffic"

Glad to hear that you got it sorted!

None of the things you've mentioned here are impossible, and all of them are very much doable with ProcessWire. This does sound like a big project, though, so better make sure you're up to it before signing up for anything. Just a few quick notes on the specific parts: Time banking system sounds like it could be a lot of work. You'll spend quite a few hours putting that together, so especially if this is a paid client project, make sure that you've made a list of features, proper plans, and estimates beforehand. The larger the scope of the project, the easier it is to miscalculate the amount of work, so leave enough room for surprises and mistakes in your estimates. Same thing goes for the messaging system, though this depends a lot on how it's actually supposed to work. "Internal messaging system" alone isn't a very good description. If it's just about leaving messages for other users, that's not particularly complicated, but you'll need to make sure it's secure. Privacy is a very big deal in a system like that. Registered users should probably be actual ProcessWire users, so that you can let the system itself handle authentication etc. That's the complicated stuff after all. Registration state sounds like something that could be a custom field on the user template. For the viewable user profiles profiles the support for multiple user templates and parents could come in handy. The best way to handle payments / subscriptions depends on a lot of things. Check out various payment services available and see how those fit your needs. Building a payment system from scratch would be a lot of unnecessary hassle you really don't want to get into. Not sure how much this helps, except for (hopefully) making it obvious that this sounds like a pretty big project. In the end the question here is not so much whether ProcessWire can handle this – it's more about whether you can handle this

I would say, admittedly without knowing Airbnb itself too well, that ProcessWire is a great platform for something like this. Such a project will involve quite a bit of custom work, from the registration and access management to reviews, but that you probably already knew. There are some modules that could come in handy, especially for the access management part. I'd check out Dynamic Roles, at least. Access management and registration are the parts you'll want to get right on the first try, as those are security-wise potential weak spots of just about any site or application out there. It's easy to model, manage, and query all sorts of data with ProcessWire, making things like complex searches easy to set up. In large scale you'll need to be careful with your limits (querying is relatively cheap, but fetching hundreds or thousands of results in memory is not; always define sensible limits and use built-in paging!) and you'll also want to test things out properly before letting too many users in. ProcessWire is known to scale well into millions of pages, but considering that usually (almost) everything is a page, that's not an impossible number to reach, of course depending on how you build this platform. I'd suggest taking a closer look into the (commercial) ProFields module package, as it could potentially boost the performance of certain parts a lot (thinking of things like reviews here, which might make more sense as Table rows than actual Pages; the built-in comments module is another solution that could work). I wouldn't worry about this solution scaling indefinitely right now; ProcessWire will scale pretty far, and if this service does indeed become hugely popular, eventually you'll have to go through a lot of hoops to get it running smooth no matter what technology you choose. Pretty much every big platform out there has gone through more than one more-or-less complete rewrite. That's not bad planning – it's simply smart to start with something that makes things easy (and relatively cheap) to get up and running, and worry about massive scale if/when you actually get there.

This is essentially just ProcessWire saying that Page Tree failed to load for something other than a network related issue. Have you updated ProcessWire lately, or perhaps installed/updated modules? Either way, check if there's anything in the error log: /site/assets/logs/errors.txt.

Your interpretation is correct, and the settings you've posted here should indeed deny access to the page for guests (non-logged-in users). Testing on the 2.6 branch, I can't seem to easily reproduce similar issue. There's a couple of things I'd like to check first, though: Do you have any additional permission-related modules installed – Dynamic Roles, UserGroups, PageEditPerUser, anything like that? Any other modules you can think of that could cause this behaviour? Do you have any third party modules installed at all? Are you absolutely sure that the page that is publicly viewable is using this template? Just trying to be extra thorough here Do you have any kind of caching going on, a proxy running in front of the site, content cached in CloudFlare, etc.? All in all this kind of issue would be much easier to debug if there was some way to see it in action, and/or if you could provide easy steps for reproducing it on a clean install of ProcessWire. It would be very helpful if you could test this with a clean installation, and see if it happens there too; if not, it could be something weird with this particular site, but at least that would give us some pointers about what to check next.

One particular case I had to deal with recently was using PageTable for configurable page layouts, i.e. dropping in blocks/widgets. In most cases, there were many different block types, but in some cases only one. In this case, I would've preferred to use template labels consistently, not making the client guess what this "new" block is that will be added. Could've solved this by field naming or descriptions, but this particular implementation was supposed to be as dynamic (and consistent) as possible, hence the need for "action" buttons to behave same way everywhere, regardless of field settings. Generally speaking convention over configuration is fine by me, but in my opinion current behaviour is far from "obvious". It's consistent with some other features in ProcessWire, but not consistent in the scope of PageTable itself. Additionally PageTable is one of those parts in ProcessWire where "convention over configuration" might not be the best approach after all; it's already being used for a lot of different purposes, and while that's a strength (no doubt about that), it does boost the importance of being configurable. In fact I've meant to post some additional suggestions related to labels, per-template settings, modal/view settings, and such; still trying to figure out whether to do that or simply fork PageTable. PageTableExtended is not exactly what I'm looking for either, even if it does already do some of the things I've had in mind. Anyway, that's a subject for another discussion

I've had use cases where this would be preferable too. Not always, though, so perhaps a field-level configuration setting would be the best approach?

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.