teppo

I'll try to put a simple example online later today.

Without (hopefully) derailing this discussion too much, that's a good start: the server needs to be configured properly. Misconfigurations open it up for vulnerabilities. The most important thing in this context, though, is escaping commands and arguments properly, preferably using a whitelist approach. None of this applies to exec only, of course – code execution features just tend to increase the risks involved. One thing that's kind of unique to code execution features is the amplification effect they have: if an attacker gains access to an application that doesn't allow her access to code, the most she can do is mangle your data. If there's a configuration option somewhere that allows her to control the output sent to exec(), such as the command it will execute, she suddenly has access to a lot more than just that. Then again, the same thing goes for tools that allow you to edit your template files etc. online

From my point of view it doesn't matter that much, as long as the work is good and it is released for the general public under a proper open source license. We already have examples of someone else taking over a module that another person started, etc. To perhaps answer your question better, I tend to see the crowdfunding part mainly as an addition to current workflow where interested parties build and release modules for completely free. In this case you get paid for that initial work. If the module needs maintaining in the "fix bugs and make sure it works with new versions" kind of way, these should imho be provided for free as much as possible (or by accepting contributions from other interested parties). If the original developer can't handle this and the module has valid use cases, I'm sure we can find someone else who does have the time to do it. In the case of "nice module, but I think it needs big feature x", there's always the option of arranging another round of crowdfunding It's one option and I'm definitely interested, but like I said, I don't have much time on my hands right now; you might find it faster and easier to catch another developer for this

Just wanted to say that this sounds very interesting. Been meaning to build a module like this, though was thinking of limiting it to PNGs since that seems to be the only case where optimization doesn't necessarily mean sacrificing quality. I'm also aware of the minimize.pw service, but a) it's not free (as in beer or as in freedom), b) it doesn't seem to be well maintained and c) I don't want to rely on external services unless I really trust them (especially when it means sending client data over to an external server). As a reply to Horst, kind of, I'd like to point out that whether or not the host allows exec(), if there's a similar solution that doesn't require it, that's in my opinion always the better route. Even when you're taking every step to make sure that it's safe, exec() is still potentially dangerous. Any and all mistakes have the potential to compromise your entire server (or, at the very least, your personal account). There's a reason why exec() and other code execution methods tend to trigger warnings from security scanners. That being said, I won't deny that executing external apps via PHP can solve some situations where nothing else helps. I've had to use it many times over myself. Edit: just took a closer look at Tinify. Somehow I managed to miss earlier the point that it is also an API, i.e. requires sending the data to their servers for processing. Can't say that I would be exactly happy with that, but will give this a while; perhaps it's a compromise worth making. In the meantime I'll be looking into some alternative approaches.

That's just the thing with PW: there's rarely a "right way" to do something. When it comes to things like templating, I still think that for a beginner it's best to start with the simplest possible scenario, which would be direct output. Once you grasp that, it's much easier to understand how delayed output or some of the more advanced output strategies work. For an example my own favorite output pattern is loosely based on model-view-controller. It's entirely based on template files, and comprised of a shared front controller, template-specific controllers and view scripts, partials, and layouts. The result is a structure that in my opinion can be easily adapted to all kinds of sites, applications, and so on. Would I recommend this as the first thing a complete beginner should learn? Probably not

Sorry, had to debug a bit further. Looks like it's caused by something called "ssc", whatever that is. Disabling the "ischrome" check fixes the weird scroll issue, though this probably means that this behaviour is (for some reason I can't quite grasp) intentional if (ischrome) { ssc_addEvent("mousedown", ssc_mousedown); ssc_addEvent("mousewheel", ssc_wheel); ssc_addEvent("load", ssc_init) }; Edit: Looks like that's the SmoothScroll you mentioned.

Weird. On two separate Macs I'm seeing the same issue, but it only seems to affect Chrome. Scrolling speed is normal on Firefox and Safari

First of all, the sites are all look awesome. Not that I would be surprised, but just saying Perhaps it's just me, but there's one odd thing on all but the Roger Shapiro Fund site – the scroll speed, that is. Not the first time I've come across this, so perhaps it's something I should recognize, but I'm having trouble scrolling the sites with my touchpad. A small swipe sends me flying to the bottom (or top) of the site, and scrolling slowly through the content takes some serious effort. Any idea what that's all about? Other than that, can't find anything to complain about

