teppo

@adrian: to be fair I was about to mention Batch Child Editor, but in the end couldn't think of any solid benefits for pages vs. integers. Now that I think about it, I guess you could do something like use a specific template for your year pages and have them render all related items right there.. which is pretty neat. You could do the same thing with URL segments without having those pages there (this is what I've done in at least one project), but a page-based approach would, at the very least, be more obvious. So yeah, there are some valid reasons to use pages That being said, I do have to point out that each page is actually a bit more than just a row in the database, and while ProcessWire can handle tremendous amounts of pages without breaking a sweat, often they are not the most efficient solution.

I haven't followed said tutorial myself, but I probably wouldn't store years as pages. What I would rather use for storing a year (and nothing more) would be an integer field, or if it really has to be a dropdown on the page editor, I might use an Options field instead. Just my five cents

Actually there was no need for version_compare(): hooking into something that doesn't exist doesn't seem to cause any issues. While hooking into savePageOrFieldReady would make sense, at this point I'm not ready to ditch 2.x support, and since that's not an option, I don't really see any benefit in it Latest version, just pushed to GitHub, fixes one minor bug and adds support for saveFieldReady.

@arjen: thanks for notifying me of this. The solution posted by Ryan a bit later (hooking into both Pages::saveReady and Pages::saveFieldReady) should be relatively easy to implement, but the problem is that Pages::saveFieldReady was added in 2.5.10 and this module currently supports >= 2.2. This could mean either jumping through some extra hoops or dropping support for a couple of releases. Anyway, I'll take a closer look at this soon. What would've been awesome was if Pages::saveReady worked consistently across all revisions, but it is what it is

Another update: the latest version logs multi-language name changes as renames. The implementation is a bit hacky since core doesn't trigger a renamed hook in this case and also doesn't track previous name etc. like it does for the default name field. The output also doesn't mention the language specifically, though that's something that could be added later on. Please let me know if you have the chance to give this feature a try and happen to notice any inconsistencies. Thanks!

First things first: what do you need this for? If it's a style-related thing use attribute selectors instead. Basically the same thing goes for JavaScript stuff. If you really need a server-side solution to this, the polite thing to do would be giving it a try yourself before asking someone to do it for you. That being said, what you are asking for would mean a) checking that the link isn't relative (href="/foo/" or href="index.html") and b) checking that it doesn't point to your own site (href="your-own-site...) It's really not a very difficult thing to do if you put your mind to it, so why don't you give it a try and if you run into any issues ask help with those?

Sorry, folks -- looks like I managed to overestimate the amount of time I'd have for this module. Anyway, I've just pushed version 1.3 to Github, along with a new module called ProcessChangelogRSS. Here's the gist of this update: If you access the changelog via /setup/changelog/rss/ you should find an RSS feed for the module. This feed requires the same permissions as the regular changelog view, i.e. you have to be authenticated and have the "changelog" permission. Since the RSS feed might have valid use cases where authentication is an issue, an optional ProcessChangelogRSS module is now included. After installing this module you should go to it's config screen (in the Modules section) and type in a key of your own. After that you can view an RSS feed of changelog events at yourdomain.com/process-changelog-rss.xml?key=your-very-long-and-complex-key. I don't really know how important this RSS feature is going to be, so didn't want to spend too much time on it -- this is why the description of each item makes use of the same tabular output as the main changelog view itself. Originally I had planned to implement multiple keys and such, but in the end decided to strip all that away and go with the most basic implementation possible. Feedback on these features would be appreciated, but please note that if you do enable the ProcessChangelogRSS module, the changelog RSS feed is publicly available, even if only for those who somehow gain access to your private key (or are somehow able to guess it). If you are uncomfortable with that, please leave it uninstalled.

