teppo

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

Just did the same, and can't spot any issues either. We're already using prepared statements, sessions are securely implemented (especially if you enable the built-in database session manager), CSRF protection is in place, .htaccess prevents direct access to anything potentially harmful, etc. Some of their suggestions are strongly opinionated, and in those cases we don't necessarily follow them and/or agree with them. For an example, OWASP suggests that a templating engine is "essential" for secure sites. Personally I call bullshit on that one, but if you really want to, you can install a templating engine as a separate module, thus making your site compliant with this suggestion. Another point to note is that they (rightly) stress that all input is dirty, and no user input should ever be embedded on a site without proper sanitization. Because use cases differ, ProcessWire won't force sanitization on you, but it does make it very easy to implement by using the built-in Sanitizer, certain Textformatters, and field-level settings that automatically remove tags from content. I would suggest checking out the security documentation, unless you've already done that. It should provide most of the details you need in order to build sites with ProcessWire securely.

Seeing this on Safari too. Appears randomly, can't see any obvious pattern here. The joy of debugging front-end issues.

That's a brilliant idea, thanks for sharing! Nearly every site I work with has something along those lines at template level. While that works just fine, this helps avoid some pointless if-mess

I can see why some might feel frustrated with the article, but to be honest, I don't think it's bad at all. Sure, the quality of the text itself isn't exactly professional, there are no images (quick, someone send him some screenshots!) and the WordPress comparison does feel slightly awkward. Still, most of the points the author makes are entirely acceptable – and even sensible: If you just want to set up a site and don't want to touch or learn any code at all, you're probably better off with other systems. It's true that our community is relatively small. On the other hand the author does mention that "small community translates into striving for quality over quantity", "it has a different target audience", and even goes on to say that "if you run into a problem, you are likely to get a complete answer from the developer or other knowledgeable users on the ProcessWire forums". The author explains how customizable ProcessWire is and how effortless the upgrade process is, especially compared to WordPress. The author actually seems to understand the concept of "Page". Big props for that. In fact, after re-reading the article, I'm not sure I see much reason to be frustrated anymore. The "pros" of ProcessWire are explained nicely, most "cons" are just facts, and in general I don't think that the article is intended to "bash" ProcessWire at all. For anyone even moderately interested in actual web development the article actually makes ProcessWire sound really good, and even the WordPress connection makes sense when you think about it a bit. WordPress is probably what most, if not all, of their readers use or are otherwise familiar with, and if comparing ProcessWire to WordPress makes it easier to grasp, that's fine by me

One more option would be the Hanna Code module, which allows you to define and embed the content blocks directly from within the Admin interface. You don't have to allow your content editors access to creating new content blocks, but they can still embed them. The obvious benefit of include files or wireRenderFile() over Hanna Code is that you can have these under version control system (if you use one), and thus it's easier to keep track of changes and harder to accidentally delete content.

I realise that you kind of got your answer already, but just wanted to add some thoughts to the topic First of all, we've discussed the "what should be in the core" topic a few times, and the conclusion has so far been something along the lines of "features that most sites require". For most sites the published/unpublished separation is more than enough, and a feature like drafts could actually be even harmful (an added complication). ProcessWire, as it is right now, does most of what any regular site could require, and more. In fact I'd be tempted to argue that in the future we should trim down current distribution, not add to it, unless someone can point out a real need that still hasn't been answered. What Ryan has been doing with the AJAX inputfield updates, selector updates, etc. is enhancing existing features, and in my opinion that should remain the main area of focus in the near future. Anything that isn't in the core can be realised in the form of modules, and if those modules are commercial, that's (again in my opinion) fine. ProcessWire has a viable module ecosystem, and anyone can create and publish commercial modules, if they so choose; in other words, this isn't a right reserved for Ryan alone. Of course I hope that module authors choose to open source their code and provide it for free, but I can't force that decision on anyone.. and neither can anyone else All that being said, the way this works should be communicated clearly and visibly; what goes to core and why. Years ago I looked into Concrete5. Back then multi-language support was only available as a commercial addition, and my first reaction was literally "what a greedy bunch they must be, asking money for what should be a core feature". Thinking about it now, I probably just didn't understand their target audience and the reasoning behind this particular decision. I sincerely hope that as few people as possible take a look at ProcessWire, see Drafts or FormBuilder or ProCache, and think that "those ProcessWire developers must be a greedy bunch to take money for obvious core features!"

Right. After looking around for a while, I still can't seem to find an obvious solution to this. Considering that you mentioned that sometimes things work as expected, only things I can think of right now are that a) the MySQL server is not functioning properly, b) connection between your site and the MySQL server is bad, or c) it's a performance/stability issue (i.e. the database server can't handle the load). Since you mentioned that you've been working with this host before, did you mean that you've had (or still have) other sites there that run just fine.. or did this particular site run fine at some point and break after a change on the server? If that would be the case, I'd be almost certain that the host migrated databases elsewhere and something went wrong, but if this is a brand new database, that's somewhat less likely. Either way, the issue itself still sounds like something related to your web host. I've never seen or heard this happening before, and while my experiences may be somewhat different from majority of users here (I prefer to manage all my servers myself, so don't have much experience with shared/managed hosts), I know for sure that ProcessWire has been running perfectly fine on so many hosts that this is very unlikely to be a ProcessWire issue per se.

Which table doesn't exist? Is this the full error message, and if so, how do you know which table it's referring to? Do you get any errors or other weirdness in your /site/assets/logs/errors.txt or /site/assets/logs/messages.txt, and if you enable the debug mode (via /site/config.php), what's the full error message you're getting? Edit: reading your post properly, you mention that sometimes the site works. This makes it sound a lot like a database issue, and while I'd be tempted to say that it's most likely an issue with your host, we should probably dig into this a bit further. Is the database on the same machine (localhost), or is it on a separate server (and host)? Have you ever experienced connectivity issues with this host before?

One hacky solution would be parsing the URL manually from $_SERVER['REQUEST_URI']. It's nowhere near as clean and simple as checking $input->urlSegment1, you'll have to route these requests through your home page each and every time, and it won't be a valid solution for all use cases.. so perhaps not the best thing to do after all Somehow I was under the impression that URL segments wouldn't be as "strict" as actual URLs, no idea where I got such idea.

@EvanFreyer, open your .htaccess file and look for this line: # OPTIONAL: Send URLs with non name-format characters to 404 page This is the first step at enabling non-ascii URLs, though I'm not entirely sure if it's the only one you need to change.

Doesn't sound right at all. 500M makes it sound like all your posts are getting loaded into memory all at once. Taking a quick look at the ProcessBlog.module, there's actually a bunch of queries without proper limits defined, such as this one for an example: wire('pages')->find('template=blog-post, include=all, sort=-blog_date, parent!=7'). If you want to debug this further, I'd try disabling all queries that find blog-posts without a proper limit, and see if that helps. Kongondo would know better how to handle these, if they're the issue here. Loading all posts into memory at once definitely shouldn't be the only option