teppo

@Pierre-Luc: that's good to know, thanks! Perhaps it's that I've missed what this thing is all about, or just a question of workflow, but at the very least this thing should be properly kept up to date, preferably automatically. It should also allow switching between versions, while we're at it. Only thing worse than no documentation is unreliable documentation. Anyway, even if we forget the public vs. private API argument for a moment, what's the real benefit this thing provides in comparison to, say, GitHub repository? Is it a presentational thing, i.e. a list of objects (and another of exceptions etc.) instead of files in directories, tables instead of DocBlocks, no code instead of full code, and so on? If you could explain exactly what the extra value is that ApiGen provides, I would be happy to see if I could, perhaps, help with the "keeping it up to date" issue, so that it becomes actually reliable. Personally I'd prefer more people working directly with code instead of adding weird layers on top of it, but if there's demand for something like this, at least we should do it properly

Regarding this, Ryan did originally raise some points about the (intended) public API vs. features intended for internal use only, which this tool doesn't always distinguish properly. I'm going to agree with those points, and perhaps even take them one step further, by stating that in my opinion this is not useful at all, and should be deleted to avoid unnecessary confusion. Considering that it was last generated for ProcessWire 2.2, it would seem that I'm not entirely alone with that opinion either If you need to know how specific object behaves or what methods it has, this provides very little (or none at all) benefit over looking it up from GitHub where you'll also see the code, changelog, etc.

You can always just store the values to variable and see if it's filled. Also, note that PW provides a native way (shortcut, really) for getting the first non-empty field value: $item->get("field1|field2|field3") etc. // like this: $price = $item->get("price1|price2"); if ($price) echo "From: € " . $price; else echo "please ask"; // this works too: $price = $item->get("price1|price2"); echo $price ? "From: € " . $price : "please ask";

@gebeer is right, this has very little to do with ProcessWire, and doesn't belong to General Support. Dev Talk is technically reserved for "development and coding discussions", so I'm moving this to Pub instead. Please feel free to continue the discussion there

Yeah, that explains it perfectly. In fact, if I open www.thesharktankproducts.com/products/ I end up at index.php?it=products/. The problem is that you're doing your own custom redirect after ProcessWire has already rewritten the URL to index.php?it=some-url You might want to take a look at ProcessWire's default .htaccess rules. There's similar www redirect there, though it works the other way around: non-www URLs are prefixed with www. The important thing is the position of this rule in the .htaccess file; you'll want to add your custom rule to similar position. Generally speaking, though, redirects like that should be placed as early as possible in the .htaccess file, since that's the most efficient way: you don't want to parse any extra rules, if there's going to be a redirect that makes it necessary to go through that very same process again anyway.

That GET param ("it") is what ProcessWire internally uses; a request to example.com/categories/food/ gets passed from .htaccess to index.php as example.com/index.php?it=categories/food. This explains why these work, but not why they're showing up in your analytics data So far my best guess would be that, for some reason, sometimes an error happens somewhere, causing such URLs to become visible to visitors, including robots. I did notice that Google has indexed some of these URLs, so it's actually possible that this error doesn't even happen anymore. Google is quite good at holding on to indexed pages, even if there are no more links to those pages If you want to debug this further, the first question would be if you have any custom rules in your .htaccess or anything like that. Something that could clash with existing rules there? I'd also suggest taking a look at your error log files (Apache and PW) to see if anything weird shows up there related to these URLs.

Just for the record: this topic isn't related to module development or any specific modules, so I've moved it from Modules to General Support

Nope. That's just what the rules wrapped with FilesMatch-checks do. If you take a closer look, you'll spot that some rules are defined without any FilesMatch rules: <IfModule mod_headers.c> ... Header unset ETag Header append Cache-Control "public" </IfModule> Of course you can specify whatever value you want to for these headers. What @LostKobrakai mentioned above is possible too, but I mostly prefer to use that for headers that depend on very specific page settings, need to contain some page-specific details, etc.

Easiest way to define custom headers is to do it in your .htaccess file, using mod_headers. WillyC's post about caching settings is a good example.

The errors you're seeing definitely sound like the $config variable would be somehow faulty -- either not initialised properly to start with, or perhaps something overwrites it later on. So far it doesn't sound familiar, so I would probably start by testing what exactly "$config" is, at various points in your index.php. Probably the easiest way would be using echo() or die(): echo "Config \"" . $config . "\" is: " . get_class($config) . "<br />"; .. and then all the regular questions: Is this a shared hosting account or private server (or perhaps local installation), and are you sure that nothing has changed server-side lately? Have you moved the site to new host, new directory on the same host, or anything like that? Have you made *any* changes to /site/config.php or /wire/config.php? Have you updated ProcessWire or update/added/installed/uninstalled/removed any modules? Is there anything else in the error log, PW or Apache? Do you see anything else if you enable debug mode in your /site/config.php? What version of ProcessWire are you using?

