teppo

This is quite a change to current implementation, but I'll have to agree. A split button is widely used and well known pattern, while the delayed dropdown we've got now is pretty much unknown, at least to me.. and probably most regular users.

Perhaps I'm missing the point here, but why don't you just add a textarea field for custom CSS and output the contents of that in your template files?

Glad I could help

As far as I can tell, there are two solutions to your issue: <?php namespace ProcessWire; require 'index.php'; var_dump(new Page()); ... or: <?php require 'index.php'; var_dump(new \ProcessWire\Page());

If you want HTTPS for the entire site, do it via .htaccess. That's more efficient. Template setting is an easy way to force it on for specific templates only.

Your translation is technically correct, but so far no-one has tried to force a maid's uniform on me. To answer your question, I bet I'd look awesome in one of those. As a potential downside my credibility could take a slight hit in the process. Seriously speaking "financial officer" or something along those lines would be a better translation in this case

I have two of my own sites (weekly.pw and streetworkoutpori.fi) running on 3.x and so far everything has been pretty smooth. When I initially updated ProcessWire Weekly from 2.7 to 3.x I had to go through some hoops and a few modules were not working as expected, but most of those were related to early issues in File Compiler. Now that these issues have been fixed, I would say that 3.x is relatively stable. The sites I've built from scratch using 3.x never had any issues. Since 3.x is a development branch, you might want to wait a few days after Ryan's "friday updates" before updating your site, especially if it's already live, though. That way you can make sure that no new issues were introduced

@porl: I'm not aware of any solutions specifically built for 3.x yet, apart from the simple tag replacement module File Compiler Tags bundled with the core package. While someone will no doubt put together a File Compiler based templating engine module in the near future, currently your best bet is going with one of the existing solutions (such as Template Engine Factory @pwired linked to earlier).

This sounds almost like the proposal in issue #1619, though assuming that you're talking about the ability to filter the whole Page List at once the scope is somewhat different. Anyway, if I got this right I really like the idea

Compiled template files are a 3.x feature, so this specific issue won't affect 2.7.x. I can't really tell from the screenshots which specific version of 3.x @abdus is using, but it sounds like updating the system to the latest version from GitHub just might do the trick.

Same thing here. As long as Ryan doesn't add a native setting called "siteSettings" – which seems quite unlikely – all is good

Was going to write a longer reply, but BitPoet already summed up most of my thoughts One thing I'd like to add to the "benefits" section is that with ProcessWire you can be certain that you won't run into issues if that "simple site" needs to grow. Sure, you could always ditch all you've got and start from the scratch, and sometimes that's a good idea anyway, but ProcessWire is more than capable of handling both small and large needs. That being said I don't really know CloudCannon that well, so it might also be capable of handling larger needs, but based on what I've seen so far that doesn't seem very likely. At the very least their pricing model ($$ per month per user, if I understand it correctly) would make CloudCannon really expensive for most of the clients we work with

Here's the latest version of the MVC-ish structure I was referring to in my previous post, in case someone wants to take a peek: https://github.com/teppokoivula/pw-mvc/.

Thanks for setting this up. While it's important to note that methods and such found via this are not necessarily intended as public API, and may be subject to change in later versions, I think it provides a good middle ground between pure code and manually edited docs Since you wanted feedback, one point I'd like to mention is the theme. This is partly opinion-based thing, but I find the light color scheme of the earlier apigen thing more readable. In the dark theme especially the dark lines tend to disappear, and some of the colors (such as the red headers) kind of make my eyes ache.

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