teppo

One more addition to answers above: you should take a look at Hanna Code module. It allows you to pull snippets of arbitrary PHP code into pages. This is what I've used to solve more complex needs, pages that need weird snippets etc. Typical issue with Hanna Code is that you won't be writing the code as files, so they won't be in your version control system etc. One way to solve this is to create Hanna Code snippets that include code from files and/or actually render pages. There's quite a lot that this little beauty can do, actually. Many of us "long-time PW users" have developed our own ways to work with PW. I'm using something similar to Zend Frameworks approach, with controllers, view scripts and partials, for an example. This is both a curse and a blessing with extremely flexible system like ProcessWire; you can create your own way to work with it, but especially if you're working on more complex stuff you'll also pretty much have to do that

Any chance that you've migrated this site (including users) from another server / PHP version? In any case this sounds like some sort of issue with Blowfish / PHP crypt function. One possible solution (though not one suggested in the long run, especially if this is a production site!) was provided by Ryan here. Quick Google search also returns a ton of related topics, so I'd probably start from there.

I'm in!

You could also check out UserGroups, also discussed here. As the name suggest, this module adds new concept called "groups" (ProcessWire, by default, only knows "roles") and allows you to specify page-based permissions for users belonging to these groups. Companion module PageListPermissions provides alternative, page-tree-based UI and in some ways makes things easier to manage. Word of warning, though: UserGroups isn't considered quite "production ready" yet, so tread carefully. Generally speaking it's more useful when your needs are slightly larger, i.e. you need a lot of different sections editable and/or viewable by specific groups of people. If you do try it out, any feedback is welcome

Thanks for that! I stand corrected; I did not know that requesting an absolute URI would result in Host header being ignored. That's quite interesting -- or "frightening" even, as one commenter there pointed out about the whole thing. Now the only thing I'm not getting here is that wouldn't it, in this case, make more sense to look for an absolute URI in REQUEST_URI and if found, use that instead of host header? I guess this wouldn't solve the problem for various dedicated hosting setups, though, so perhaps it's not really viable "global" solution. I guess I'm mostly annoyed about having to keep an up-to-date list of hosts in multiple places instead of letting Apache take care of that. So much potential for unexpected misconfigurations This is exactly what I don't understand -- why would I want to redirect user from HTTPS to HTTP when "view" is clicked? Not much of a problem usually, but I find it a bit strange .. and back to the original topic: Personally I still feel that this is a problem. When installed locally, PW offers "localhost" as the default httpHosts value. That's fine until you move the site to your web host and suddenly things won't work. I'm afraid that a lot of people won't really think twice about that setting or even remember it exists. Of course it might be just me who's got such a crappy memory, but I wouldn't be surprised if topics like this started popping up quite often. Not sure if there's any bulletproof solution to this, though (other than making this an optional security setting, that is -- and making security "optional" always sounds awful).

Isn't host header exactly what the server uses to decide which site, if any, to serve.. or could it be that this is specific to virtual host setups? Those have been the most efficient option for me so far, so I haven't really had to set anything else up, which could explain why I'm having trouble following you here. With that kind of setup your vhost files include all possible hosts for each site, in which case whole httpHosts whitelist seems unnecessary (and even confusing) repetition Just gave this a try on my own site by providing dummy host header (testing via telnet) and that -- as expected -- resulted in Apache default page showing up. I'm not seeing how anyone could use that for their benefit. Then again, if this isn't always the case, there definitely could be potential for abuse. Also: the problem, as explained by @gunter, is with ProcessPageEdit; it uses httpUrl for view links. That does seem a bit weird, so perhaps it's a leftover or something?

@dragan: that's good to know and definitely not nitpicking -- my intention at this point is to make this module support all native fieldtypes (except images and files, though I'll hopefully get there eventually), including checkboxes. I'm starting to realize that not writing specific tests for multilanguage part was a huge mistake, obviously there are quite a few weird things happening there As soon as I get the time, I'll write a test case for checkboxes (for starters) and see what exactly is going on. It should work.