I'm a bit confused here to be honest, but.. does the module work for you now, or is it still not installing? What you're describing above shouldn't be necessary, but if that fixed it for you, then that's very good to know. Install/uninstall methods are not needed for this module, since it doesn't actually do anything special during installation/uninstallation. They're mainly for cases where a module needs to do something like add new fields during install, and perhaps remove those during uninstall -- stuff like that. Assuming that this is/was the same issue that was posted here before (requires not working at all), its a bug with modules directory. I've just pinged Ryan about that, as it seems that the issue was more or less forgotten already.

When it comes to pure PHP regex testing, http://www.phpliveregex.com/ beats the crap out of every other tester out there. (Though regex101 looks pretty neat too.)

@ceberlin: so far this is working just fine for me with latest dev PW. I should probably set up a clean site to test this on, but meanwhile, are you seeing any JS errors in your browsers developer tools? Also, which browser (and which OS) are you using? .. oh, and which admin theme? Another helpful thing would be checking if this particular line of JS appears in your admin template's HTML source. If it doesn't, the issue is most likely a PHP one, but if it does (and this module still won't work), it's more likely to be some sort of JS problem.

While MODX and Symfony are probably great systems, their goals are not necessarily the same as ours. I don't think that anyone here (or anyone in their right mind, for that matter) would ever deny that standardisation is a good thing, but I do believe that Ryan is doing the right thing by always putting things in the right context -- which, in this case, would be ProcessWire, it's target audience, and their needs. Also: all good things take time. Even if we don't act instantly, it doesn't mean we won't act when the time is right. This really isn't something that is going to happen overnight, and sometimes we just need to be patient By the way, I'm absolutely not trying to discourage discussion. I just hope that we're all on the same page here: no-one is opposed to these ideas, and I'm sure we'd all like to see them discussed even further, but especially bigger and more fundamental changes need to be properly evaluated first. "X does it like this" doesn't necessarily mean that it's the best thing for us to do, and so on.

@Soma: relatively easy "solution" would be forcibly loading the ProcessLoginHistoryHooks.module file in ProcessLoginHistory::construct, but I'd like to avoid that if possible -- feels like a hack, might not completely fix the issue, and I'd really like to know first why this is happening out of the blue. The symptoms made me wonder if it's just a question of load order (that's something I've had various issues with before), but on the other hand the hooks module not showing up in installed modules makes me wonder if it's something entirely different I can't seem to reproduce anything you've mentioned here at the moment. I've heard of somewhat similar issues before (in fact just a few moments ago I replied to a report where similar issue was affecting my VersionControl module), so I believe that this is a real issue. Is there anything you can think of that could've caused this -- updates, environment changes, corrupted files (cache/other), automatic processes running wild, or something? Have you updated/installed other modules, perhaps using built-in tools or modules manager, or something? Would love to get my hands on an installation where this "disappearing modules" error occurs, but it seems kind of random and usually only happens on real-world sites. So damn frustrating For the time being I'm going to take a closer look at changes to Modules.php. Looks like there have been quite a few of those recently, so perhaps something is actually broken/changed..

Wish that wasn't necessary, but adding support for some of the "more advanced" features (like binary file versioning) to pre-2.4 PW just didn't seem feasible. Hooks that these features require aren't there, etc. All in all I just felt it was better to leave this module as-is (in case someone stuck with pre-2.4 PW needs limited version control features), fork it as a new VersionControl module for later PW versions, and get on with it

@Mike: Just gave this a try, and I can't seem to reproduce either issue. At what point exactly does the "Method Page::snapshot ..." error appear? When you load the page, when you hit preview, when you try to restore earlier revision, or somewhere else? Do you see any additional details, line numbers, etc.? So far I'm thinking that it might be some weird compatibility issue (PHP, other modules, something) or perhaps a problem with autoload order -- though I might be totally off the track here too. Would be much easier to debug if I could somehow reproduce this Another issue seems to be out of my reach too. Same workflow works for me as expected. In fact, I'm having trouble understanding how this could even happen in the first place -- if the field is enabled via Version Control module settings and other enabled fields are working as expected, this sounds really weird. If you can reproduce this, could you check that module config is actually saved to database? Other factors that come to mind are some sort of (opcode) caching, and perhaps some installation weirdness related to either the native GUI install/update tool or modules manager. Absolutely not trying to pass the blame, but from what I've heard, both of these have had some issues. Never really used either one myself, which might or might not be the reason I've never had any installation issues either..

@horst: sorry, no idea. I don't see any reason to use this module over VersionControl on a 2.4+ site, to be honest

Thanks! To be honest this seems to be out of the scope of this module. I've been going over your suggestions a few times in my head, and while I think I could probably implement something like that to this module if I really wanted, I don't really think it's a good idea. Drafts would most likely be easier to implement using a completely different approach. Ryan took some steps towards drafts support a while ago, so you might want to see where that goes. If Ryan implements that as a core module, I've no interest in trying to duplicate similar behaviour here. Though I haven't used any of those that much, there's also Process Preview by Nico, Page Draft Creator by Rob, and Process Page Drafts by Jan Romero; you could always give one of these a try.