ryan

PW updates the last modified date if you call $page->save() or $pages->save($page) -- those two commands functionally identical. But if you save just one field from a page, like $page->save('body'), it doesn't update the last modified date or anything in the pages table. It only updates the 'field_body' table. Perhaps it makes sense for it to update the pages table too (something to talk about more), but the thought behind the current behavior is this: if you are just saving an individual field, you are likely doing so to limit overhead as much as possible. As a result, PW doesn't considers that a field save, not a page save. I don't think that there would be much overhead in updating the modified date, so it's something to consider. I'm not sure how you are seeing it modify the modified_user because the query that updates that is the same one that updates the modified date, and it doesn't get executed when you just save a field (2.1). For a page save, the last modified user has to correspond go a user in the system. So if you want to show the user as "api" as the last modified user, then you'd have to add a user called "api" and set it to be the current user before you save your pages (full page saves), like this: Wire::setFuel('user', $users->get('api'));

If your dev environment is running in a different path than your web site, then you are right this will be a problem. It's the case for me, as I have everything running off of paths on my dev server, but the web sites ultimately run off the web root. This module solves that problem for everything from asset links to page links and even moved pages: http://processwire.com/talk/index.php/topic,280.0.html 90% of the time, this is probably going to be a TinyMCE specific issue, so I should probably just build some basic root URL abstraction right in the TinyMCE module...

It's not a car or a motorcycle... it's a monotracer. Did a little more research about these "monotracers", and sounds like they are made in Switzerland and built around some BMW motorcycle parts. http://monotracer.com/ http://monotracer.peraves.ch/ http://peraves.wordpress.com/ So far I can't figure out how much they cost or where/if you can even buy one. They also have the eTracer, which is an all-electric version.

Great suggestions from everyone. I've also played around with jCrop in the past and thought we would eventually implement cropping in PW using this or another tool. But will implement it at the API level first (since we need it at that level before we can build a front-end). PW already supports center cropping (by resizing just one dimension) in addition to regular resizing, but doesn't yet support coordinate cropping. I suppose coordinate cropping at the API level isn't that useful since it requires making a visual judgement… but we'll have it anyway. Forget about TinyMCE for the moment. The existing plan was that image fields (FieldtypeImage) would get an "edit" link for each image. That "edit" link would open ProcessPageImageEdit in a modal window. This is the same image edit screen that you see after selecting an image in TinyMCE. We would add the cropping functionality here (with jCrop or otherwise). You would be making edits to the original image. So any resizes and crops you made would be committed to the image once you hit "save". Though perhaps you'd also have the option to "save a copy" if your field supported more than 1 image. Now back to TinyMCE. It would work the same way, only it's going to work off copies of the original image, given that it's only "borrowing" images from another field. That's how it already works (with resizes), but just restating it to say that it'll continue to work this way with crops. Btw, great examples Antti! Finally, just for fun… here's a screenshot from Dictator CMS (what came before ProcessWire). It had a little bit more advanced image manipulation functions that PW2 does, so far. And please disregard the name and branding for Dictator (made in 2003). That dude in the logo is apparently Kim Il-sung (North Korean Dictator, statue)... I was young and didn't know any better (it was supposed to be a concert conductor). Needless to say, after a friend informed me of this, Dictator was re-branded as ProcessWire. Though Dictator's code is long gone (none of it is in PW2).

Thanks for the report, I will try to duplicate and fix here. Regarding the duplicate pages: PW doesn't support multiple copies of the same page in the same list, primarily because the underlying <select> that these widgets are progressively enhancing doesn't support that. Though perhaps we'll find a way around that at some point.

I didn't use a password field on the installer just because I wanted them to be sure they had typed it in correctly. After all, if you type it in wrong here you won't ever be able to login to your PW admin. So I wanted to make sure they could see what they were typing (at least, I like to). But perhaps a better solution would be to just make them type it twice (2 password fields).

Translating data from one source to another can always be tedious and complicated. But at least the PW side of it is relatively easy. More advanced importers have to create and populate page references or handle mirroring of existing data in addition to importing of new data. I've built more of these than I can count, so glad to post examples or pass along any info I can anytime somebody needs to do something similar.

It's okay, I don't like jQuery UI CSS framework that much either, but it gets the job done. But I do like jQuery UI, so it's a necessary evil. I figured it would be better to embrace it rather than compete with it by introducing multiple frameworks.

Thanks, that's good to know. Currently, since user names are page names, they are bound by the same rules, so that means that user names can contain these characters: a-z 0-9 dash "-" period "." underscore "_" If it's a straightforward matter to add uppercase letters to that in the future too, we'll certainly do it. Also wanted to mention that the characters above are just for the login name itself. You can add other fields to the 'user' template to support any other data you want to store… In your case, I'm thinking you might want to add a 'display_name' field or something like that. If you wanted to, you could even construct your site's front-end login to disregard PW's login name completely (though you'd still have to set it to something behind the scenes, perhaps to the user's ID number).

Actually I've been meaning to set this up for awhile, but finally got a few minutes to do it yesterday and didn't want to start it out blank.

It's called the jQuery UI CSS framework. http://jqueryui.com/docs/Theming/API This is what PW uses, though it also introduces a few of it's own things on top of that (though not much).

Looks good, thanks for posting!

