teppo

Sometimes a little bit of Googling can be helpful: https://processwire.com/talk/topic/5693-new-module-type-wiremail/. WireMail is a core class that provides support for sending email, and in template context you can access its features through the wireMail() function. Native WireMail implementation is just an abstraction layer on top of PHP's native mail() function, but other WireMail modules provide different methods, such as SMTP support (which is a key part of both WireMailSwiftMailer and WireMailSMTP), or other features, like the WireMail Branding which wraps WireMail messages with custom markup.

Additional note: Ryan did mention this issue in GitHub, and he did also mention one potential solution: modifying the find query directly. In my opinion that doesn't change the fact that listable doesn't behave in a manner that one would expect, but it's definitely something to look into.

As far as I can tell, we're talking about the same thing, but from different points of view. In my use case I need to hide specific pages, which can result in all pages being hidden, in which case the issues I've mentioned before come up. You're hiding all children at once, which is a different thing.. unless I've misunderstood something about your code On the other hand, if I could do what you do there *in case that all child pages are hidden one-by-one*, that would be a potential solution. I don't think it would work that way though, because of the order things happen in.. unless I actually pre-populated the "hide children" info during page save, or perhaps iterated children on for each page in addition to targeting the pages that should get hidden directly (which might add a lot of overhead). Looks like I really need to revisit this sometime soon

Most prominent issues, I believe, are pagination and the case where all children of specific page are hidden and a weird half-functional opening animation is left in place. While I agree that most editors won't notice the off-sync child count, some still will, which will lead to more work for me and others managing the site. Sure, it's not much, but little things like that pile up and turn into noticeable overhead in the long run. I may have to revisit this at some point too, can't remember exact details anymore. While I get that adding performance overhead for a rarely used feature like this is a bad idea, at the moment I also find it very hard to consider this "working as expected". I even thought about altering the tree with JavaScript after it has been rendered, but that's kind of a volatile solution

Hey there! Just wanted to say that if you find a way to solve these issues, this would be very useful. The recent addition of "listable" support for page tree seemed like a great addition, but this issue makes it feel clunky, if not downright broken (in my use cases, anyway)

Yup, thanks Adrian! Had completely missed this one, but glad it (apparently) got solved

This is an interesting tweak, and a new config option for it doesn't sound like a bad idea either. If you'd like to get such a feature into the core, I would suggest submitting this as a feature request via GitHub issues. Either way, thanks for sharing this! (For the record, I've just moved this topic to the General Support section, as it's not strictly speaking related to modules.)

Usually I would agree with @SteveB on such "unnecessary" features, but the weird thing is that in this case I quite enjoyed the "typewriter effect". Combined with the overall style of the site, it felt almost mesmerizing, and made me focus more on the content. All in all browsing this site was an enjoyable experience – great work!

Topic moved from Off Topic > Dev Talk to Community Support > General Support.

Thanks for clarifying your intentions on the switch, Ryan! While FSF has a great goal in mind with GPL, making sure that free applications stay free, I can see how that could be perceived as a negative thing by some. It's also obvious that it could make it more difficult to work with other, non-GPL code – whether proprietary or just under a license that is incompatible with GPL itself. It doesn't really help that some other platforms, most notably WordPress and Drupal, have stated that in their case even the themes and plugins are always under GPL. While it should already be clear to most people here that they can create non-GPL – and non-open – modules and site profiles for ProcessWire, moving on to another license to avoid unnecessary ambiguity probably makes sense. While I honestly hadn't considered a situation where someone would like to release a larger application based partly on ProcessWire under another (possibly proprietary) license, again from the framework point of view this does seem feasible. While I wouldn't consider it a typical use case by any means (and in most cases I would also advise against such move), in this regard the switch does indeed open new doors. On a related note, once you push a change out there for everyone to see, the cat is out of the bag. Makes sense follow up with a swift explanation, like you just did here, though sometimes explaining such things in advance would be even better