Should probably be noted that the wire() method in the Wire class is not intended as a constructor. See the code comments for a more in-depth explanation. Edit: not the first one to note this, I see

If those values come from other fields, you could always use the Textarea Markup module to achieve this.

That's true. Still, there are some reasons why you might want to update sites anyway: If you're hosting and supporting multiple sites, it's more overhead when they have different versions of the system running Updates often bring in new features – such as hugely improved image management tools – that your customers might want to use Not having known vulnerabilities in the core or third-party modules in the modules directory so far doesn't mean that these can never ever appear; especially when you're working with third party code, it's good to keep track what you're using and where, and for this reason alone a centralized management platform can be quite useful We're hosting quite a few sites and for this purpose I've built an in-house solution that does pretty much what you've described here. The focus is on making management of a large group of sites effortless and providing automation for common tasks, but this platform is also used to keep track of site-specific features, versions, usage, and so on. There's little chance of opening our in-house solution to larger community, but the thought of building something similar and open-sourcing it has crossed my mind a few times. Potential user base for this would be somewhat limited for the time being, but this is definitely something to keep in mind in the future

Should also be noted that there are multiple ways around this, depending on the larger context and your needs: If the booking system provides support for event-based actions and you need real-time data for your ProcessWire site, you could do what adrian mentioned above; make the booking software bootstrap ProcessWire and create new pages (or populate ProFields Table field or a custom database table of your own) for your reservations. If the reservation data doesn't have to be real-time and you have proper control over your production environment, you could create a cron job to fetch data from the booking system (assuming that you have access to it via an API or database). If you only need the data for view purposes and have access to the database that third-party booking app populates, you could just use ProcessWire's $database API variable and query it on the fly. The most important considerations here are a) do you need the data to be real-time and b) can you tap into the third-party systems events in order to bootstrap ProcessWire, does it have have a public API you can query, or do you have direct read access to its database.

Hi. Me. On just about all sites I've built in the past few year, both my own ones and those built for clients. Layouts consisting of blocks or "widgets" created via PageTable or Repeater fields have their use cases, but for regular content CKEditor works just fine and provides a sensible balance between flexibility and structure. It's true that getting CKEditor to behave takes a little bit of effort, but on the other hand I've noticed that most people familiar with the eccentricities of Word tend to be very much at home when it comes to CKEditor I've use Hanna Code in some specific cases, but to be honest it hasn't really been that helpful. Most non-technical users prefer the interface of CKEditor ("it's like Word") and strongly dislike anything that feels like "coding". Even those users who get it tend to forget which snippets the site has and how they work (which is why I built the Hanna Code Helper module in the first place). Like Joss already pointed out, it really depends on what you're building, and for whom.

PageTable is particularly handy if you need control over where the data is stored. Repeaters handle this part automatically behind the scenes, but with PageTable you have more options, such as making stored items children of current page, etc. In some cases the UI of PageTable is also preferable. Of course there's also the free vs. commercial point of view: with PageTable you get the multiple templates feature right out of the box, but with Repeaters you'll have to get the (commercial) Matrix version in order to pull that off.

The problem is very likely something not visible in your post above. Testing with the setup below, I had no issues getting this to work under latest version of the devns branch: <?php # /site/modules/TestHook.module class TestHook extends WireData implements Module { public static function getModuleInfo() { return array('autoload' => true); } public function init() { $this->addHookAfter('WireHttp::send', $this, 'hookCheckAuth'); } public function hookCheckAuth(HookEvent $event) { die("dying"); } } <?php # /site/templates/basic-page.php $http = new \ProcessWire\WireHttp; $http->send('/');

(Sorry, couldn't resist. English is such a wonderful language, don't you think?)

