ryan

Thanks for posting. Looks like the site came together very well. Nice work.

That's a good addition. You can also set the sortfield for your parent page, so that you don't have to keep track of manual sorting. In the case of skyscrapers, the pages I import to are always sorted by 'name', so setting the 'sort' isn't necessary, but it may be depending on your need. You can set the 'sortfield' from the admin on the 'children' tab of the parent page (which is what I did when importing skyscrapers), but you can also set it from the API like this: <?php $parent = $pages->get("/skyscrapers/"); $parent->sortfield = 'name'; $parent->save(); After you do that, all the child pages will come out sorted by name when you retrieve them with a $parent->children() call. They will be sorted that way in the admin too. You can reverse the sort just by prepending a minus sign,"-" to the beginning of the field name, i.e. <?php $parent->sortfield = "-created"; The child pages would then come out sorted by date created in reverse-chronological order (i.e. newest to oldest). You can specify any field for 'sortfield', as long as it's a native-to-PW field, or it's one of your own fields with the 'autojoin' option set in the field settings. For example, the 'title', date fields, and other text fields are common to sort by. You can turn on 'autojoin' just by editing the field in Setup > Fields, and checking it's 'autojoin' box.

Thanks for your analysis of FCK/CK and TinyMCE. I agree with what you've said, you put it into better words than me. That issue with TinyMCE and Webkit (image selection) they claim is not a bug, but rather a lack of support by Webkit for selection of that sort. Though I'm guessing that just means that Webkit doesn't support the way that they want to do it. I'm anxious to experiment with CKEditor.

Thanks for your post. What you are doing looks right, except that you can skip creating the Pageimages field. PW would rather do that internally. So this is the entirety of what you should do (after you have your $page object): <?php $page->images->add("path or URL to image"); $page->save(); If you are doing this from a template file (as opposed to a shell script or admin module), you have to turn the output formatting off first, as you saw. This is to ensure that you don't accidentally add runtime-formatted content to a page and save it. By "runtime-formatted", I mean entity encoded, markdown, etc. This example might better explain it: <?php $mypage = $pages->get(123); echo $mypage->title; // value is "Products & Services" $mypage->setOutputFormatting(false); echo $mypage->title; // value is "Products & Services" Now lets say that you did this instead: <?php $mypage = $pages->get(123); $mypage->title = "Great " . $mypage->title; $mypage->save(); If ProcessWire let you save that page, the 'title' field would now have this value the next time you viewed it: Great Products && Services Basically, PW only wants to save content in an unformatted "clean" state. It throws that error asking you to set output formatting OFF in order to protect against you corrupting your content. So to follow up from the first example, this is what you should do if you are doing this import from a template file: <?php $page->setOutputFormatting(false); $page->images->add("path or URL to image"); $page->save();

That's a good link. I've never actually used CKEditor, but my understanding is that it's the next generation of FCKEditor (something that I did use in earlier versions). I definitely preferred TinyMCE after using both of those, but it sounds like CKEditor is a total rewrite and may have an edge on TinyMCE at this point. I'm going to develop an Inputfield module for it so that people have an alternative to TinyMCE with ProcessWire. Hopefully it'll be a little easier than developing the TinyMCE one. But this is a couple months off--I have to finish the rest of PW 2.1 first.

Good catch, I've updated and committed it to be this: $sibling = $this->parent->child('sort=-created, status<unpublished'); That "status<unpublished" part makes it include everything but unpublished pages. We do that rather than "status<=hidden" because 'status' is a bitwise field that might have multiple bits set (i.e. greater than the value of 'hidden'), so we have to compare to the next highest status level above 'hidden'. If that doesn't make sense, don't worry because this isn't something you would typically need in regular API usage. But if you are interested, all the status levels are listed at the top of /wire/core/Page.php. Thanks, Ryan