They probably just thought that "hey, this fav/app icon/metadata stuff is a mess anyway, so where's the harm in adding one more to the list" <link rel="apple-touch-icon" sizes="57x57" href="/apple-touch-icon-57x57.png"> <link rel="apple-touch-icon" sizes="60x60" href="/apple-touch-icon-60x60.png"> <link rel="apple-touch-icon" sizes="72x72" href="/apple-touch-icon-72x72.png"> <link rel="apple-touch-icon" sizes="76x76" href="/apple-touch-icon-76x76.png"> <link rel="apple-touch-icon" sizes="114x114" href="/apple-touch-icon-114x114.png"> <link rel="apple-touch-icon" sizes="120x120" href="/apple-touch-icon-120x120.png"> <link rel="apple-touch-icon" sizes="144x144" href="/apple-touch-icon-144x144.png"> <link rel="apple-touch-icon" sizes="152x152" href="/apple-touch-icon-152x152.png"> <link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon-180x180.png"> <link rel="icon" type="image/png" href="/favicon-32x32.png" sizes="32x32"> <link rel="icon" type="image/png" href="/android-chrome-192x192.png" sizes="192x192"> <link rel="icon" type="image/png" href="/favicon-96x96.png" sizes="96x96"> <link rel="icon" type="image/png" href="/favicon-16x16.png" sizes="16x16"> <link rel="manifest" href="/manifest.json"> <link rel="mask-icon" href="/safari-pinned-tab.svg" color="#5bbad5"> <meta name="msapplication-TileColor" content="#da532c"> <meta name="msapplication-TileImage" content="/mstile-144x144.png"> <meta name="theme-color" content="#ffffff"> .. and yeah, the current situation is a joke, really. Everyone is just adding their own metadata requirements, because hey, everyone else is doing it too and, perhaps, partly because of some messed up "we're so special we can't use what others use" mentality. If only this was the one place where this is happening, but of course not. What about something like the Open Graph metadata? Great idea, except that every service implements it in different way, and then along comes Twitter who decides that they're way too special to use what others use, and require their own twitter-metadata in addition to a half-assed support for Open Graph. Sorry for the (mainly off-topic) rant, by the way

Superusers can use Page Edit to select templates that are otherwise not available. It's a feature, though admittedly a weird one

Not many specific use cases, beyond the general examples I mentioned in the README Some of my own modules have used their own database tables, partly for performance reasons, and partly because storing that kind of data on pages didn't seem like it would make sense and/or be worthwhile. Simple ORM like this can make dealing with such data easier and more enjoyable especially from developers' perspective; it's essentially a layer of abstraction, a middle ground between PDO and PW's API, and (at the very least) it can help avoid some extra rows of code. The specific use case for which I ended up building this module for was more or less similar to those existing modules: a Process module that handles custom data. In this case I found RedBeanPHP's fluid mode especially cool, as I could just dispense beans, add content, store the beans, and RB would create a schema for me automatically. RAD at it's finest, and at the end I could just switch to frozen mode, add some indexes, and be done with it Other than that, I would imagine that this could come in handy when dealing with content in external databases, or perhaps in SQLite databases. Haven't had many needs like that recently, but it's a topic that pops up even here sometimes.

RedBeanPHP is a simple and easy-to-use ORM, and this module is a lightweight ProcessWire wrapper and/or loader for it. The main task of the module is loading and setting up RedBeanPHP with database credentials from $config. There are some config settings for defining how RedBeanPHP should behave, and the module also exposes some often-used methods, but that's just about it. For more details (including a rant about why one might prefer separate ORM in some cases), take a look at the README file. Please note that, for almost all use cases, the data modeling features of ProcessWire are much better choice than a separate database structure of your own, but in those rare cases where that's not the situation, it's good to have options. This module was a side product of one of my own projects, and I thought I might as well share it with you folks. You can grab the module from GitHub: https://github.com/teppokoivula/RedBeanPHP.

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