teppo

I've just pushed to GitHub new version of this module.

This update includes some minor improvements, such as storing version data for pages starting from the moment they're added, and as a bigger addition $page->snapshot() feature exactly as described by @SteveB earlier:

echo "Page title now: {$page->title}<br />";

$page->snapshot("-1 week");
echo "Page title last week: {$page->title}<br />";

I've been working on and off this for a while now and actually had to write a bunch of PHPUnit tests just to make sure that everything works as expected (too many moving parts to keep track of manually.) There's still some work to do here and especially performance-wise more tests to be made, but at least this shouldn't disrupt how other parts of the module work

But I get a PHP Fatal error:  Call to a member function find() on a non-object on line 51:

$features = $pages->find("parent=/events/, bfd_day.name=$todayday, bfd_month.name=$todaymonth, sort=bfd_year");

So I presume the doesn't understand the ProcessWire code "parent=/events/"....

That error is caused by the fact that you run this file without involving ProcessWire at all. You can't just run template file "standalone" and expect it to automatically load ProcessWire, you know

Solution @horst provided above is most likely what you need here (or external / real cron job instead of this awfully limited scheduler thing you're using now).

Then again, if this is the only reason you need that template, i.e. it doesn't need to be web-accessible, you could forget whole template and page thing and simply place a PHP file somewhere your scheduler can access (such as your PW root directory) and in that file bootstrap PW and write any program logic you need. Point your scheduler to that file and you're all set.

So, while the website looks as it does, I think that "modern" would be my vote for default "color set" and for the installation routine.

+1 for "modern" for the reasons Adrian mentioned.. and because the "warm" color scheme gives me this nostalgic feeling I can't quite explain. It feels comfortable (kind of like 80's product design and advertising), but doesn't really match my image of ProcessWire as a present-day top-of-the-line software product

Some time ago, while debugging a misbehaving site, I found out that one user had a habit of hitting shift + enter at the end of each line in the editor. That made sense as an attempt to gain more control over the typography, but it also explained the situation.. especially since the site in question was responsive.

Making each <br /> visible could've prevented that whole mess -- or at least made it easier to understand why it was happening

It would make sense that if a user group is responsible for only one part of a site, that on the Pages page of the admin, they only see the bits of the site they are responsible for. 

In a very complicated site structure, this would make navigation and administration far more logical and has offers the nice comforting psychological aspect of logging in straight to your area of concern.

Agreed -- and I'd like to add that in some cases even the page names and/or titles themselves could be considered confidential data. I'm thinking about things like closed intranet for managers, working group discussions etc.

@ryan: I'm not 100% sure that we're talking about same issue here, though I thought they would be related as symptoms are practically identical. Previous case where this happened was when page A had field that referenced page B.. which had a field that referenced page A.

With page fields (strictly speaking fields where the value is instance of Wire) change tracking does something I can't quite grasp -- instead of answering the question "has field value changed", it seems to check if object that field references has changes. Different kind of circular reference issue, perhaps?

Just to be very clear: apart from what this module was doing earlier, I've never had/seen any reason why page should be able to reference itself.

Nice job Nik! Does that mean I don't have to figure out how to solve circular Page references in the core, or do we still need that? What's funny is that I was working on this in the core a couple of hours ago and then got a forum notification email that Nik had found a workaround. But I can keep working to find a core-level solution if we still need it.

Ryan, I don't see need for it, at least not because of this module. Solution we have now should work as good as the earlier (I am bit disappointed that I didn't invented that, since it isn't codin magic, but plain old selectors...).

Just for the record, similar issues have caused me a lot of headache over last month or so; the more I work with page references, more obvious it becomes that something is broken. Even though there's a way around it here (and usually in other cases too), I really hope that module authors wouldn't have to jump through hoops to achieve something that should be a no-brainer.

Sorry if I sound a bit agitated, but having spent literally hours in my last module to hunt an issue down -- only to find out that it requires what I'd consider an ugly hack to get over -- has that kind of effect on me

