ryan

Thanks Marty, I was wondering about https URLs, but hadn't yet seen any so figured they didn't use them. I have just updated the module to support them, so they should work now (vimeo or youtube).

I'm not seeing the double links, but there is one unrelated issue I've been running into every day and might as well mention it because it's easy to show. It's a problem with indentation in any code listing. Check out the following example: Each line is indented with the indicated number of spaces. Notice how IP.Board messes this up, causing endless problems formatting code examples: 0 spaces 1 space 2 spaces 3 spaces 4 spaces 5 spaces 6 spaces 7 spaces 8 spaces 9 spaces Here's a screenshot of how it was entered: No love for tabs in code examples either. But they are lost when pasted into this editor, as opposed to after submitting the message: 0 tabs 1 tab 2 tabs 3 tabs 4 tabs Since code examples are such a big part of what we do here, I was wondering if IP.Board has any settings or plugin modules that would make it more code friendly? Thanks, Ryan

While it may be okay to do once in awhile, I would avoid structuring your site in a way that requires uploading the same image in multiple places. Instead, pull from the source page via the API and use the image. An example of this would be a site structure like this: /about/ /contact/ /press/ /history/ Lets say that you want all these pages to have the same header image. Rather than populating a header_image field on each page with the same image, populate it on just your /about/ page and let the others pull from it. Even if all the pages use the same template file, you can achieve it with this: $image = $page->header_image; if(!$image) $image = $page->rootParent->header_image; if($image) echo "<img src='{$image->url}'>"; The approach here is to give each page the ability to define it's header image, but make it optional. When it's not populated, it grabs the default from the root parent page (/about/). But lets say your structure is a little deeper than that: /about/ /contact/ /directions/ /press/ /history/ In that case, you may want to have it inherit the header image from the nearest parent that has it defined. So /about/contact/directions/ would show the header image from /about/contact/ (if it had one) rather than the one from /about/: $parent = $page; do { $image = $parent->header_image; $parent = $parent->parent; } while(!$image && $parent->id); if($image) echo "<img src='{$image->url}'>"; There may be other cases outside of the example above where you might have the need of using an image defined on another specific page. In that case, use a page reference field. You might call it header_image_page. It would essentially say "I want to display the header image from that page". This is a little better than a direct file reference because your image will still work even if the source page changes it. $image = $page->header_image_page->header_image; if($image) echo "<img src='{$image->url}'>";

Thanks for your work here. Just took a look and if I understand correctly, the scope of it is just to give each class and interface it's own file, named identically to the class. Also because Data.php becomes WireData.php, Array.php becomes WireArray.php, etc., that portion of the autoloader is no longer necessary as well. Let me know if I'm on the right track? I am going to have to start creating fewer classes in my workflow. One [short term] concern: The scope of doing this same thing may be a lot greater in /wire/modules/, perhaps more than would be a good idea in the short term. Though I could be wrong, haven't not looked too closely yet. But I just wanted to make sure that it was worthwhile to do part of it now (/wire/core/) even if we can't do the whole thing in the short term? Or would it be better to pen the whole thing at once to a version (2.3, 2.4, etc.)? I also have a couple classes with major work-in-progress in /core/ that I probably need to wrap up before I introduce new files and change filenames. Do you know if there are any exceptions or alternatives to the 1-file per class with this PSR-0 compliance? I'm just thinking of the dozen or so Selector* classes, and others, as some of this could be difficult to manage in my editing environment (VIM). I think it's worthwhile even if we have to increase the quantity of files in the system somewhat, and it's not often I have to go back and edit these classes… but just wanted to check, as the PSR-0 compliance does appear to introduce new challenges, at least in my editing environment. But it all seems worthwhile regardless.

Michael, that looks interesting. Looks like a lot of cool possibilities there and I look forward to taking a closer look and seeing if there might be another module brewing in there. But I have to admit that I find the whole oEmbed thing a bit vulnerable, as it's letting another web site populate raw markup into your site. You must have a lot of trust in whoever you let do that. It's more sensitive than linking to another service's JS. I have that level of trust with YouTube and Vimeo. I suppose I need to convince myself that something like embed.ly doesn't seem like a potential security timebomb, because the potential is very cool. I'm going to spend some more time looking at it.

There is now a module for this:

I'm actually using a 1987 IBM Model-M keyboard with my Mac, so I have an ALT key rather than an Command (Apple) key. But unless I'm mistaken, ALT and Command (Apple) are just platform specific names for the same thing. Macs also have something called the Option key, which I don't think has an equivalent on the PC. In my case, I just have Option mapped to my caps-lock key since I'm using an elderly PC keyboard. Regardless, I think that anyone on a Mac that uses this module would find the default search command (ALT-Q) causes their browser to quit. Though given that my setup isn't conventional Mac, it might be good for someone else on OS X to confirm.

