teppo

@jmartsch, two notes about that: Session fingerprint is a security feature, and should only be disabled when absolutely necessary. In your case this might actually be the situation, pointing this out in case someone else reads this It's never a good idea to modify anything in the wire directory – instead of that, copy the directive to /site/config.php and change it's value there.

So far unable to reproduce this. With ProcessWire 2.6.20 dev (Reno theme) and PHP 5.5.21 mobile upload seems to work fine for me. The phone I'm testing with is Samsung Galaxy S6 Edge running Android 5.1.1 ("Lollipop"), and I'm using the native browser. One difference is that my sound recording app would only save mp4 or m4a, but this shouldn't matter at all for ProcessWire anyway. Edit: Did another test with a downloaded mp3 file just to be sure. No issues with that one either. Still unable to reproduce the issue.

Additionally knowing which version of Android you've tested with, and which browser you're using, would be helpful. There have been numerous bugs and missing features in the system, not to mention that even specific phone models sometimes seem to mess things up. I'll see if I can reproduce this using one of my own phones, though. So far it sounds like your phones are not sending the file extension properly, and in that case there are two likely scenarios: either the file didn't have an extension in the first place, or the file upload dialog (in your browser) is not sending it properly to the server. Hard to say without testing a bit more.

Not sure if I'm getting your question right, but why not simply check if the value of the field is an instance of PageArray: if ($page->field_name instanceof PageArray) { // iterate }

Your preference towards double quotes in HTML markup is purely visual. The browser doesn't care, users won't care, and if you enable minification via something like ProCache, it's actually possible that it might automatically remove some of those quotes altogether. In many cases the quotes are not needed at all, which means that they're just taking extra space. Regardless, my personal preference in PHP is to always use single quotes by default, and double quotes only if I really want to embed variables in the string. Using single quotes means that there's zero chance of accidentally inserting a variable, or really any string starting with dollar sign that would be interpreted as one. When I do want variables in the string, I prefer double quotes, though I also tend to use curly braces everywhere, regardless of whether they're "necessary": $editUrl = "data-mfp-src='{$page->editUrl}{$lang}&modal=1'"; Regarding editors: my opinion is that any decent editor should get highlighting right. If your preferred editor doesn't, consider switching. If syntax highlighting works in some cases, but not always, that's a potential source of confusion. In the end the style guide for ProcessWire is no different from other style guides in that many things there are opinion-based. If you don't want to use that in your own projects, you don't have to, but of course adhering to it could make working together with fellow ProcessWire users slightly easier.

@MisterM: first of all, great to hear that you're enjoying ProcessWire and the forum! To answer your question, I would simply use "Powered by ProcessWire". Seems snappy and obvious enough to me, especially if it's also a link to processwire.com

This is a valid suggestion. Here's a bit more about the same subject: https://processwire.com/talk/topic/3000-non-alphabetic-page-name/. I'm pretty sure that there is/was a GitHub issue about this too, but can't seem to find it right now.

Not saying that multiple branch support wouldn't be a cool feature for Admin Restrict Branch, but in case visibility is not an issue and you're looking into ways to restrict permissions per branch, I would also suggest taking a look at UserGroups and Dynamic Roles. The approaches are slightly different, but both modules already provide support for this.

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.