Soma: edited my previous post. Didn't see couple of latest posts until after writing that (and also misread some points), so you can simply forget most of that now..  

By the way, Modules Manager Notification looks awesome!

Edit: this message was written before reading posts above and makes no sense anymore.. weird things going on with cache, I think. Anyway, thanks Soma, problem solved! 

picture.0x100.jpg and picture.232x176.jpg are size variations dynamically created by ProcessWire. Original image is saved as picture.jpg, that's all.

Directly uploading image with FTP won't do any good, since PW won't know about it, i.e. there's not going to be required metadata to support it. If this image field of yours is called "images", see contents of database table "field_images" for an example. Each uploaded image gets a row of data in table associated with the field it's uploaded to.

I'd still suggest that you don't attempt FTP upload + directly manipulating database content, unless you absolutely have to, as that could result in issues elsewhere.

Its like voting for TV talent shows. They used to try and stop people doing multiple votes, but research showed that the same percentage of people multiple voted for all artists, so it wasn't worth the hassle trying to police the system.

And here I was questioning their motives, thinking that the money each vote brings in would be too tempting.. good to hear that it's actually fair too

@apeisa: I know.. "all publicity is good publicity" and so on. Just saying that there's a flip side to that coin too

I honestly don't agree, and really don't like sites/apps opening new windows/tabs for me (that's what option+click is for). But you aren't the first person to mention it, so I'll try to accommodate both preferences somehow or another. 

I agree with you in principle that generally sites shouldn't open new tabs/windows, but I think users have come to expect that links to external sites and internal links that can break a form submission will be in a new tab/window. Maybe it isn't critical in this case since it is a backend link and even content authors should be able to get used to it. 

I'm *not* a fan of anyone deciding for me whether or not a link opens in new window / tab, but this is the one case where it might make sense. I'm not too fond of the "even content authors should be able to get used to it" explanation either, partly because I myself keep forgetting it..

Form Save Reminder helps a lot with this issue, though. As a matter of fact it's one of those 3rd party modules I think should definitely be baked into core and even enabled by default.

By the way, Ryan, this is probably wrong place and time for this, but were you aware that modules directory is currently doing exactly the opposite of this? Module links are catching mouse middle button clicks and redirecting, effectively overriding commonly used setup where middle click opens link in a new tab. (It's driving me nuts, another quirk I just can't seem to memorize..)

@SiNNuT: agreed.

I believe that PW deserves to win this one, but votes like these are still mostly bullshit. Bitnami should at least require authentication via another platform or something similar in order to keep their "contest" (even remotely) fair.

Sure, malicious users will find their way past that limitation too, but at least it'd look like the people responsible for the contest actually give a shit.. 

Probably should've mentioned in my last post that it's, of course, possible to support both $db and $database simultaneously. Ryan posted an example of this in the first post of the thread linked above. That would make sure that your module works now and in the future releases, though I must admit that I still haven't added this to any of my own modules either..

Oh, and by the way: this module seems very useful. Had a quick look and so far I'm liking it very much

@Larry: just had a very quick look around and.. well, so far things look amazing (probably 'cause parts of this remind me very much of how Zend Framework works.) Will definitely dig in further

Will be deprecated at some point in near future. $this->database is the new one that uses PDO in PW now.

Minor clarification:

Since current master doesn't yet support PDO and according to Ryan 2.4 will be backwards compatible with earlier versions (thus supporting $db and MySQLi) "in near future" might be a bit of an overstatement here. If this module needs to work with current master (stable) branch of ProcessWire, $db is a requirement.

@landitus: you're right in that using the code I posted earlier message would get sent every time user is saved, which probably isn't correct behavior. One way to achieve what you're describing here would be by simply adding a check for changed status (published). You might want to take a look at Process Changelog for some sample code.

"@" character was missing by purpose; in PHP adding @ before function such as mail() suppresses errors. If you're relying on these emails getting sent, this makes very little sense, as it just tells PHP that "if this fails, no worries, just keep going as if nothing happened!"

@Sevarf2: no native way (that I'm aware of).

In case tat you're using Session Handler Database (i.e. storing sessions to database instead of files) table "sessions" will contain all active sessions and theoretically you could get distinct user_id's from there and then find users matching those. These users may not actually be actively doing anything or even really be online, they just haven't logged out yet and their sessions haven't been cleaned by garbage collector.

Sounds kind of hacky, but it's a start.. 

I'm not entirely sure how much sense this makes, at least without some additional changes; at the moment if you make a fieldset global, you still can't insert any fields in it by default, right? You'll just have an empty fieldset with all your templates?

Option to make a fieldset global and choose which (global) fields it should contain and their order would be pretty awesome, though..

(By the way, there's a full section of this forum dedicated to new ideas and suggestions like this: Wishlist & Roadmap.)

Thanks, Ryan -- looks like we were too impatient

I'd like to point out (again) something I mentioned earlier:

Did you mean that it would actually be in default site profile's modules directory or still bundled with core modules, only not "permanent", or something else?

Removing "permanent" status from TinyMCE would take us past at least some of the issues mentioned in this thread; that way anyone could simply uninstall it and then install another RTE or none at all, whatever they prefer.

Bundling it with site profile instead of core is, again, almost as good -- though personally I dislike the idea that pretty much every site profile out there would need to include an RTE after that. Sure, they could choose one of their own instead of what default site profile uses, but still

@ryan: sounds like it would make most sense to combine the switch to TinyMCE 4 / CKEditor with release of either 2.4 or 2.5 (depending on your timeline here), especially if there's a possibility that existing fields don't work as expected after upgrade?

Regarding differences between TinyMCE 3 and 4, they do provide "compat3x" plugin to make transition less painful. Might be worth checking out if issues mentioned above were somehow related to plugins.

In the past I've had quite a few times when I had to dig data directly from MySQL. Since a page there doesn't "know" it's full URL, just it's name and the id of it's parent, a) locating a page is a bit of a hassle -- which is why I've often let page edit do that for me -- and b) getting useful page-related data (with full URLs, that is) directly with SQL queries is even more troublesome.

Can you post a real-life example of such a query? What's the reason you query mySQL directly, what kind of scenarios?

Answer is long overdue, but I've mostly used this for one-time requests for pages with specific content in specific field(s), i.e. "give me a list of personnel with phone number starting with xxx / email address with domain example.com", sometimes with a twist or two (".. but only those people we mention in one or more of our news items"). Other times I've just needed a simple list of pages matching certain criteria (such as created / edited within given time frame) possibly combined with something like a list of pages they're connected to via a Page field.

This is doable via selectors and PHP, but sometimes I just prefer SQL; no need to write even the simplest of scripts or format the output myself (and when formatting, replacing, combining, calculating etc. results is needed, (My)SQL has very good tools for this.) This way I can also add any related data with a JOIN or two, export it as CSV with INTO OUTFILE.. and so on.

Most of the time it's just a personal preference, something that makes sense in my workflow and saves me a few lousy minutes of work 

Note that I've very, very rarely used this at template files or modules -- just a few times to make some common but relatively complex and memory-consuming (from PW's point of view) task faster by cutting some corners -- and it always feels like a very dirty hack. Definitely not something I'd recommend doing.

@Joe: could you provide the version numbers of ProcessLoginHistoryHooks that a) work for you and b) don't work? I'm not aware of any issues related to it, but I'd still like to make sure..

Edit: you mentioned "teppokoivula-ProcessLoginHistory" in your post above. Are you just referring to the module with this name or is this an actual directory in your /site/modules/?

Just making sure, 'cause having one module in two locations (such as /site/modules/teppokoivula-ProcessLoginHistory/ and /site/modules/ProcessLoginHistory/) would definitely cause this kind of issue.

This has been discussed about a dozen times already -- not saying that it's not interesting, just pointing out that there's already a lot of discussion and actually couple of (mostly) working examples available if you just take a quick look around

Well, if the module actually shows up as installed, it's most likely still in modules database table. If you can't uninstall properly, try removing related row from there manually. Column class there should match modules classname.