teppo

Our main audience are currently web designers/developers that require a platform that does most of the heavy lifting for them, but allows them to freely modify data structures, markup, and even back-end functionality of their sites. WordPress, on the other hand, is famous for trying to cater for all kinds of users – even those who don't ever want to touch or see any code *or* markup at all. As a result they're not particularly good at anything and just trying to keep their current codebase in good shape seems to be nearly impossible task. I'm not saying that ProcessWire is already as good as it can get – quite the contrary. We've taken huge steps in so many ways in just a few short years and will no doubt continue doing so in the foreseeable future. The point I'm trying to make is that "converting all WordPress websites over" isn't necessarily a goal worth striving for. At the very least that's not what motivates me personally. Correct. Site profiles provide a starting point, and after installing one of those you can customize your site as you see fit. While I have no idea what you mean by "making it custom", the thing is that site profiles in general are not interchangeable like WordPress themes. This is what I was referring to in my previous post: we've had some discussion about agreeing on specific fields, based on which we could develop interchangeable themes. Not entirely sure what's up with that project right now, but it sounds like this might be something you'd be interested in pursuing too. Actually you could make any module output styles, and some modules already do that. Some existing options include using the $config->styles or $config->scripts arrays (though they also need to be included in your markup somewhere), altering generated markup with a page render hook, and simply outputting styles or scripts in the middle of generated markup. I'll have to agree that these may not be exactly clean solutions at all times, but on the other hand, have you ever debugged a WordPress site with a ton of plugins adding their own styles/scripts? Trust me, "clean" is not how one would describe that either In my opinion this is a very cool idea, but absolutely not something the core should do. Without going into specifics, nothing you've mentioned so far can't be done with a third party module. If this is something you feel is missing from ProcessWire, feel free to give it a try. You might even find some like-minded people here who'd be willing to help. In some ways I'll have to agree, but it's really not that simple. WordPress a) was around at the perfect time, b) decided relatively early to cater for the needs of everyone out there, c) doesn't care about how they're perceived by the technically adept audience, and d) doesn't care how much technical debt they amass in the process. I don't think that any platform can really take them head-on when it comes to number of users: at this point their popularity is also their biggest asset (assuming that "being the most popular platform out there at any cost" is really a sensible goal.) Agreed, and we *are* already expanding our audience. You haven't missed the Composer stuff we've been adding lately, have you? It's just that we've been aiming for expanding our audience to a slightly different direction than you had in mind I hate repeating myself, but I'll do it anyway: build a module. Publish it. If it's awesome and a lot of people love it, it has a good chance of becoming a core feature one day.

Currently we're catering for this need with Markup modules, site profiles, and to some extent Textformatters. In my opinion these are all "easy ways to share design". If these are not enough, you could also share template files and smaller snippets of code, but considering that each site may have different fields in place, that only works as long as you also standardize those fields. There has been some discussion about this too, but more as a community project than something the core should take part in. If you're using the devns branch, there are also field-level template files. These would be much easier to share between different projects, so I'd suggest taking a closer look at them. I've built quite a few sites using ProcessWire, ranging from very simple one-page sites to news and intranet sites with (tens of) thousands of pages. I've never felt that the API "only works for simple websites". Admittedly I've used SQL on some extremely rare occasions, but that has mostly been due to the fact that I've either had a custom database structure too, or I've needed to optimize a potentially slow query for just one very specific task. Assuming that the API is awesome for *at least* 95% of use cases (that's my impression anyway), I don't really think we can state that it's "not good enough". For use cases that a few people here and there might face in some rare situations it's entirely acceptable to figure out a custom solution. Just checking, but you do realize that you could easily add a custom queryArray() method to $pages API var and even publish your solution as a module if you feel that it has potential for wider use, right? That being said, I'm not against this feature per se. It's just that every added feature also adds complexity and the core absolutely shouldn't contain features that are known to be used extremely rarely (not entirely sure if that's the case here, but based on my experience so far it very well might be.)

To be honest I'm not particularly worried about the amount of issues, but I do agree that it doesn't look very good for a random visitor. The obvious solution to the "too many open issues" issue would be two-fold: Get rid of all the "fixed" and "not a bug" tags. If an issue is fixed it should be closed, and if the fix doesn't work it can be reopened. If we want to get rid of as many issues as possible, we could move feature requests to another service. Personally I would vote against this. In my opinion closing unresolved issues, whether old or new, should never be an option. "Can't reproduce", for an example, doesn't mean that the issue isn't real. Just my two cents.

jQuery-inspired is in my opinion the best short description of our API. "An easily approachable and powerful API" is way too generic, especially since the jQuery connection is actually an important point. ProcessWire's API is modeled after jQuery, after all, the general idea being that "if you know jQuery, you'll learn ProcessWire development in no time". On a related note, personally I prefer to discuss it as the "developer API", not just API. On a couple of occasions I've had to specifically explain that ProcessWire doesn't actually expose a public API automatically. The Finnish translation ("rajapinta" vs. "kehittäjärajapinta") seems to be even more prone for misunderstandings

In my opinion this is a good idea, though it should be made clear that feature x getting a lot of votes doesn't mean it will be implemented – just that it's what most users voted on. If product development was all about "ask the crowd what they want and do it", products like ProcessWire – ones that dare to approach things from a different point of view – wouldn't exist. We'd just have a ton of WordPress clones. I'm not sure where I've heard it from and if it's even really true, but they claim that Nokia once asked their users what were the main griefs they had with their phones. The one they heard most was that the battery was drained too fast. For a long time their phones had terrific batteries, but in all other aspects they were way behind companies like Apple who literally decided not to listen to their customers. Sorry for going slightly off-topic, but my point here is that while it's good to ask what your users think, it doesn't mean that you should always do as they tell you. It can, nevertheless, provide you with new ideas and feedback regarding the direction you're going with your product. The idea is good, but needs to be put into right context

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.