@gunter: see if httpHosts setting is in place in your /site/config.php and contains only "localhost", that's the most likely culprit. Ryan: if you're reading this and if aforementioned really is the problem here, I'd say that this is an issue that should be dealt with.. personally I'm against this whole setting (I'm seeing more issues than benefits there), but at least it should stay out of way as far as possible -- opt-in instead of opt-out.

That sounds good and you'll definitely have more up-to-date results with that approach. I used cron mostly because sites in question were really large, content is constantly being updated and generating the JSON file could take (relatively speaking) a long time. I didn't want each page save to take that long.

Usually you wouldn't do this real-time. I'd suggest cron job that periodically updates the source JSON. ProcessWire even provides nifty "lazy cron" module you could use, but for tasks like this I prefer proper cron job -- that way there's not even that (rare) slowdown for end-users and you don't have to worry at all about that process getting interrupted halfway. I've recently been working on converting some pretty large and active sites to PW and that's exactly what I did there. In my case JSON file is generated once a day, but of course you could build it much more often. Depends on how often your data changes etc. That sounds just about right There are certain things that are slower than others, but the PW selector engine is pretty well optimized already. What you can and should do is mostly just about keeping it simple -- fewer fields in a selector string is usually faster (take a look at Fieldtype Cache by the way), searching with $page->children("selector") is faster than $page->find("selector") but only finds direct children, comparisons using "=" should be faster than "*=" (which should be faster than "%=") etc. I'm pretty sure you could find quite a few posts about keeping queries fast around here. I'm definitely not the most qualified person here to comment on this. As a general tip forget the native forum search function, it's not very helpful -- do a Google search with site:processwire.com/talk and you'll get much better results..

I've surely written some crappy replies earlier, but this was first one bad enough to be removed No need to restore anything, really. Main point of that reply was that this module had a bug that @dragan uncovered. When more than two languages were in use, values were getting stacked, i.e. version_control_for_text_fields__data contained property values such as "data10141015" instead of "data1015", "data101410151016" instead of "data1016" and so on. This is fixed in current version at GitHub so I strongly suggest everyone using this module to update to that. To fix existing data you have to replace those nonsensical values directly in your database: UPDATE version_control_for_text_fields__data SET property = 'data1015' where property = 'data10141015'; UPDATE version_control_for_text_fields__data SET property = 'data1016' where property = 'data101410151016'; # .. and so on, depending on actual language page IDs (broken values should be easy to spot)

@dfunk006: working with a ton of pages is going to be slow, it's simple as that. Sure, you can always add more muscle to your server, but honestly, how often do you really need to show something like 10 000+ results simultaneously? How is that ever going to be useful for end-users? Adding sensible limit and using pagination or infinite scroll etc. makes sense not only resource-wise, but also from usability point of view. To expand Martijns reply a bit: PW also loads fields defined as "autoload" (via field settings) automatically, so you'll want to be careful with that if you're expecting to handle huge numbers of pages. Unless, of course, you actually always need those fields

@dragan: thanks, that actually solved it. There was an issue with storing language versions; language ID's were getting "stacked" instead of last one being used, which resulted in useless data. Looks like I never properly tested this with multiple language versions.. I've just pushed fix to GitHub and would suggest you (and everyone else reading this) to update the module. To fix existing data you can do something like this in your database: UPDATE version_control_for_text_fields__data SET property = "data1015" WHERE property = "data10141015"; UPDATE version_control_for_text_fields__data SET property = "data1016" WHERE property = "data101410151016"; # .. and so on

I'll have to agree with Adrian: many clients won't see the benefit and many ProcessWire developers aren't hosting client sites themselves so that they could really benefit from this themselves. Problem with large images doesn't seem huge when you're visiting a site often enough for cache to kick in (which is true for many clients, I'm afraid). Unless you use analytics to see how the site is doing for wider audience you might not even notice that anything is wrong. Most of the sites we build also have couple of API calls to images tops and a ton of images included within page content (Tiny / CK fields). Benefits of minimize.pw for sites like that would be less dramatic. Then there are people like me. I've been minimising static images with tools like OptiPNG and also had plans to develop something similar to this module for local use. Your prices aren't high, but if I can do same thing locally without any costs (other than the work required) and without any image limits and so on.. well, it does sound tempting. (People like me are probably not your target audience.) Long post in a nutshell: I'd try to make the benefit of this service as clear as possible and consider what @apeisa said about minimising images during upload. Latter is what I see as the biggest flaw in your current product, actually: if the service would automagically start working after one-click install I believe it would be a lot more beneficial than current solution. Ease of use combined with very clear explanation about what happens when your free quota is gone (does the service still work, does it prevent using the site normally etc.) and easy way to upgrade your plan and you've got a winner.. probably .. and, of course, if you want to make big bucks with this, add native support for more platforms.