This is something I just don't have much knowledge on. I've never maintained a user account on any site that was anything but lowercase, so the thought just never came up. What do other systems do in this regard? Are U&LC usernames common, or is lowercase fairly standard?

While the data import may be the hardest part of this, it's probably also going to be a lot simpler than you think. If you can get the data you need to import into some standard format (like CSV, JSON, XML, etc.) then you'll have no problem getting it into PW. Here's a really simple example of importing a CSV that has has fields for 'title' and 'body': <?php $fp = fopen("data.csv", "r"); $parent = $pages->get("/path/to/parent/"); $template = $templates->get("some-template"); while(($data = fgetcsv($fp)) !== false) { $page = new Page(); $page->parent = $parent; $page->template = $template; $page->title = $data[0]; $page->name = $data[0]; $page->body = $data[1]; $page->save(); } When the time comes, just post some details about what you are doing and we can get you started.

Looks like a good upload solution, I like where you are going with this. I'm usually not 100% up-to-date with jQuery just because it's never seemed that beneficial. So I typically upgrade it when some time has passed or when an need comes up for a new version (like this). I'm certainly happy to upgrade PW 2.1 to use the newer versions if you need it, just let me know.

Spotted this on my evening walk up to the town square so snapped a few photos. Later I saw it drive off, and those middle wheels folded up into the body of the vehicle kind of like airplane landing gear. Anyone else ever seen one of these?

Pete, that sounds like a cool site to develop in PW. I've always heard good things about MODx, though have never developed a site in it. It would be good to hear about the differences if you pursue this project sometime in the future.

Thanks Pete, that's very kind of you. This is still a pretty new project so there's plenty we haven't thought of yet too. We are all full time web designers and developers here, and I think we get a lot of good collaboration and thinking going on in these forums.

I've thought that we should eventually provide 2 views for the images. A thumbnail grid view (with just the photos), and the current view. The thumbnail grid view would horizontally stack as many per row as the interface width would allow, and you wouldn't see the description field. Since this isn't yet an option, I recommend putting a FieldsetTab field around your images field, and give it the label "Images". That way, in your page editor, our images will be on their own tab and you won't have to do all the scrolling when making other edits. Another option is to set your images field to be "always collapsed" when configuring it. Many of the sites that I work on have 50+ images on a given page, and have found that utilizing the tab makes it pretty manageable. Edit: I also meant to add that you would be able to switch between the two views (in JS) just by clicking one of two icons at the top: # or = (if you can imagine those are icons and the first looks like a grid and the second looks like rows).

This looks awesome! Well done. This looks very fun to use. I really like what you are doing with this module.

For the autocomplete – I'm going to finish the new ProcessSearch module first, because that will provide the JS ajax results for the autocomplete. Luckily, that part is almost done. If you are querying something else for your autocomplete, I think you'll find it relatively simple to implement if you use jQuery UI's autocomplete. PW admin is already including jQuery UI, so that widget is already available to the admin. As for selecting from a massive list that needs to be dynamic, have a look at the InputfieldPageListSelectMultiple module, which can be enabled from your Modules tab. Here is a video of how it works: http://processwire.com/videos/page-fieldtype/ Though I'm thinking this isn't what you need because this only works for selecting pages.

Looks like a bug, thank you for finding it. There was an issue in the editor_plugin.js that I must have introduced recently when trying to get this working with IE. It was using the wrong filename (fullsize rather than resized). The in-editor resizes were still working properly, just not the modal ones. If you grab the latest commit of 2.1, this fixes that particular issue. Thanks, Ryan

The reason for this is that users in PW 2.1 are actually pages, and page names are kept lowercase for URL consistency. Some servers are case sensitive and some are not, so the only way to guarantee cross-server compatibility is enforcing lowercase. I like the idea of having either case for usernames, but it may involve a lot of changes underneath. I'll keep an eye on future opportunities to have U&LC in the usernames.

For the files not found in Safari's activity window, which files? I'm not suggesting that you change all your site files around, just perhaps your /index.php so that you can prevent some future WordPress hack from appending some Viagra ad to every page in your site. There's any number of other things such a hack might go after, so this will only exclude one type (though the one I've seen most often). But I'm not necessarily sure this is worth your effort. Since apache can write to all your files (since it's running as you), you can find some security in making some files readable to everyone, and writable to nobody (including you). In a directory list, the permissions would look like: -r--r--r-- I don't have the proper permission numbers in my head at the moment, but you could achieve it with: chmod uog+r-w index.php In plain English: With (u)ser (o)ther and (g)roup, add +®ead permission and remove -(w)rite permission. If you need to modify or replace /index.php (like during an upgrade) you'll want to give yourself write permission again: chmod u+w index.php If your site was compromised, the hacker could certainly change the permissions too, but large scale automated attacks on WordPress usually aren't so sophisticated. Another point of view: if your WordPress gets compromised, it's not necessarily a bad thing to have your /index.php writable because most likely you will know very quickly that something has been compromised... rather than finding out weeks later when the hole may have resulted in bigger problems. In both cases where I've seen a compromised WP install write to the /index.php file, it actually just resulted in the site showing a PHP parse error... the exploit didn't check if the file ended with "?>" or not, and it tried to run HTML tags through PHP resulting in a parse error. It was a great red flag alerting the client that something was wrong.

I totally agree. I love that you can drag-n-drop into the editor... I'm anxious to add full support for this. I might have to rethink some of the bad things I've said about TinyMCE.