Looking at this again, I do think this is clearly indicative of a compromised system. That <img> tag was located at the very bottom of index.php. A technique used by many hacks is to append or prepend some code to your main /index file -- exactly what you are describing. Since you indicated you "found" it there, I'm going to assume you've been hacked. The question is how did they get write access to it? First you should make sure that your FTP/SSH passwords are changed and to strong passwords. Your web host may be able to help you determine what the entry point is, as well as let you know whether it was specific to your account or multiple accounts (which would indicate a problem at the host rather than your account). Are you running a not-so-up-to-date WordPress on the same account? If so, your WordPress is likely hacked. I mention that particular instance, because I've experienced this exact issue on a WordPress installation before. WordPress is also a common target for automated attacks due to it's widespread usage. What other software do you have running on the same account? (whether CMSs or anything else) When you get your account back online, install a copy of Firebug in your Firefox browser. Browse pages with Firebug open and look at your cookies and DOM. Do you see anything you don't recognize? Look at the network tab and see if any requests are being sent to places other than your server. Unfortunately, you can't assume that anything is safe once the system has been compromised. But having seen something like this before, I do think there is a chance that it was an automated defacement attack rather than a particular individual trying to wipe your data. At least the 500 server error was a red flag that might have prevented the problem from propagating further. You need to find out the entry point, and then get fresh copies of any software you have installed. You can also assume that your databases are compromised, so you'll need to export them and do some forensics with a search tool (I can describe further if you'd like). When ready to install a fresh ProcessWire, let me know and I can walk you through what you need to do to install without deleting your site. If you are running WordPress, I suggest moving it to a non-web-accessible quarantine area.

What is that doing in your index.php? You said you found it there. If that's the case, you need to find how it got there as it may indicate a compromised system. There should not be anything like that in index.php. Your template files are where there should be markup. No markup should be in /index.php.

I just tested here in IE8 too and was able to duplicate it. I tried pulling the latest TinyMCE into ProcessWire and testing, but still doesn't work. Did some searching and found that many other people are running into similar issues with IE8 and various TinyMCE plugins. Apparently IE8 drops the selection when the window focus changes (like when a modal dialog window opens), where other browsers don't. It may be less of a problem if you only have one editor instance on the screen at a time. I'm looking into solutions, but starting to think about trying out CKEditor as an alternative Inputfield option for the textarea field. Not sure how much better it is in IE, but I'm not real comfortable with the amount of workaround/hacks necessary to accommodate various IE8 issues that keep cropping up when writing plugins for TinyMCE. That may just be the nature of the beast though.

Thanks for posting. What dir did you apply those permissions to? Technically, you should only need apache's group rwx permissions on on /site/assets/ (and everything in it) but nowhere else. It's actually preferable not to have anything else writable, from a security standpoint. But if this is a dedicated server or vps, your risks are fewer.

MT has kind of an unusual setup, but i use them for some of my own sites so have used them regularly. Are you running one of the latest commits? I fixed some MT related issues recently. Though I've not used an MT dedicated machine before (just grid servers). I'll try another fresh install on my MT acct when I get the computer this am because I've not tested last weeks commit on MT... Though doubt that's it. Also, is this moving from a grid server to a dedicated? Or from a local dev server to MT?

Nice site! Great work. Thanks for posting.