I've been using this module with 2.4 for couple of sites without issues. David, your problem sounds a lot like issues reported earlier, i.e. "empty" date fields containing 1970's timestamp. I'd suggest trying what Craig explained above: DELETE FROM field_publish_until WHERE data = '1970-01-01 01:00:00';

Could you specify what kind of field this is that's not saving, TextareaLanguage or something else? Based on your second post I'm guessing that data still gets saved to db tables, is that right? Are you using the default theme ("new" or old) or something else? I'm currently running a fresh test site where this seems to work properly, so any additional information would be helpful. I'd probably approach this directly via database. Table version_control_for_text_fields contains all changes and timestamps for those, so it would be easy to grab changes made during last 24 hours. Rest depends very much on what you want to send, i.e. do you want to also describe how content in each field changed and so on, so there's really no simple answer for this one. Two tables, actually, and you're right in that those are language values. All values are stored mostly because that's what ProcessWire itself does -- it updates all language values simultaneously. You're right in that it feels a bit weird, especially here where rows are stored potentially for a very long time. I'm not yet sure how to get more specific data from ProcessWire (which language version has changed), so setting these values separately might require another method for handling data. This could also make certain database queries a lot more complicated. Created an issue for this one so I won't forget it right away..

My solution for the issues mentioned by @diogo above is a simple script that syncs (via rsync) contents of /site/assets/files/ between dev and production sites ("two-way sync"), but that's just about it. Not a perfect solution, but works mostly just fine. Certain things (such as modules cache) still need to be cleared on a per-environment basis when making changes there (adding modules etc.) I wouldn't worry about logs, sessions or cache files -- it's actually better that they're environment-specific -- which leaves "files" only thing you'll need to keep in sync. One drawback is the situation where you have assets in both versions and then remove them via admin UI from one version; those assets will stay in other version of the site and you'll have to figure out a way to remove them from there too. This thread provides some helpful code samples for doing exactly that and you could also create a simple module that triggers one-way sync operation (rsync, for an example, has the ability to remove extra files from target directory) every time an asset is removed. If anyone has a better solution in place, I'd be happy to hear about it. I've been considering various options starting from shared directories, but haven't found anything solid yet (it'd be easier if both sites lived on same server, but generally dev environment shouldn't exist on same server as production one IMHO..)

Tested and so far working fine in PHP 5.3.2. Not that I'd be against updating PHP (I'm not!) but it should still be noted that most GNU/Linux distros backport security updates to bundled PHP versions. At this particular server I'm, for an example, running PHP 5.3.2-1ubuntu4.22 -- so technically it's not same thing as "vanilla" PHP 5.3.2. As long as you're using PHP bundled with your distro and a distro that takes security seriously, you should be safe. As long as that particular distro version is supported, that is

Depends a bit on context, but especially for modules I prefer translating strings in module file, storing them in $config->js and then in JS file fetching from config var. Simple example: PageListPermissions.module => PageListPermissions.js (though I'd also suggest "namespacing" JS config content, i.e. instead of using config.i18n.*, use config.YourModuleName.* and/or config.YourModuleName.i18n.* etc.)

Update: version 1.3.0, just pushed to GitHub, adds support for repeaters -- or, to be more precise, support for saving revision data for fields that are within repeaters. Repeaters being pages after all, it seemed most logical to treat them as such. If repeater field added to a template for which version control has been enabled contains fields that are also under version control, values of those fields will be stored just like they would be for the main page (page containing the repeater field). I'm not confident that my explanation made any sense, so let's just say that this should be self-evident once you try it. Main point is that instead of saving repeater values on per repeater basis the module is treating individual repeater fields (or repeater field fields..) separately Another thing to note is that snapshot feature added in previous update is now module called PageSnapshots. It's still bundled with VersionControlForTextFields and initiated (and automatically installed) by VersionControlForTextFields init() method, so this shouldn't change anything. I'm simply trying to keep the "core" version control module as lean as possible. Once again, I'd suggest making sure that things work properly before putting this update into real world use. There have been a lot of changes and something could've broken. I've tried to write and run tests vigorously, but those definitely won't catch all issues.. yet

I find #2 kind of pale, much better contrast in #1.. and I also dislike those huge button-style links, way too "mobile" for my taste. How would navigation bar of #2 work for subpages, i.e. how would templates, fields etc. fit there? Or would they not? (If not, that's yet another big plus for #1 IMHO )