ryan

From a PHP code side I think it looks fine. If you reduce it to just the logic (taking out all the needs of the markup), you've got this, which is pretty straightforward: <?php $content = "<pre>"; foreach($morePoints as $aPoint) { $content .= "\n" . $aPoint->title; foreach($aPoint->children as $subPoint) { $content .= "\n\t" . $subPoint->title; } } This method does become messy if you once you get to a lot of nested levels, or an unknown number of levels. At that time, it's better to take a different approach (recursive function being the option I usually take).

If you aren't running the latest 2.1, you can also do this: <?php $role = $roles->get('role_name'); $user->roles->add($role); Also, to make your code more readable and easier to type, I would suggest localizing the API vars you are using, like this: <?php $input = wire('input'); $sanitizer = wire('sanitizer'); That way you can use them like you would in a template.

Good catch, thanks Pete–fixed.

Great–thanks for the followup and glad you got it working. The main thing will be to watch out for the possibility of having a page with the same name as a user when it's not intended. Of course, if you are limiting this capability to just one parent then that will be less likely.

Looks like I was missing an attribute. Thanks for finding – This is fixed in the latest commit. I agree on the needs for an option to have horizontal image display, at least when using thumbnails. We'll get an option for this soon, and I don't think it'll be too difficult to add.

Your user should just be named "test", without the preceding "user-". I only recommended having "user-" in the page name just for additional clarity and specificity in the page name, but it isn't actually necessary. Also, we are bypassing PW's permissions for this, so don't give them page-edit permission in PW. There's no reason to. And doing so would defeat the purpose of building your front-end forms.

Very nice Soma. I really like a lot of what you are doing with this theme. And you beat me to those pulldowns–well done! I like how they work. Great job with this theme. Only details that came up as questions during testing (and these are really minor): In the PageList, the children counts are resting on a lower baseline than everything else. I also had a little trouble with asmSelect fields (like Page references) with the colors being the same as the container. Like I said, pretty minor. The diamond icon you have in the PageList presents some interesting possibilities, and it got me thinking. At first I thought it was a replacement for the 'move' link or something to indicate a page status. While it's only decorative now, it seems like down the road maybe there is possibility (whether in this theme or another) of having a preceding icon that is functional, whether to indicate the page's status, template, or something like that. Indicating the page's template with an icon (configured per template) was Adam's idea months ago, and I've always thought it was a good one. Though probably something we need to add to the core to make it work.

I don't think that any of these would be actual limitations, it would just determine what approach you take. But if the subject is still "simple poll", then it's hard to get simpler than pages. You'd have a /tools/polls/ section or something, and then a page reference field would let you select what polls you want to show on any given page. Though I understand your desire to build this as a Fieldtype, so if you want to go that route lets keep talking about approach and we can figure out a good one.

You can use limit. As long as specify a limit greater than 1, PW will still count the pages even if it doesn't load them. When you call getTotal() it tells you the total number of matches as if there were no limit. It has to do this for pagination, but it's a trick that's handy to know about even when you don't need pagination.

The problem appears to be a result of characters in your $titolo field. You mentioned you are using $sanitizer, but didn't mention if you are using $sanitizer->selectorValue() before bundling the value into your selector. You would want to do this in addition to any other $sanitizer/sanitization you are already doing. This is because selector values need to be sanitized so that the values in them don't get confused as other components of a selector. So make sure that you are doing this: <?php $titolo = $sanitizer->selectorValue($titolo); $find=wire('pages')->get(1485)->find("template=libro,title%=$titolo"); If that doesn't work, try echoing the value of $titolo before calling find() so that you can see which one is causing the problem. From what I can tell, it starts with "senza censure". I am thinking that you can fix this just with $sanitizer->selectorValue(), but if not then paste in the full value here that is causing the problem and we can analyze it further.

Glad you found a solution to this. You are right that the functions we are using in PHP require full dates, so one can't specify zeros for a given part (except time, if you are using that). If you only need to support a year, I would just use an integer field rather than a date field. If you only need to support a month and year, then something I've done in the past is to just ask the client to specify "1" for the day, and then we only use the month/year component for output on the site. This has worked well for me at least.

