ryan

The request for a media manager has come up a few times here. Once you really get into the ProcessWire frame of mind, a media manager becomes redundant (at least in my opinion). But it's so ingrained in other CMSs that it's understandable why it comes up. In ProcessWire any page can be a media manager, able to share any of it's assets with any other page. Not just from the API, but from the editor (TinyMCE) as well, you can select images or files from other pages. If you need something formal, like a "shared images" page, then you would create that page in your structure and use it specifically for that. Different I know, but also very capable. We will continue to improve the file and image fields to the point where any perceived benefits from a separate file manager would be diminished.

I think these are good ideas. Regarding the quality setting: ImageSizer does support adjustment of the quality (via the setQuality() method), but there's not currently a way to get directly to that from the size(), width() or height() functions (like with the upscaling option). However, I'm wondering if this is something that needs to be on-the-fly or might be better off in a $config setting that you can set for the whole site? (or modify it at runtime as needed). Something like this: // just an idea, but not yet implemented, so don't put in your config.php yet $config->imageSizerQuality = 90; $config->imageSizerUpscaling = false; $config->imageSizerCropping = true; Of course, that could still be on-the-fly, by modifying the $config properties at runtime. But just wondering if this might be better than adding params to functions that most won't need to utilize. In addition, we could always provide a 3rd param $options array to the size() function that could override individual settings too, but wouldn't want to make that the only way since I'm guessing most don't need to set these things but once. Regarding the crop, I like the idea and capability. I just don't know how to do it, yet. If anyone wants to collaborate I'd love to get the capability in there. Rather than getting it in as another function param, I'd want to integrate that option as part of the $options array to the function, i.e. $image->size(100, 100, array('position' => 'top-left', 'quality' => 95));

You should also be able to grab the last image and add the description to it: $page->images->add($filename); $page->images->last()->description = "description";

In the majority of scenarios, when I replace an image, it's because the image has changed, and thus so has the description. But we all use things differently, and sometimes needs change from site to site. It sounds like in your case, you are replacing an image where you want to retain the same description. In this case, I would suggest making your image field a multi-image field, and just use the first image in your site. When you upload another image, you will then have two images. You can drag your second image to be first, and copy/paste the description when it should be the same. In this workflow, you at least can retain your description in a manner that can't be lost and is easy to migrate where you need it.

That formToPage function there is for dealing with a PW-generated from using Inputfields. It looks to me like your form is one you've created yourself, so there's no need to use formToPage. Instead, you would get your form values from $input->post, sanitize them, and then populate them to your page object, i.e. $page->nachname = $sanitizer->email($input->post->nachname); Also slkwrm is correct that the formToPage function was expecting a single Page rather than a PageArray. But like I say, it looks to me like formToPage is not what you want.

It's possible that there is some site out there using ProcessWire with hundreds of thousands of pages, but if there is, I don't know about it yet. I haven't gone above ~50k pages myself, though I don't think it would be a problem to scale as large as you need it to. It's not like an odometer on a car where there is a max upper limit and the higher you get, the more you are taxing the system. Whether your site has 100 pages or 100k pages, ProcessWire itself isn't dealing with any more data at a given time (only MySQL is). Scale should not affect the performance of the admin UI either. I actually think that the admin lends itself very well to large scale, and the larger scale you go, the more you'll appreciate some of the ways it does things. That's what it was originally designed for after all. As scale increases, you just have to be more careful about how you develop things. You need to be conscious of calls like $page->children and be sure you are placing limits on quantity of results returned from such functions, i.e. $page->children('limit=50'); More about that here. When dealing with high traffic, you need to consider caching at various levels. Know when to use template caching and markup caching. Optimize some situations with autojoin fields. You might also investigate FieldtypeCache to potentially reduce page load times and increase the speed of multi-field text searches. Make sure your PHP is running with an opcode cache like eAccelerator or APC. I'm also working on an htaccess/rewrite cache for ProcessWire (like WordPress W3C Supercache), but it's not done yet. The advantage of this will be that you can direct some pages to be delivered directly from the markup file (via some complex rewrite rules), bypassing PHP, MySQL and ProcessWire completely. I don't have anything to add about multi-server setups, but interested in hearing if anyone else has experimented here.