You may have noticed when using PW2 that when working in Admin > Access > Roles, it gives you a message about "currently in development..." That's because the user/role system was kind of a temporary solution until we had something more concrete. This post is to give you an update on what's in the new user system and tell you how it works. The user system is currently in production, but close to being finished and already being tested in a few places. Users are now Pages In this new system, users, roles and permissions are now all a form of pages, each with their own group of fields. This means they can be managed just like pages both from the admin as well as from the API. It also means that you can add any fields you want to users (and roles and permissions if you have the need). You can add fields in the same manner that you add them to your own templates. The other benefit to this system is that it's now just as scalable as the pages system (given that users are now a form of pages). Any code that you write to find, iterate or manipulate pages is compatible with users. While you can use the $pages API var to access user system variables, the system also provides $users, $roles and $permissions API vars that only operate exclusively on their specific type. These API vars also provide some consistency/compatibility with the existing API vars that were in the previous user system. Access is now managed by Templates rather than Pages I was never that crazy about the way ProcessWire's access was managed by turning roles ON or OFF on any given page. The role settings were inherited through the hierarchy, which was necessary, but also complex. While it could be powerful, these were the main problems I had with it: 1. On a 5,000 page site, there were 5,000 possible places to define access. Granted, you might only define access in a couple places in your site and let the rest inherit that access, but you had to be very disciplined and careful to take advantage of the power it offered. The scope of possibilities here isn't particularly client-friendly for when you hand over the keys to the site. 2. Since access was inherited, you would typically define it on a parent page that had dozens/hundreds/thousands of children, rather than defining it individually on those children. The problem here is that if you want to assign edit access to those children, you would also be giving edit access to the parent... something you may not want to do. 3. The existing system presented some challenges in determining a user's access to a page before it was actually loaded from the database. So when you did a broad $pages->find(), the results needed to be post-filtered (by you) if you didn't want to include pages the user couldn't view. I know this behavior may be desirable in many instances, but ideally it should be optional. 4. Like setting up templates and fields, I've always viewed access configuration as being something more appropriate as part of the site's setup that I would perform, rather than something that my clients would make decisions about in their daily page adding/editing activities. Managing this at the page-level never seemed like an ideal fit. What's different in the new access system? The new system solves the 4 issues mentioned above. In this system, access is managed with templates rather than pages. So on your 5,000 page site with 10 templates, you now have 10 places where you can manage access rather than 5,000, but with the same amount of power and control. In addition, you don't have to manage it in every template if you don't want to -- templates don't manage access unless you check a box to tell it to. So pages using templates that don't manage access simply inherit their access. That access is inherited through the page's parents until it finds one with a template defining access. Lets use the PW default site as an example. Access is defined on the "home" template. That access is inherited by the other pages in the site because we set the other two templates ("page" and "sitemap") not to manage access. And then there is the "admin" template that defines it's own access. So all pages under /processwire/ are controlled with the access settings assigned to that "admin" template. To word it another way, access for all of the PW default site is defined on the "home" and "admin" templates. I've attached a few screenshots so that you can see what this looks like. Two other things to notice in these screenshots: 1. You can now specify your own custom redirect URL to send a user to when they don't have access. 2. You can set pages to NOT be searchable when the user doesn't have access. This will prevent them from appearing in $pages->find() operations (for example). Previously you had to do your own post-filtering. How roles and permissions work ProcessWire's user system is still considered an RBAC (Role-based-access-control system). Any given user can have one or more roles. Roles can be thought of like "groups of users", and a user may belong to multiple groups. All users, including anonymous visitors have the "guest" role. Individual permissions are assigned to these roles. A user inherits ALL of the permissions assigned to all of their roles. The "guest" role typically only has "page-view" permission. When it comes to page-specific permissions (like "page-view", "page-edit" and so on), both the user and the page (via it's template) must have the same roles assigned before those permissions become applicable. This is best demonstrated with an example: Lets say you've got a "guest" role and a "member" role. Both roles just have one permission, which is "page-view". Then lets say you've got a page at "/members/" using a template called "members". When editing the "members" template, you've checked the "member" role, but not the "guest" role. Even though both roles have the same "page-view" permission, only users with the "member" role will be able to view the "/members/" page. Likewise, any pages in your site using templates that don't have the "guest" role will be invisible to anonymous site users. You can now add your own site-specific permissions You could add your own permissions in the old system, but you had to do it via the API. In the new system, you can add your own permissions right from the admin, should you want to. So lets say that you wanted to add your own permission that would determine whether user could submit comments on a page. You would go to Admin > Access > Permissions and "add permission" and call it something like "submit-comments". Then in your template, you could check if the user has that permission: <?php if($user->hasPermission('submit-comments')) { // draw form or save submission } That snippet just asks the question "Does the current user have this permission?" It doesn't ask if the current user has the permission on a specific page. Should you want to verify the permission for a specific page, you would add the $page you want to check to the hasPermission call: <?php if($user->hasPermission('submit-comments', $page)) { // draw form or save submission } Users, Pages and Usage in the API While the user system now uses pages for it's types, the user, role and permission pages aren't directly "viewable" as pages on your site, like other pages are. You certainly could make them viewable without too much trouble, but I don't see the point (technically they are pages in the admin). They are based on pages purely for the flexibility and scalability in managing user data. So if you wanted to create a page where a user could "view" their profile, for instance, you'd so it with your own template: <?php echo "<p>Welcome {$user->name}</p>!"; echo "<p>Your email address is: {$user->email}</p>"; echo "<p>Your favorite color is: {$user->favorite_color}</p>"; Or lets say that you wanted to list a all the users in the system that had the role "member" and wanted to sort them by name, and list 25 per page: <?php $role = $roles->get("member"); $members = $users->find("roles=$role, sort=name, limit=25"); echo $members->render(); There really is no difference between the above example and what you would do with pages except that we're using $roles and $users API vars rather than $pages. You could also use $pages, but you'd have to specify the "user" and "role" templates to make it work: <?php $role = $pages->get("name=member, template=role"); $members = $pages->find("template=user, roles=$role, sort=name, limit=25"); echo $members->render();

This topic has been moved to Getting Started. [iurl]http://processwire.com/talk/index.php?topic=187.0[/iurl]

This topic has been moved to Getting Started. [iurl]http://processwire.com/talk/index.php?topic=168.0[/iurl]

This topic has been moved to Getting Started. [iurl]http://processwire.com/talk/index.php?topic=217.0[/iurl]

This topic has been moved to Getting Started. [iurl]http://processwire.com/talk/index.php?topic=216.0[/iurl]

Some of the existing boards are getting pretty populated, so just wanted to add some new boards to get things started. I'll be adding more in the future, but here's what's been added today: News & Announcements (this one) Getting Started: Showcase Ryan

Looks like another good one. I will be taking a closer look at this too--thanks!

Nikoka, Welcome to the ProcessWire forums. Thanks for your nice feedback. It sounds like you might be talking about pagination? If so, see this: http://processwire.com/api/modules/markup-pager-nav/ Every page also has $page->next and $page->prev, which refer to the next and previous sibling page. That use useful if you want to step through them sequentially in your UI. But you mentioned a group of sibling pages, so I'm thinking the pagination link above is probably more what you are looking for? Also, see the second half of this post, where it talks about using 'next' and 'previous' links instead of the numbered pagination: http://processwire.com/talk/index.php/topic,28.msg53.html#msg53 Let me know if this is what you were looking for, or if you meant something different? Thanks, Ryan

What are the field names and types that you want to be searchable? Generally, you can find all pages that match keywords for a given text or textarea field like this: <?php // find pages that match the phrase 'some keywords' on the 'title' or 'body' fields: $matches = $pages->find("title|body*=some keywords"); // find pages that match the words 'some keywords' anywhere in the 'title' or 'body' fields: $matches = $pages->find("title|body~=some keywords"); // find pages matching 'some keywords' phrase in 'title', and 'some other keywords' words anywhere in 'body' $matches = $pages->find("title*=some keywords, body~='some other keywords'");

Looking good!

The get() function returns just one page, but the find() function will return multiple pages (PageArray). As a result, there is no need to specify a "limit=3" with the $pages->get(), because only 1 page is already assumed. See this for more: http://processwire.com/api/variables/pages/

This looks like a nice upload script, I will experiment with this more. Anyone had good experiences with any others like this? In particular jquery-based solutions?

There is no variable called $image in there from what I see. Are you sure you don't mean: $thumb = $img->size(200, 200); ($img rather than $image)?