You mentioned that you didn't include the /site/config.php from your old installation in your new installation. Your logins won't work if you do this because /site/config.php includes a line at the bottom that looks like this: $config->userAuthSalt = '...'; That is the key to your passwords. If someone ever gets access to your database or a copy of a dump file, they shouldn't be able to decrypt the passwords if they don't have that key. Likewise, a PW install won't be able to work with passwords in a system without the original key that created them. So if you installed a fresh copy of PW 2.0, you'll either want to use the old /site/config.php …OR… copy the last line out of the bottom (that looks like the above) and paste it into your new /site/config.php (replacing the one that's already there). These keys are generated uniquely for each site. Btw, I do have a PW20 to PW21 upgrade process if you want to beta test it this week. I did just upgrade the skyscrapers demo site to PW21 and so far so good. Though note that it does not attempt to copy over users, roles or permissions at present… these things are too different between PW20 and PW21. What it does is create a site profile of your old site. Then you install a fresh copy of PW21 and use the profile it created rather than the one that PW comes with.

I think it might be easier for us to help if you can post the code that isn't working. Though if it's my example above that isn't working, let me know. As with everything, we want to first get it working with the simplest possible scenario with code that only accomplishes the task at hand and nothing more. Then once we've got that working, you'll be able to build from it knowing it's got a strong foundation.

That's way too many pages to try and load in memory at once. I'm impressed you were able to load that many. When you start dealing with hundreds or thousands of pages, start using "limit=n" to paginate whether for output or not. How many pages you can load at once depends on how many fields are being auto-joined to it and how much memory you have available to PHP. Here's are two ways to achieve what you want below. This one loads a max of 3 pages. In the first example, we specify "limit=2" because any limit above 1 triggers PW's pagination (making it include the total matches). So we take advantage of that to get the total: $total = $pages->get(1485)->find("template=libro, limit=2")->getTotal(); This next example requires PW 2.1. We use a "has_parent=1485" in the selector, which is a way to tell PW that the matched pages have to have that parent somewhere in their ancestors . That's something that the first example is doing for you since you are already specifying the parent by calling the find() directly from page 1485. $total = $pages->count("has_parent=1485, template=libro");

The issue you described does happen in FF in some cases, due to the image selection and some issue in TinyMCE (out of my hands unfortunately), but I was thinking this was the same thing. Glad to hear it's not.

A good middleground is fluid with minwidth/maxwidth and centered-- good at any res.

I may be one version behind you with chrome. Based on what you are saying, it sounds like they've added real image selection capability in the latest chrome (something that FF had before but not webkit). I'll check if there is a new chrome update on Monday to test with.

I think this would be possible with the way it's setup. Something to plan for the next version.

Foreach your images and strpos the URL for each one in your body field. When it matches, remove the image from the array. You'll be left with the unused ones. I can post a code sample when I'm back at the computer on Monday if you'd like?

I forgot to mention it before, but that last update should have fixed this too. I changed it to just check for access "page-view" permission, and not any other factors. If you don't have that access then the page wouldn't even be selectable, so I don't think that error message will be seen again in regular use.

Caches and modal popups can be a challenge sometimes. You may need to right click in the window and (in FF) choose: frame > reload.

Can you describe more how to duplicate? I might be doing it incorrectly, because I can't duplicate yet. Tell me what I'm missing (I'm using Chrome): 1. Click image icon in TinyMCE, select image (my example is 900 px wide). 2. Enter 200 for width, hit enter, and click "insert image" and image appears in editor. 3. Back in TinyMCE, click image to highlight, and click image icon again. Following that, my image is still 200x150. What am I missing? Also, right click somewhere in the image edit window, and choose "Reload Frame". That will make Chrome reload the CSS and JS files, just in case it has an older version cached.

Sounds intriguing–I'm very interested in hearing more about this.

@Pete–this has been added in the latest commit.

@Soma, oddly enough this issue just started happening to me on my desktop computer with the latest Chrome. Though it didn't matter what width I had the window at, the image would just disappear whenever I selected one and I basically got the same thing as you. As far as I can tell, it's a bug in Chrome. But I found an easy fix, and that was just to add a height attribute to the image. That seems to fix it here. When you have a moment, would you mind giving it a try over there? While I was there, I added width/height pixel inputs for specifying image dimensions. I think Pete had asked for this awhile back, I need to track down that thread.