To be fair I've never had any major issues with permissions in ProcessWire: Built-in RBAC system fits most needs easily, for page-and-group-level access management we've built the UserGroups module, the DynamicRoles module provides a lot of flexibility when you can't make pre-defined groups/roles work, and, finally, when none of these approaches work I have always been able to check permissions programmatically. Sure, the last part requires some custom work and thus it's obviously not something you can just pull out of the bag and set up with a couple of clicks on some GUI.. but, unless I'm missing something obvious, this is true for most other frameworks (such as Yii or Laravel) as well. Finally, I'd like to point out that if you find yourself in a situation where the permissions on your site constantly change and there are no logical rules to define them, thus making even programmatic permission checking impossible, I'd be tempted to say that it's not a problem with the system but rather within your own design.. or, rather, the lack of it Regarding the original questions from @DL7: Depending on your time frame and definition of "60% done", I'd say that while all of this falls nicely into ProcessWire's domain you should consider finishing your first version on the current platform and then, perhaps, merging it to a more flexible platform like ProcessWire. You've mentioned multiple times the need for "custom development", so I'm not really sure if you're not comfortable with this or if it's just something you see as a benefit of ProcessWire. Either way, you should realise that with ProcessWire you will no doubt have to do custom development too. We don't have a module for everything (we're not WordPress). That being said, ProcessWire is quite likely much friendlier to develop with than your home-baked system and we have a wonderful community you can ask specific questions from. There are also some modules that could help you a lot, such as DynamicRoles and, perhaps, the commercial FormBuilder. While you can no doubt integrate your custom-built solution with ProcessWire and you can even perform direct SQL queries from within your ProcessWire template files and modules in order to utilise your own database tables (see the $database API variable), I'd strongly suggest that you don't. 99% of time using a custom database means that you are not making use of ProcessWire's features as well as you could. In some cases I've found it useful, but those cases are really, really rare. All of the data structures you've mentioned can no doubt be done via regular pages, for the editing part you could consider using the regular page editor, and you might even be able to pull this off using the built-in page tree, but if you need something more customised, you might also want to look into developing your own custom Process module (which is what I've used for a few similar use cases before). The commercial ListerPro module is another useful tool in this regard, so don't forget to check that one out too. I'm not going to try and provide you a ready-to-use structure (or page / field strategy) for your site, but feel free to draft something out and post it here so we can comment on it. Generally speaking if you have a specific question or an idea / concept you'd like to get comments for, you'll get replies on this forum in no time, but if you ask others to do the groundwork for you that won't get you anywhere

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f Just saying.

Current programming playlist is a mix of Die Antwoord (they released a new album earlier this month so got some catching up to do), Little Big ("the Russian Die Antwoord"), and some random NYHC songs just to crank things up a bit every now and then. Works wonders for me. I'm pretty sure I've still got an LP from The Shadows somewhere. One of the first ones I ever bought and to be honest I'm not entirely sure if I've even listened to it properly – got lured in by the cover art and the rest is history..

Thanks for the suggestion. To be honest I was going to turn this one down (ProcessChangelog already provides JSON feed, so this could actually be a separate module), but I've already got a rough proof of concept ready and I think this has enough value to be part of ProcessChangelog itself. Hopefully I can finish this in the next few days (a bit busy right now). Definitely worth considering. Currently this module is limited to keeping track of changed page data, but I'm open for the possibility of tracking more than just that. I'll see if I can find an easy way to handle this (and a sensible way to output such content).

Thanks, but I'm still unable to reproduce this. Been running on debug mode, switching between multi-language and non-multi-language setup, so far no idea about this. I'm less worried about a notice and more worried about what caused it -- in this context it could be a sign of a more serious issue somewhere else, one that results in broken or malformed data. Which version of ProcessWire are you using? Any other tips for reproducing this? Anything you can share would be very much appreciated /cc @adrian Strangely I'm not able to reproduce this either. The values in the select menu should always be operation names (strings), not numbers. Is there a chance that you might've changed something related to this? Does anyone else see this? Thanks for clarifying these. As soon as I can figure out what's going on here, I'll be happy to apply a fix

Whether or not one would benefit a lot of Composer depends a lot on the type of work they do (like @szabesz already pointed out), the workflow they prefer, and a few other factors. I for one haven't seen any reason to really get into using Composer. It's not that I don't like it, mind you – I really do, and I actually wish I had more use for it, but I just don't. I do most of my work with ProcessWire, and most of the time I work on web sites: public-facing sites, intranets, extranets, directories of data, etc. I do custom development for those sites, applications if you will, and in many cases there's some server-side automation / integration involved. ProcessWire does out-of-the-box most of what I need to get that stuff done, I use some third party modules here and there, and PHP itself is a framework with a vast collection tools and extensions built-in. That being said, when I browse the list of the most popular packages on Packagist, I see some projects I've used in the past (using a basic download / git clone + require one file approach) and some that I probably could've used but usually have worked around with a few lines of my own code. Either way, these projects could've saved me a few minutes (or even hours) here and there, had I already been well versed in the Composer workflow. Now that ProcessWire supports Composer, I'm probably going to give it a try and see how it feels, but for the time being my opinion still stands: Composer is by no means something you "have to" use, even if you do so-called "serious development". It's one tool among others, and while some no doubt benefit from it greatly, for some it's of very little help (or potentially even harmful as it can tempt you to rely on a dependency for everything – left-pad, anyone?)

One more addition: testing with multi-language page name support, I'm seeing that the rename operations affecting only non-default language are not being logged as renames at all. Currently I'm thinking that this should be logged as a separate rename operation, i.e. if you change the name in multiple languages for the same page at once, it would look in the log a bit like this: renamed basic-page what as what-2 renamed basic-page what-in-finnish as what-in-finnish-2 Probably will implement it like that unless someone has a strong opinion on thi

