teppo

After banging my head on the wall recently trying to get a certificate for personal use from a commercial CA, I must say that this service would be very much welcome. I'm perfectly fine with paying for certificates intended for commercial use (not to mention that in those cases the request process has so far been smooth and painless), but for non-commercial use free and open alternatives are a must. </rant>

@ngrmm: take a closer look at the code Martijn posted and note the semicolon. Looks like your code is still missing that. While developing a site, you should run it in debug mode. This will output errors on screen and make it a lot easier to spot the source of issues like these.

This is answered in Page.php: Generally speaking Pages::saveReady and Pages::saveFieldReady (though saveFieldReady has only been around since in 2.5.7) are probably what you're looking for, because at that point it's certain that the page/field really can and will be saved.

It's clearly not just you, but.. nope, they didn't On a (slightly) more serious note, I have to say that after a few years with OS X I would find it very difficult to switch back to Windows. OS X has a bunch of neat features (such as the Spotlight search, which in my case has literally eliminated the need to touch menu items or Finder ever again), but a much bigger benefit is that it's Unix-like. If I need to automate a task or two, can't figure out how to do this or that via the GUI, or just want to get things done without swinging a goddamn plastic rodent all over, I can always just step into the soothing darkness of the console and get shit done. OS X is the next best thing after Linux, and since Linux still doesn't have most of the apps I need, it's the best thing at the moment. The new Surface Book does seem like a splendid machine, of course. Compared to a MacBook Air it looks a bit clunky, but from a strictly technical point of view it does seem quite awesome. If I actually had to get a Windows laptop, this just might be it

Been using Linode for years, and so far everything has worked out great. Don't have experience with their managed solutions and haven't had a single reason to directly contact support so far, so can't speak for those

Actually I meant individual requests on the Network tab (again in Chrome dev tools, might be different in other browsers). Anyway, Internal Server Error sounds like there's an actual issue on the server, so response text might not uncover anything new This could still be a result of a permission issue on the server, it could mean that the server runs out of memory (resizing large images can do this), or it could be something entirely different. Did you check the server error logs (and PW error log) already? A more specific error message would help a lot here.

There are couple of reasons why this might happen, but I'd check the situation with your browser's dev tools first. If you look at the request related to uploading that image, specifically the Response tab (if using Chrome; Fox probably has something similar in place) do you see errors or other weird output there?

It would be neat to be able to instantiate another installation within current one and just gain access to its API, but that's not possible (yet). Multi-instance support is currently listed under ProcessWire 3.0 in the roadmap. Currently your best bet would probably be using a migration tool or otherwise exporting the data first, and then importing it as a separate action, whether by using a migrator tool or case-by-case import/export scripts. In some cases it also makes sense to create a wrapper script that bootstraps another installation and performs specific tasks on; you can then call this wrapper via exec(), shell_exec(), or any of the other program execution features of PHP. Said features are, of course, extremely dangerous if unsanitized params are passed through, but you probably already knew that

I don't see the connection here either. The whole point of server-side image processing is to a) automate things so that you don't need to perform them manually on image-by-image basis and b) make these kinds of things possible for users with no access to software or know-how needed to do image processing themselves.

Sorry for being a bit hasty there! The module seemed mature enough to be mentioned, and I've personally found that often good stuff gets buried for way too long just because it's not "fully polished" yet. Early announcement combined with a little warning tends to work out just fine.. and it does also have the added benefit of getting feedback at a stage where making changes doesn't necessarily mean hours and hours work being wasted

The main difference is behind the scenes: Moderators are more privileged than PW-moderators. I do agree that the naming could be better, though

For the record, I originally managed to miss the post from Patreon where they announced the hacking. It's actually a pretty good one: seems honest, and they're not just apologizing, they're also explaining how they're going to prevent the same from happening again. In essence this is a good reminder to never keep dev stuff publicly available

Aww crap. Especially now that the ad blocking debate rages on, Patreon is among the few services that provide an actually viable alternative for independent artists and content creators to support themselves. I hope they don't take too much damage from this, as that would be a real shame. Also, I hope they get their shit together, as the data seems to point out that there are gaping holes in their security

That article is way too long to read right now, sorry for that. Anyway, I'm going to agree with much of what LostKobrakai said there Advertising per se is not evil, and a lot of media outlets currently depend on advertising for their livelihood. I'm not happy about the fact that this movement is driving hard-working content producers out of business, and my fear is that over the time it might actually affect the amount of freely available information floating around the net. Even more likely (and quite unpleasant) result is an increase in so-called "sponsored articles" . On the other hand this is an obvious reaction to many advertisers going way over the top. Not only do ads invade your privacy, ad networks take no real responsibility for malvertising – neither of which is acceptable anymore. While advertising is here to stay, the revenue stream it generates will slowly diminish, and advertisers will need to find either smarter ways to advertise or other, hopefully less obtrusive, ways to earn. The worst case scenario right now is that ad blockers getting more common will result in even more ads (and even more intrusive ads) which in turn will result in even more aggressive ad blockers – in other words an arms race between advertisers and ad blockers. That would be a bad situation for everyone

