ryan

I don't think that face, size or color are valid attributes with a <span> tag. It probably doesn't hurt anything to have them in your TinyMCE definition, but I think the only valid one you would need is "style". Is it really working with span[face|size|color], or do you have a span[style] in there too?

I do the same thing that apeisa mentioned. However, I also prefer to keep other things in the site structure where possible, even if I don't intend to use them for front-end views. I often setup template files for these things for my own use (or the client/admin's use), and it can be quite useful. I've found that the approach scales very nicely and enables things to grow over time without becoming more complex. When not practical within the site structure, that's when you use your /tools/ structure. It only becomes messy if you treat pages as buckets, and buckets are messy. If you treat it as structure and put thought into where something should go and why it should go there, what you end up is something extremely organized and purposeful. If something is a non-visual page, does that matter? You see it in an administrative interface, where administration is the purpose. Where I would not want to see the non-visual page is on the front-end. Another thing to consider is whether something should really be "non-visual". I prefer to implement template-files/views for nearly everything on my sites, even things I might consider non-visual in other platforms. The benefits become obvious once you start doing it. However, ProcessWire will happily maintain pages that have no output too. But experiment with implementing output for things you previously thought as non-visual and see where it takes you. It often opens up great new paths to information and is an excellent SEO tool for increasing cross references in your site. For example, consider these pages from the modules directory that started out as non-visual. I went back and implemented an "author" template that does nothing other than show the modules by that author. Yet it's quite useful. This may be an obvious example, but the same concept applies to all kinds of situations. This is only true if you code with a dependency on structure. The suggested route is to select by IDs, templates, relative references or some other field to depend on when you are dealing with potential structure changes. Selecting by path is just one way to pull from other pages, but far from the only way. We use it a lot in examples because it is the easiest to communicate with in the context of examples. But that doesn't mean it's always the right way. Ultimately what is right or what is best just depends on the situation. Using the "hidden" checkbox is a good way to immediately differentiate such pages. However, for something better and more automated, check out mindplay.dk's excellent Template Decorator module. I'm hoping he will add this to the modules directory soon! It is possible, but it's not something I would suggest. I think it's fine to create one-off structures for menus where you might want to vary from the page structure for specific situations like footer links, or even primary navigation in some cases (*see note). But if you build your entire strategy on that, you are adding a load of unnecessary complexity to a site, disconnecting navigation from structure, and ultimately creating a mess that could have been avoided with a little planning. *I think page reference fields, combined with PageListSelectMultiple input are often times a lot better for this stuff.

I agree that it might be good for us to show what you can do with ProcessWire rather than just admin screens. Once we have a nice site directory setup, I was thinking these screenshots could pull from that, and perhaps lead into it. But I don't want to stick screenshots from my own sites into there unless they are also in rotation with other people's sites. But I'll experiment here and see what we can do. In the short term, we do need to get some more screenshots in the rotation, regardless of what they are.

Nik has the best posts! Another thing I wanted to add is that it's also very easy just to use API code to do these types of imports. 90% of the time I use API code to script imports with shell scripts, versus using the import pages CSV module. Though part of that is that I use the API every day and there's not a lot of figuring out to do. But if you want to post a sample of the data you are importing, I'd be happy to respond with a sample of how you might import it from the API.

What version of ProcessWire? Also, what method did you use to delete the page? Are you sure that your deleted page isn't still in the trash? I just tried to duplicate here, but so far can't. When I delete a page that has a repeater on it, the items that accompany the repeater get deleted. The method I used was to delete the page from the page editor, then go and empty the trash. You can observe if the pages are still there by browsing the page tree to Admin > Repeaters > [repeater field name] > [page name]

Caching isn't on by default (Templates > edit template > cache). So if you aren't using cache, I'm not sure what the issue could be. You might try replacing $input->cookie->InfoBar with $_COOKIE['InfoBar'], just to see if there's any difference (just in case, since you are on the dev branch). Cookies are stored at the client side, so it's always worth considering that too (something interfering with cookies?).

Subfields like "category.id" aren't currently supported by the PageArray in-memory find/filtering functions. Though I think I can add this easily enough. However, "category" should resolve to the id property anyway, so you probably don't need it.

The problem is that page $f doesn't know the repeater item changed. Those repeater items are individual pages themselves. You can solve this by saving the repeater item ($g) rather than the owning page ($f): 1. Replace your $f->save(); with $g->save(); 2. Also replace your $f->of(false); with $g->of(false); 3. Lastly, I also suggest replacing your first line with this: $found = $pages->find("parent=/invitations/$user->name, guests.guest_name=" . $sanitizer->selectorValue($form['oldname'])); Adding that selectorValue() sanitizer in there will prevent problems from occurring if the guest_name happens to contain characters like commas or quotes.

Thanks Martijn, this has just now been fixed in the latest commit.