Thanks for updating the roadmap, and a Happy New Year to you too, Ryan! We've got some great things coming this year, no doubt about that Though we might want to discuss this eventually in a separate thread, inspired by Mike's comment above here are some initial comments regarding the site redesign. I'm trying to be as constructive as possible here, so please forgive me for just stating negative things; there's a lot of good too, but right now I feel that it's more useful to point out things that don't feel quite right. I've mentioned this before, but what I would love to see would be more clarity in regards to navigation and structure. For most parts those are the same thing, but there are also things that are only related to one. The visual side of the site could perhaps use a facelift too, but I wouldn't consider that a top priority right now; in my opinion there are more urgent issues to address, and the site doesn't feel all that outdated to be honest. Great design transcends time and so on Perhaps the biggest inconvenience for me is that the hierarchy of the site is not really reflected on the navigation. Topmenu items are not items at the top level of the page tree (except that some are), subnav items are often links to other sections of the site or completely separate (sub)sites, etc. One key strength of ProcessWire is the page tree approach, which makes structure sensible and easy to follow. I would like to see that benefit in action on our own site too. Other than that, I feel that the structure has pretty much grown in an organic way, and as a result of that things are not always where I'd expect to find them, and sometimes adjacent pages feel entirely different in scope. Some pages appear in multiple places, which can also get confusing, though in those cases they're usually redirects to somewhere else on the site. All in all the content architecture of the site doesn't feel very concise to me. In regards to the subnav, I would like to see some minor usability improvements in upcoming versions. For an example, the first item of the menu is actually the parent page, but visually it's in no way different from its children, which makes it less obvious than it could be. Also, while I still feel that a dropdown menu is often bad for usability and accessibility, it could also take away some of the pain related to "things not being where I expected"

Just checking, but.. is this the Markup SEO module?

Agreed. This is a surprisingly common gotcha for regular users. Opening the page tree again to unselect selection is not very intuitive.

You're making good points there, but to be completely fair that's your point of view. I'm not so sure that Ryan feels that way, and I certainly wouldn't. Even if it's just a question of committing some changes to separate repository and keeping track of two repositories for issues etc. in my opinion it seems like added workload and complexity compared to current situation. The point with .htaccess is that while you've suggested this as something that would make upgrading as simple as one git command, the .htaccess file is exactly why this isn't true: it may require manual changes, and thus that single git command is only a partial solution. Note that I'm not saying that making the index.php file a placeholder would be a bad idea in itself; I'm referring to the bigger context here. Finally, I believe that you can already upgrade your site with a "git pull". The only downsides I can see are that a) it won't upgrade index.php or .htaccess, b) you'll probably have a bunch of unnecessary site-* directories, and c) it will also pull in some other unnecessary files, like a htaccess.txt (.htaccess should prevent direct access to these). Please correct me if I'm getting something wrong here, writing this in a bit of hurry and probably not thinking everything through

Modesta actually works quite nicely with 2.7.2, as long as you install the latest version as an admin theme module. The issue with 3.x needs a bit more debugging.

Not much to go by there. Checking your site out did bring one new method to mind, though, so perhaps I'll be able to catch even these cases soon.. Probably need to make the rules visible on the isit.pw site too, so that people can actually prevent detection if they so choose.

What's even more odd is that this link gives me "yup". Either I'm doing something wrong here, or there was some kind of temporary glitch in connections or whatnot.

Use cases I've seen in the wild: Get a page at "/news/". Site admins have access to this page, and thus someone could replace a page in that URL with something entirely different, or unpublish it expecting it to disappear completely. Get a page matching user-defined search query etc. from URL-segment, GET param, or something similar. Selector is nicely sanitized, but that doesn't do much unless permissions are checked separately. The answer to "otherwise why would you get() it" is often as simple as "because I want to find one page." In other words it's used as a syntactic sugar for something like $pages->find("some-stuff, limit=1")->first(). To my best knowledge findOne() is rarely used, but there the potential for confusion is actually even bigger, just like we can see from Martijns reply above. You're absolutely right that there are no problems as long as the dev checks permissions manually. What I'm saying here is that in my experience so far this is surprisingly often unexpected behaviour. Some devs will assume that the system automatically skips over pages current user doesn't have access to. Whether or not that's a reasonable assumption is another question entirely. In a way this might be similar to "should content be escaped automatically": in my opinion it shouldn't, but numerous times I've had to remind others about properly escaping content before output – or in ProcessWire's case enabling certain field settings. Twig and other templating systems seem to gravitate towards autoescape, making output of raw content a conscious decision, which is actually a great design decision in that context. The whole get() vs. find() thing is probably just something to be more adamant about when instructing new users, but when I see a mistake like this made often enough, I tend to get worried. Obviously you can't avoid all such cases with a system as flexible and unobtrusive as ProcessWire.

Just sharing real-world observations. This is a point of confusion for some devs, including me, and thus I believe it makes sense to ask whether it's working as expected. As always, if the general consensus is that it works exactly as it should, then it probably does, and the disagreeing minority should just suck it up. Either way, when it comes to questions that involve security, I tend to gravitate towards the most obvious and fool-proof approach possible