Thanks, guys! I'm just now taking a closer look at these, and there are a few things I'd like to understand first. Regarding undefined indexes: @adrian and @SteveB, it sounds like you were both able to reproduce the undefined index problem. How exactly did you get there? I've been testing this with a multi-language setup and a non-multi-language setup for a while now, and can't seem to figure out the steps to reproduce this. As far as I can tell, this would mean that a page has been renamed or trashed, but there's no information about what the name used to be. Logically thinking that must be something that shouldn't be logged in the first place, or the problem is in the way I'm fetching the previous page name. Do you have any pointers here, what am I missing? Regarding RuntimeMarkup: I'm familiar with RuntimeMarkup, but haven't really used it, so my initial thought is that this doesn't sound quite right. A field should not report itself changed every single page load unless it really changes each page load, in which case logging these changes is the only sensible thing to do. Either way, one definitely shouldn't have to check for specific field types like that. Anyway, I'll take a closer look and see if there's actually a sensible reason why this is happening. Regarding non-working filters: @SteveB: If I'm getting this right, selecting an operation on the Changelog page results in a numeric GET param, such as "operation=3", right? I'm not able to reproduce this either, as the values in the operations dropdown are actual operation names, not numbers. Any pointers for reproducing this one? Thanks again for reporting these issues, and sorry for not being able to reproduce them..

Agreed. The effect is particularly strange in mobile: feels like perhaps it's one of those menu bars that disappear when you scroll down and reappear when you scroll back up, but nope; it's just a sticky menu with a weird bounce effect The font is a little bit too small for my eyes, but other than that the site is really clean and feels easy to browse. Great job!

Don't Make Me Think is a classic and applies to all kinds of UX/UI design. Nielsen Norman Group articles are also worth checking out; Jakob Nielsen in particular is one of the most prominent figures when it comes to usability research. Lots of stuff to add here, but I'll leave that to others

First thing to check is whether those requests look natural, even if just to rule out the off chance of a DDoS attack and stuff like that. Tons of requests to a specific page and usually something uncacheable (like search page with the same search term every time) is a telltale sign that someone is intentionally bombarding your site. It's also good to check where those requests are pointed at: if there's a lot of traffic to a specific part of the site at the same time when issues start, the problem might be related to that part too. Or it could just mean that a specific piece of content is extremely popular Most properly configured and resourced servers should be able to handle bot traffic with ease. There's the possibility of a misconfiguration and the settings of Apache, MySQL, PHP, etc. can always be tweaked in order to handle traffic spikes better, but if the root cause is that you're being harassed, there are other (and more efficient) ways to handle that.

Am I reading your graphs correctly, i.e. is there a notable increase in inbound network activity when this happens? If so, is that natural traffic (regular visitors browsing the site) or something else?

This is by design. See this GitHub issue for more details. It's not the most consistent solution, but admittedly I've found it quite useful too.

If the error occurs in Admin, it has nothing to do with your templates. It also shouldn't have anything to do with FileCompiler: you're running 3.x, so core files don't need to be compiled. Did you upgrade via git pull or something like that, or replace the wire directory manually, or how did you perform this upgrade? There's a slight chance that something is missing from the /wire/ dir, so one option is to remove and add it again (note that if this is a live site, the pubic site won't work at all while the wire directory is missing). Another thing would be checking that file permissions are fine, and make sure that the module you're trying to open works as expected. By "the module link is not working" you meant that you're trying to open the page related to some specific Process module, right?

Thanks, @BitPoet I'll take a closer look at the code changes soon. Meanwhile I've created a new issue to the ProcessWire repository regarding UserGroups issue #45 and the related change in the ProcessWire core. I'd like to hear what Ryan thinks about that before implementing any kind of fix for that.

Nope, nothing on this side either. Should find some time to test this soon.

@tpr: finally found time to take a closer look at the language tabs issue. So far there appear to be two issues behind the scenes: VersionControl stores all language values in the form of "data[language-id]", but the field name for the default language is actually just "data". I'm pretty sure this used to work at one point, so perhaps it was a core change somewhere between 2.4 and 2.6 (have to setup a test site with earlier version to make sure). When built-in language tabs are enabled, CKEditor instances are not loaded before a specific tab is opened. This is a bit of a problem, since I can't set a value of a CKEditor instance unless it's already there. This requires a bit of testing, but I'll try to get these sorted out soon.

Out of interest, which product are you referring to and/or how does one gain access to this free plan? The sign up only speaks of a 14 day free trial, and I can't seem to find this option on their site either I gave their application monitoring a try something like a year ago. Seemed really interesting, but sadly (at least at the time) it wasn't working too well for ProcessWire: knowing that most of my users interact with index.php or that index.php is eating the bulk of my resources wasn't exactly what I'd call "insightful"