Looks good, thanks for posting back how you did it. Also wanted to mention that ProcessWire already has a function that does what your cleanURL function is doing: $slug = $sanitizer->pageName($title); or this variation tries to make a prettier version: $slug = $sanitizer->pageName($title, true);

I keep up to date with Safari on my mac, but I think Apple has lost interest in it as browser outside of iOS. Chrome is pretty much better in every way. There doesn't seem to be a reason to use Safari anymore in OS X. Since File/FileReader aren't apparently applicable to iOS, my guess is that Apple doesn't care about it.

Martijn: There is a link to some high resolution logos linked at the bottom of this post. They aren't print resolution, but still quite large. We could probably use some powered-by logos, so if anyone feels like sharing what they come up with, definitely post it.

If we're using the skyscrapers example literally, like the demo site, then there is no structural connection between cities and architects since they are in different branches, not part of the same family: /architects/ /cities/ So the only connection of an architect to a city is via a page reference field on a building. That means that somewhere, the process you described has to take place, like this: $architects = new PageArray(); foreach($page->children as $building) { $architects->add($building->architects); } $architects->sort('title'); echo $architects->render(); On the individual architect pages, if you wanted to list the cities they are active in, you could do this: $buildings = $pages->find("architects=$page"); $cities = new PageArray(); foreach($buildings as $building) { $cities->add($building->parent); } $cities->sort('title'); echo $cities->render(); In either case, you don't need to worry about duplicate removal is ProcessWire is already taking care of that for you.

ProcessWire doesn't get involved in markup generation by intention. But Soma is right that it does keep $config->styles and $config->scripts for you, if you happen to want to utilize them in generating your <head> markup. As for things to minify and combine scripts, I think they are worthwhile if the selection of files is reasonably static and the browser can cache and use it. But again, ProcessWire doesn't want to step on the developers toes by crossing the line into your output. We don't want to assume that we know what is best for every implementation and developer. ProcessWire may power many web sites but it's also powering mobile phone applications, web services, shell scripts and more. This forum has always been a great place to find out about new tools and resources we can use with ProcessWire too (I need to check out that Minify at Google Code).

As far as I know, the page breaks in HTML attributes are specific to printers? Not sure though, I've never had to use them. Could just break on an <hr> tag too.

I haven't configured anything on my computer (OS X Snow Leopard) but did notice that mail() never works, unless I email to an address powered by GMail. I don't need mail() to work locally, but thought it was curious that GMail apparently accepts mail from my computer where nobody else does.

Think of ProcessWire's tree like a fractal. There is no difference between multiple trees, and branches within a tree. Both can extend forever in the same way. ProcessWire knows nothing about menus. So what is or isn't a menu is based entirely on what you make it, there are no limits. You can have as many menus, whether structured, or flat (via page references, toggles, etc) as you want. Here are common ways of drawing upon ProcessWire pages for menus, but these are just examples in unlimited possibilities: It's common to relate your first level of pages to your top navigation: $topnav = $pages->get('/')->children; It's also common to relate the children of your first level as secondary navigation (which you might also carry further into the structure for tertiary navigation and more): $subnav = $page->rootParent->children; If you wanted dynamic footer pages, you might create a structure where they will be (whether actual viewable pages or redirects): $footerNav = $pages->get('/tools/footer-nav/')->children; Or you might assign footer links via a multi-page reference field on your homepage template, where you edit your homepage, pluck out the pages you want to appear in your footer (using a PageListSelectMultiple input) and drag to order them. (this would be my preferred option) $footerNav = $pages->get('/')->footer_nav; Or you might just put a checkbox field on every page that says "show in footer", and check the box for the pages you want in the footer. $footerNav = $pages->find("footer_nav=1"); Or you might use a repeater to create a more literal menu with title (anchor text) and the URL it should go to. This is just for starters. Pull away from the rigid thinking of other CMSs and you'll find anything is possible.

Here's another route you could take (written in browser, just an idea, not tested): $n = $input->pageNum-1; $data = explode('<h4>', $page->body); if(!isset($data[$n])) $n = 0; $body = $data[$n]; if($n) $body = "<h4>$body<p><a href='./page$n'>Previous Page</a></p>"; if(isset($data[++$n])) $body .= "<p><a href='./page$n'>Next Page</a></p>"; echo $body; I think it's probably better to split on something you define, like "---break---" rather than an <h4> tag, but you should be able to split on just about anything using explode() or preg_split().