We still have the Wiki ready to go (http://wiki.processwire.com/). It's just looking for someone to show it some love. I've closed off public post access because of all the spammers, but happy to add any new accounts for anyone that wants to work on this -- let me know?

Do you have template caching turned on? That would negate the use of any cookies set from PHP. When I need cookies and caching, I use Javascript-based cookies instead, since they are client-side and still happen regardless of server side caching.

I'm not sure I understand the 1 week vs 2 week thing. It really shouldn't matter whether the range is days, weeks, months, years, etc. There are no 1-week dependencies that I can see in any of the code in this thread so far. You should be able to provide any date range in your selector. $fromvalue ="2013-07-13"; $tovalue = "2013-07-27"; or $fromvalue = strtotime("2013-07-13"); $tovalue = strtotime("+2 weeks", $fromvalue); Also wanted to add, I have a better solution for this now (on the latest commit to the dev branch). You can now do this, where $item is a repeater item: $property = $item->getForPage();

They didn't used to entity encode those feeds, but looks like now they are. I think I've got this fixed. Please give it a try and let me know how it works for you: https://github.com/ryancramerdesign/MarkupTwitterFeed

As of the latest commit to the dev branch, you no longer have to do this. You can now replace the above bit of code with this: $forPage = $product->getForPage(); That returns the page that the repeater item is for. I also added this, should anyone ever need it: $forField = $product->getForField();

Okay I think I've got this fixed. Would you mind trying it out and seeing if it also fixes it on your end too? It is on the latest commit to the dev branch. https://github.com/ryancramerdesign/ProcessWire/commit/7dab612baa55b7ca02a7d6679e70d1aef4298f8b It involved a re-thinking of what a repeater Page is. I've changed it so that repeater pages are now represented by their own class (RepeaterPage rather than Page). The new RepeaterPage is the same thing as a Page, but overrides the method used to determine when files should be secured or not (which it now delegates to its owning 'for' page) . It also adds 2 methods (see below) so that people don't have to do stuff like this to figure out what Page or Field a given repeater item belongs to. For those interested, these methods now appear on all repeater item pages: $page->getForPage(); // returns the owning Page this repeater item is for $page->getForField(); // returns the Field this repeater item belongs to

That's a bug (glad we have a dev branch). I'll work on this.

It's a good thing.

There will be soon. Just need to figure out how to do it. But that's part of the reasons the $options array is there, so that we can include additional options like crop direction.

Not an ETA yet, but it's something that has been started and I've got a proof-of-concept going, so it's at least in the picture. ProcessWire's performance is pretty strong relative to other CMS platforms and there hasn't been a lot of demand for cache solutions. But I like the idea of a "super cache" because it does feasibly give one the potential for holding up to a flood of requests, like one might get from being linked on the reddit homepage or something.

Thanks for the link, that's a great directory of these frameworks. Found out about a few I'd not heard of too.

Thanks for the updates Nico! How about posting this to the modules directory?

Use of font tags seems kind of rare these days. I'm thinking that something like forecolor or fontselectsize would use span tags with inline styles rather than <font> tags. Though not positive. But you might try adding a span[style].

The goal here is to show ProcessWire in several different contexts to portray a lot of diversity, but that probably doesn't come across yet since we just have one set of screenshots in play at the moment. The way I see it, ProcessWire is a system, not an admin theme. If we're going to show them the system, I want to present it in the way that looks best on the page. I thought Nikola's screenshot was more attractive than mine in this context, but it's still showing the same system (and the Futura theme is beautiful). But what I'd really like is to have several sets of screenshots to rotate in here. So far I've not been able to get anyone else to send me any. Would love to get some screenshots of your admin theme tweaks you posted the other day in there--actually would like to implement those in the default admin theme.

Only fields with the 'autojoin' option set are fetched when a page is loaded. All other fields are fetched on demand. Meaning, $page->body won't actually be retrieved from the DB until you access $page->body. Most fields can have the autojoin option set if you want it (Setup > Fields > your field > Advanced > Autojoin). However, I recommend using that sparingly and only on fields that are used every time you load the Page. The 'title' field is a good example of a field that should be autojoin. ProcessWire does not keep separate modification dates for each field. Though it's feasible that it could. If you went into the DB and added a timestamp field to each field_* table, that's essentially what it would do since MySQL automatically sets a timestamp field on every update. I'm not sure I understand this question, as you can access $page->modified already. Likewise, you can retrieve pages from a selector using the modified property. For instance, if you wanted to retrieve all pages modified in the last day: $items = $pages->find("modified>=-1 DAY");

4. One other thing I added: If you delete an image, it won't leave the crops behind (they get deleted too). Previously the crop files would stick around even after the original image was gone. The field config is defined in InputfieldCropImage.module rather than FieldtypeCropImage.module, so that's why it works. It's more your doing than mine, as I only had to tweak a couple things to make it work. It was an accidental find too. Meaning, I wasn't intending to add this specifically, but noticed it worked through my own error of forgetting to change the fieldtype. It's possible I'm missing something, but it all seemed to work fine here. Of course, the FieldtypeCropImage is still a necessary component. But it's acting like an autoload module, adding hooks to Pageimage and Pageimages.