ryan

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.

Hi Pete, thanks for your feedback and welcome to the forums. I was confused when you mentioned "drag and drop", as PW doesn't have support for dragging images into TinyMCE. But then I went and tried it myself, and sure enough, it works! I don't know why that works as I've not coded anything to support it. Apparently it's something that TinyMCE must have built-in and I just never realized it. Did anyone else here (other than Pete) realize that TinyMCE supports this? I don't know how I missed this. So now that I know TinyMCE supports it, I think I just need to setup PW's TinyMCE plugins to recognize the event... I need to do more research to find out how to support this... give me a couple days. Until we've got that working, you'll want to just click on the image icon and select the image that way. But I'm anxious to add this drag-n-drop support, as it sounds quite convenient. Thanks, Ryan

So it's pulling from the CC images already–that's great!

The screencast looks very cool! FieldtypeImage just extends FieldtypeFile. If you look at the FieldtypeImage class, there's hardly anything in it. So the meat of it all is really in FieldtypeFile. I would suggest just extending FieldtypeFile and overriding any parts as needed. You can even override the table structure if you need it to be different. But as it is now, 'data' is just the filename, and 'description' is just a fulltext indexed MySQL 'text' field. If you wanted to, you could certainly use the 'description' field in a different way, perhaps to keep some JSON encoded data or something. I love how this works to pull images from Flickr. One question popped into my head as I was watching it. Does it search and pull from anywhere in Flickr? Or is this just for hooking into your own flickr account? I know in the US at least, if we cloned images from Flickr without adhering to the individual license requirements of each, we might get in legal trouble. I didn't know of a simple way around this because PW finds compatible types based on what classes they extend. Since InputfieldImage extends InputfieldFile, it's technically valid to use. If this becomes a larger problem with more instances in the future, we'll probably have to make the modules explicitly specify which they are compatible with.

For a production site, the recommended security is that you don't have any writable PHP files, or any directories where PHP files can be both written and executed. The only directory that ProcessWire needs writable on a production site is /site/assets/. And it's htaccess file excludes any *.php files from being executed in that structure. This may seem like overdoing it to some, but PHP is the most widely used web scripting language and so it gets targeted for exploits kind of like Windows does. So I think it's always good to take some extra precautions. These messages are only displayed to the superuser role, and they aren't a complete security check, just a few of the most obvious things. If you are still getting those messages, that means that PHP can write to the files indicated. Most likely you are in an environment where PHP is running as you (like PHPSuExec or CGI PHP). If ProcessWire is the only thing you are running on the account, then for myself, I would probably ignore the messages... but I don't want to recommend that per se, as it really depends where your comfort level is. If you've got anything else running on the account (like WordPress for example) then I wouldn't want my /index.php to be writable (or any PHP files, or directories where PHP files can be written). The reason is that a large number of automated exploits target your root /index.php file simply because it's a known common-denominator. Making it non-writable is just a small thing you can do. Because PHP is running as you, In your case, you'd have to make it non-writable to yourself. It's up to you to decide whether you think it's necessary or not. If you want to suppress those warning messages, grab the latest commit and add this to your /site/config.php file: $config->showSecurityWarnings = false;

I just committed an update to 2.1 that makes Field/Image Fieldtypes offer the option of a configurable Inputfield on a field-by-field basis. Let me know if this works for you? Thanks, Ryan