I think these sound like good ideas. I was initially thinking the fields permission would work very similar to how it does in the Template editor (for consistency). Something like this: Setup>Fields>[field] editor would have an 'Access' tab or fieldset. It would say "Do you want to manage edit access for this field?". If No, it doesn't have anything else. If Yes, then you get a list of roles where you can check the box for the roles you want it to be editable for. When you want to do grouped permissions, you'd use a role, as their purpose is to group permissions for users. (Roles are a many-to-one relationship with users). To reuse your example, you'd name the role 'edit-private-fields' if you wanted to isolate permissions for a group of fields. I was also thinking the access could be a component of the field-template context modal dialog, so that you could grant a role access to edit the 'body' field in one template, and not in another. Though that may be going farther than we need to.

Thanks for pointing that out. What's really strange is that it only seems to munge the last one: Hopefully the next IP.Board update will fix this. I'll check with Pete on if we can submit a bug report to them.

It was a broken redirect. I've fixed the link-- thanks.

That is strange, sounds like the MySQL version might play into it somehow. Well, I hope to have this one figured out soon.

If you've got a lot of URLs to deal with, you don't have to create separate redirects for each of them in your .htaccess if you don't want to. You could automate it. Setup a rewrite rule for "index.php?/" and redirect all of them to another directory where the old blog is, your own PHP script, or into ProcessWire (where you could let the Redirects module handle them). Let me know if I can be of assistance with the RewriteRule.

Thanks, this is what I was looking for. This answers my concern. @internal sounds like what we need! I will put this on my to-do list. Thanks, Ryan

One of the ways you can show support for ProcessWire is to help get the word out by including a small "Powered by ProcessWire CMS" tagline (ideally linking to processwire.com) in the footer of sites that you develop. This is a big help to the ProcessWire project. But I know there are many cases where it just doesn't work to do that because the client thinks of it as gratuitous. I think it's important to communicate to your client that it's not gratuitous at all. It is doing the right thing by showing appreciation and support for a software that is running their site at no cost. Even so, it's not always as simple as that, and I completely understand. We have no requirement or expectation that sites developed in ProcessWire do this. We just encourage and appreciate it when you can. Let your client decide One thing I've been doing lately is to put the control into my clients hands. They really appreciate that I've given them control over it… more so than if I'd left out mention of ProcessWire completely. It also makes them feel good as they are the one showing support, not just their site developer. Here's how to do it in 1 minute: 1. Create a new "checkbox" field in Setup > Fields called "toggle_powered" (or whatever you want to call it), and enter the following for label and description: 2. Add the "toggle_powered" field to your homepage template. 3. Edit the homepage and check the box (if possible in your situation). 4. Edit the template file or include file that contains the site footer and paste in the following: <?php if($pages->get('/')->toggle_powered): ?> <p> <a id='processwire' target='_blank' href='http://processwire.com'>Powered by ProcessWire Open Source CMS/CMF</a> </p> <?php endif; ?> The code above is an example, so adjust the markup, size, wording and placement to suit the site.

I've made some updates to have $config->urls->admin ready before init() is called. I can't think of any reason not to have it available, especially since (as you mentioned) the $pages API var is accessible (even if no pages have been loaded yet). I'll commit to the source here within the next day or so.

Great! Thanks for testing it out and reporting back. I'm going to give it a couple more days here to test before I move it into the public source, but so far so good. Likewise, please let me know if you run into any concerns. Thanks, we are lucky to have you here! Your do.php repeater-populate is actually what prompted me to write that tweet. I ran out of memory before it could create all the pages. Then I realized I had debug mode on and it made sense why it was running out of memory. Now I'm debating putting a limit on the number of queries it'll save in memory for debugging purposes, to prevent this problem.

Where are your sort settings defined? On the parent page(s) or with the template? I think we do have a bug when sort settings are defined with the template. I noticed when I imported a profile the other day, the sort settings in the template were still there, but somehow not having an effect. Somehow the process of exporting/importing causes template-based sort settings to get lost, but I haven't figured out why yet. So this is something I'm working on and hope to have a fix for soon. But I'm not positive if this is the same issue you are running into or not?