Ben, have you seen the Grid Builder? The module isn't available (at least yet), but sounds very interesting. With PageTable you can build quite flexible things already, so I'd probably go that route. Support for multiple templates for PageTable fields allows you to define various types of content blocks (or widgets), and if you need multiple columns, just add more PageTable fields. In a recent project I built a somewhat similar concept to what you've described here. Started out with PageTableExtended, but discarded it in favor of regular PageTable as I couldn't get the UIs to match one another well enough; in the end having two "almost but not entirely identical" UIs felt more of a con than a pro There are downsides to this approach, such as more complex front-end search, but nothing one can't solve, at least with some hook-related magic.

It's true that this might be out of the scope of this project, but it is a great idea. Nothing beats real content when working on a site, but when that's not available yet (or you're not working on an actual site but a module or something like that) it would be cool to be able to easily mock up a given amount of (real) pages, and later remove them just as easily. This would be particularly helpful for testing UIs, performance, and scalability. Just saying, not trying to put any pressure on you Adrian..

Not APIs, API. Hopefully I don't sound too rude (in a bit of a hurry here), but please check out the docs section. It's all explained there. In addition to that, I'd suggest taking the time to browse through some of the tutorials, in case you prefer a hands-on approach. The kind of questions you're asking here are perfectly understandable from someone just getting started with the system, but it also sounds like you haven't really bothered checking out the docs either. Also, the forum is filled with answers to very similar questions, so you might want to try looking around a bit. To be fair most of your current confusion seems to stem from not understanding many of the basic concepts of ProcessWire, including how it handles content and content types. While it's a bit outdated by now, Ryan's excellent overview video is still a very good starting place in this regard; the UI will look different from what you'll see on your site and your site will have more options and settings to play with, but the basic concepts are the same.

First of all, thanks for sharing this. Hash ID's have their benefits, and your method is a nice example of getting started the easy way A hashed ID is essentially password authentication, though without the need to type in a username. For use cases that require more security, one should consider not using this method alone, but, for an example, combining it with another GET param (which would be a username, constant API key, or something similar) and perhaps making the salt unique on a per-user / per-calendar basis. Additionally detecting multiple attempts for different ID's from one client and issuing a cooldown period (a ban) automatically would make sense, to prevent malicious attempts to gain access to calendars, which might contain very private data. Just my five cents

In my opinion some of the convenience of putting sites up fast is diminished by the need to constantly keep an eye out for vulnerabilities. You can't just set the site up and expect it to work. The more important the site is to your business or your reputation, the more you'll have to worry about it getting hacked or otherwise tainted. Additionally it's not all bliss when your plugin collection grows and each time you want a new one you need to consider how it affects all the existing ones. Anyway, I've heard the same positive things, and witnessed them myself too. In this regard it mostly depends on how happy you are with the off-the-shelf solutions: if it's a perfect fit then that's great, but if you want to make "just a little change" things can get ugly really fast. Probably the best answer in that case would be "can't do it". Also, if the client (whether that's a real client, you, or someone in-house) asks for a new feature, you'll have to consider the whole plugin ecosystem before giving them an answer. ProcessWire makes developing custom solutions extremely fast. For the kind of solutions I've been developing for years, from the scratch, ProcessWire saves me so much time per project that it's almost scary. On the other hand developing a custom solution is never going to be as fast as installing pre-made themes and plugins

@Pete: actually, this doesn't sound that unfeasible to me. It might require new kind of structure for the directory though. Private modules wouldn't need to be approved at all, but on the other hand they should require authentication, and they would need to go through approval process if later changed to public. Not sure if that's where we want to take the directory, of course, but I'm quite confident in PW's ability to handle this Something along the lines of what @Dave mentioned has crossed my mind too. For an example, for our sites we don't allow installing modules from the directory, mainly because they still need to be internally audited. I'd be quite happy with the ability to set up a separate directory of my own, if that's what it takes, but perhaps there's an easier way to achieve the same result

Sounds like a sensible idea, a new forum section for security-related discussion definitely gets my vote. At the very least this should make it more obvious that security is, in fact, an important factor for ProcessWire. The product and the community.

https://github.com/ryancramerdesign/ProcessWire-2.0/commit/2eef88ad57ccb2a7f58dcacc2a3f44f7ed43951e

No. Just.. no.

You might be right. Looks like the uxpin one first describes adaptive design as something that does not change after initially being loaded (by which I assume they mean loaded using breakpoints which they specifically mention, though they're not being very clear about that), and then continues on describing adaptive design process (when designing from the scratch) as developing different breakpoints for the same layout. Confusing much? Terminology isn't the strong suit of the web design community, but I do have to admit that for me this interpretation of AWD was completely new, so.. learned something new here. I don't agree with the approach, though, and believe it's fundamentally broken; we don't know what the future holds and in order to be "future friendly" we need to take that into consideration in our designs.

Not only does that article use weird terminology (popular interpretation of adaptive web design is something entirely different), but it's also missing important parts of responsive web design – including the whole point of doing web design in a device-agnostic way. In most cases I'd rather suggest looking into ways of improving your responsive design workflow with mobile-first approach, lazy-loading assets, etc. Either way, if you really need to go with server-side device detection, you might want to look into Mobile Detect module. It's far from a complete solution in this regard, but one step closer to what you're looking for