Video embed for YouTube and Vimeo ProcessWire Textformatter module that enables translation of YouTube or Vimeo URLs to full embed codes, resulting in a viewable video in textarea fields you apply it to. How to install Download or clone from GitHub: https://github.com/r...atterVideoEmbed Copy the TextformatterVideoEmbed.module file to your /site/modules/ directory (or place it in /site/modules/TextformatterVideoEmbed/). Click check for new modules in ProcessWire Admin Modules screen. Click install for the module labeled: "Video embed for YouTube/Vimeo". How to use Edit your body field in Setup > Fields (or whatever field(s) you will be placing videos in). On the details tab, find the Text Formatters field and select "Video embed for YouTube/Vimeo". Save. Edit a page using the field you edited and paste in YouTube and/or Vimeo video URLs each on their own paragraph. Example How it might look in your editor (like TinyMCE): Here are two videos about ProcessWire https://www.youtube.com/watch?v=Wl4XiYadV_k https://www.youtube.com/watch?v=XKnG7sikE-U And here is a great video I watched earlier this week: http://vimeo.com/18280328 How it works This module uses YouTube and Vimeo oEmbed services to generate the embed codes populated in your content. After these services are queried the first time, the embed code is cached so that it doesn't need to be pulled again. The advantage of using the oEmbed services is that you get a video formatted at the proper width, height and proportion. You can also set a max width and max height (in the module config) and expect a proportional video. Configuration/Customization You may want to update the max width and max height settings on the module's configuration screen. You should make these consistent with what is supported by your site design. If you change these max width / max height settings you may also want to check the box to clear cache, so that YouTube/Vimeo oembed services will generate new embed codes for you. Using with Markdown, Textile or other LML I mostly assume you are using this with TinyMCE. But there's no reason why you can't also use this with something like Markdown or Textile. This text formatter is looking for a YouTube or Vimeo video URL surrounded by paragraph tags. As a result, if you are using Markdown or Textile (or something else like it) you want that text formatter to run before this one. That ensures that the expected paragraph tags will be present when TextformatterVideoEmbed runs. You can control the order that text formatters are run in by drag/drop sorting in the field editor. Thanks to Pete for tuning me into these oEmbed services provided by YouTube and Vimeo a long time ago in another thread.

I thought it sounded good, but haven't yet done enough research to answer definitively. I'm not sure that I understand the full scope of changes it would involve yet. But the benefit of meeting that standard would seem to answer any reservations about breaking things into yet more files, assuming it doesn't add overhead to the system. I think it's generally safe for files in /wire/core/, but some concerns about breaking stuff down in /wire/modules/ because there are possible file location dependencies in there (which can be overcome I'm sure). I'm probably not the best person to outline best practices about forks and pull requests. I just know the way that I understand code is a little different from others. I don't have a high comfort level with automated code changes from Git, because it's too easy for me to gloss over the details. I generally need to type something myself before I really see and understand the full scope of it. So the way I handle pull requests is to review the changes and basically re-type (or copy/paste where comfortable) into the code and commit them myself. I still tag it as the pull request so that GitHub understands it as the original pull request. This probably sounds a bit insane, but what can I say, I'm old and it works, and it helps me spot any issues a lot sooner. So if you are interested in making these changes, it doesn't matter to me if you do a pull request or outline the changes here in the forum, email, etc. Whatever works best for you is good with me. Thanks, Ryan

Great update Soma! I'm really liking the new ajax page search. Only thing I wanted to mention though was the default key assigned to this ALT+Q can't be assigned in OS X because it's the application Quit command. I did it, and it immediately quit the browser, closed all windows, etc. I changed it to CTRL+Q, which seems to work well, but am thinking you chose alt+q because ctrl+q has the same problem on windows? Maybe there is some other default for this that would be safe across platforms? Maybe something like CTRL+. or CTRL+[ or CTRL+- I love everything about this module, except that I'm confused by the templates/fields search. Probably because I'm just accustomed to clicking, rather than typing template/field names in the admin. In most sites, the quantities here are small enough to make the search seem overkill. So if there were a most wished for feature on my part, it would be that either: 1) it showed a list of templates/fields rather than a search box. Or; 2) that the field/template search boxes showed all of the fields/templates (that you could click to edit) and then filtered (rather than created) in the list as you type.

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().