ryan

Soma, that's a good find. I'm pretty sure I know why this is the case. Right now when it executes a match on other pages, it doesn't specify an "include" setting, meaning pages can be excluded. It probably should not be that way. I know where to make the change to fix it (it will be easy), but the question I'm struggling with is whether it should be "include=all" always for subfields? After all, we're not technically matching the pages the subfields live on, just the page that references them. It seems to me like it should always be include=all, but I also worry if I'm not thinking through all possible side effects.

I'm still totally confused about exactly what you are doing but it definitely sounds challenging and interesting. Please let us know what solution you ultimately find. A screenshot might ultimately help to clarify too.

Good points in your notes. I wrote a somewhat related article several years ago, some of which might still be relevant (and some not). I think HTML is totally fine for an editor as long as it's used as just markup, and not style. I mean basic things like, this is a headline, this is a list item, this is a blockquote, etc. That means essentially using it within the same limitations as an LML, but with the Word-like interface that clients refuse to do without. This is how we've got TinyMCE configured by default ... not so impressive to look at, but also not too dangerous. It's when you start getting into "this should be this size" and "that should be this color", and so on (style), that it becomes a problem… at least for anything scalable. And the issue with wysiwygs like TinyMCE and CKEditor is that they do both. So you have to put a lot of restraints upon it. But the temptation of eye candy, impressing the client, and giving in to their demands can make the broad capabilities of these editors a curse. Companies even win project contracts by these capabilities because they are such eye candy… "You'll be able to edit your web site just like you edit your Word docs" is an unfortunate selling point. The fact that you can do some fancy (but ultimately not so good) things with it means that the danger is always there. Joomla has obviously crossed the line here. But you are right, the big picture is that it's the nature of wysiwyg and not Joomla. I would prefer an editor that had less grey area.

The configuration options are a little different between checkboxes and autocomplete. I don't think they are as directly replaceable as select-multiple, checkboxes and asmSelect (for example). So may take some re-configuring of the field when you change the type. It sounds like you may be talking about something more though, so I'll experiment here.

I was originally thinking it would be something fairly simple where you could just swap out the files from the default profile with new files, and have it ready to go. And that would be plenty useful. But it would probably be better to go further and try to account for most of the elements. At least, I think this would be more useful to people that want to literally use it to build a site from. So it would be nice to have more than what's currently with the default profile... like a template that uses the slideshow (or ability for any template to use it), a contact form, ability to use the various list styles and menus/button bars, tables, captions with images, icons, etc. (we'll need Soma's expertise with configuring TinyMCE for some of this). All the while keeping the layout and look simple and generic enough that someone could also easily build from it as a base. How about you handle the front end and I'll handle the back end? Let me know if that's of interest, or if you have other ideas? Perhaps some of this overlaps with your plans for HTML KickStart too? If we were to collaborate on this, it seems like it would be not just another profile but more likely one to replace the default profile included with ProcessWire (which is in need of replacement). Though I do think it's important that the next default profile be a little more mobile-friendly than the current one is. Anything that takes the default profile further also means we should include a second "blank" profile with PW (which we don't currently do, but I think we should). I was also excited to hear about your plans for HTML KickStart. Thanks for the shoutout too.

Making that change should be fine. I can't think of any potential side effects.

Any news on this? Wondering if you guys found out what was causing it?

Sorry jacmaes, I didn't catch that earlier. But yes, ProCache will be able to cache m.domain.com and domain.com separately, so would work well in that type of setup. Support for that is not yet there, but likely will be over the next week.

Thanks guys, I will check these tools out. Lightweight text editor is what I've already got. And XML files are usually pretty good at self describing themselves. But this XML file is definitely not setup for human readability. So I need something that will parse it and make it human readable. It sounds like there are some good options here. Thanks again!

If that's all there was to it, I wouldn't have bothered spending weeks developing ProCache. Likewise, if all a CMS needed to do was save and display the contents of a textarea, then I wouldn't have bothered making ProcessWire. While we use an entirely different method, capturing output from a PHP script and caching it is relatively painless. It's knowing when to save a cache and when to expire, how to maintain and freshen the cache, how to handle the security, URL segments, page numbers, configuration, etc., that's the hard part. There's a reason why this is a commercial module.

Does anyone know of any good tools for analyzing giant XML files? I'm dealing with a pre-web services era feed, which is just a giant XML file (20+ mb). I need to write something that imports it to ProcessWire pages every hour. The trouble is that it's a rather complex feed with thousands of tagged elements. The size of the feed is such that it makes it particularly difficult to analyze. For instance, it's a bit too large to navigate with browser-based XML tree plugins (at least, with those I've tried so far). I'm trying to find a way to break this into smaller chunks so that I can make some sense of it. Does anyone know of any software tools or services that can help with navigating through a giant XML file?

What do you guys think of Unsemantic? I've only read about it, but thought it sounded appealing in a Skeleton-framework kind of way.

Rather than an external service, it could probably be accomplished most easily with just a local cron job that does something like this: curl --data "procache=force-save" http://domain.com/path/to/page/ > /dev/null The "procache=force-save" would be some user defined variable that we update ProCache to look for and then force saving the cache when present. You'd need to do this for every page you wanted to ensure was always cached, so maybe not that practical. But might be if you just need the homepage or a small set of pages to never display non-cached versions.

Well that's what processwire.com is for. de.processwire.com is for those that want to read about ProcessWire in German. I'm guessing people would still find out about PW from processwire.com first, and go to de.processwire.com to read about it in German. So it probably does make sense for the DE site to at least be a little more copy oriented than the main site, simply because that's the underlying purpose (native language). But my comment was really more just humor, brevity is an asset regardless of language.

Thanks Alan! Glad you are liking ProCache. I'm adding you to the ProCache board as soon as I finish writing this message. It is feasible to add it, and it sounds good, but there are some problems with doing this. It moves the render from one request to another. If a lot of pages were expired in the same request, it could even become quite a bottleneck on the server. The way it's setup now, the cache generation piggybacks on a page that's already being rendered, so it's very efficient and ProCache activities aren't ever going to consume all the server resources. Consider this scenario: a maintenance run expires 1000 cache files (a potentially common scenario on a large site)… if we have to regenerate them all right there (as opposed to when the page is next viewed) we will temporarily take over a lot of server resources… perhaps interrupting traffic to the site. Whereas, if we cache them on-demand (which is what it currently does), usage of those resources is spread out over a period of time, and generally focused on caching the most-important pages first. Even if we use cron to re-cache them incrementally, the use of resources would still be disconnected from the demand for them (i.e. caching pages that may not be needed in the short term while missing pages that are). But I understand where you are coming from. If you've got a page doing a lot of heavy lifting (perhaps taking several seconds to render) then you don't want any user to ever experience that. So I will put more thought into how such a situation could be handled. For now, if you want to limit the chances of users getting a non-cached page, the best strategy is to increase your expiration times and limit what gets cleared on page saves.

It is supported if you allow it in your field's TinyMCE settings. Setup > Fields > body > input > Advanced TinyMCE settings. It's not recommended though, because being able to enter things like iframes or scripts directly in body copy are considered bad security. It's better to use a runtime module like the TextformatterVideoEmbed module. If you are finding that doesn't work in your case, then give more details -- what is the URL you are pasting in? The first thing we'd want to do is make sure it is in the expected format. Next we'd make sure it is in it's own paragraph (i.e. has 1 blank line above and below it, if placed among other copy).

The $page's next and prev functions return the next and previous sibling, according to whatever sort settings you have defined with the parent. However, you could still do it like this: $siblings = $page->siblings("sort=date"); // or whatever you want to sort by $next = $siblings->getNext($page); $prev = $siblings->getPrev($page); if($prev) echo "<a href='$prev->url'>Prev</a> "; if($next) echo "<a href='$next->url'>Next</a> "; Personally, I prefer using regular pagination to something like this. The skyscrapers profile has some good examples of using pagination with custom sorts.

Do you only see the extra encoding/slashes on the front-end of your site, or do you see it on the back-end too (like in TinyMCE?). If it's only on the front-end, then I'd agree with Wanze that it sounds like you've got a textformatter applied to the field when you don't need one. Either that, or you are running the output through htmlentities() or htmlspecialchars() in your template files. But the extra backslashes in there are an oddity either way. If you are seeing it on both front-and-back end, then it sounds to me like something server-side is "sanitizing" all HTML input from POST. It's feasible that mod_security could have an option to do something like this. I'm guessing this is either a client's self-run server or a very small host (?), as this type of POST sanitizing wouldn't be compatible with any CMSs I know of. Please let us know what you find.

WillyC isn't quite correct there, if I understand what he's trying to say. page-edit is the minimum permission required to to do edit-related activities on the page. Sorting a page's children is considered an edit-related activity. Why? Because it's feasible a user might have edit access to some siblings and not others, so it's a bit of an access control problem for edit access to one page to affect placement of pages a user doesn't have edit access to. So I don't know of a way to get around that without installing other modules. But for the most part, if you've got limited access editors, your sorting mechanisms are ideally predefined so that they don't have to do that. But I will put on my to-do list, to think of other solutions for that particular case. Though I think where we are is probably about right from a security standpoint. For now there are a couple of ways you could accomplish this with modules. One way would be to install the Page Edit Field Permission module. Have it create permissions for all the fields you want to limit access to on the parent. Then create a new role in addition to your existing editor role. Call it "editor-parent" or something like that. Give that role page-edit and page-sort permissions, nothing more. Edit the template used by the parent page, and check the box to give it edit access to the parent with the sortable children. Give your editor users that role as well. Your editors will be able to sort the children and edit the parent, but only the fields you designate (which you might decide to be, none). Another alternative is to add a custom module to take care of it for you. This one essentially changes the behavior of ProcessWire so that if you have access to edit a page, and you have page-sort permission, you also have access to sort it among siblings (written in browser, not tested). class PageSortableCustom extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Page Sortable Custom', 'version' => 1, 'summary' => 'Let a user sort siblings they have access to edit.', 'autoload' => true, ); } public function init() { $this->addHookAfter('Page::sortable', $this, 'hookPageSortable'); } public function hookPageSortable(HookEvent $event) { if($event->return) return; // already sortable, so exit $page = $event->object; if($page->id == 1 || !$page->editable()) return; if($this->user->hasPermission('page-sort', $page)) $event->return = true; } }

Aren't the words the purpose? … The reason for having it in another language?

Thanks guys. I've just changed the release status to "stable", as there haven't been any real bugs to turn up, and I'm now using it on several production sites. If anyone is interested in seeing more details about the Apache bench test results I did, here they are. This is to the skyscrapers homepage, testing on localhost using the command "ab -n500 -c10 localhost:8888/skyscrapers/demo/". For all tests, I performed a manual pageview to the homepage before running, just to ensure the relevant cache was already active. The server is MAMP running Apache with PHP 5.4.4 on a Mac Pro (early 2008). ProcessWire is version 2.2.13. No caching enabled: Concurrency Level: 10 Time taken for tests: 29.066 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 11567500 bytes HTML transferred: 11361500 bytes Requests per second: 17.20 [#/sec] (mean) Time per request: 581.310 [ms] (mean) Time per request: 58.131 [ms] (mean, across all concurrent requests) Transfer rate: 388.65 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.7 0 8 Processing: 463 578 59.5 567 810 Waiting: 455 569 59.4 558 792 Total: 463 579 59.5 568 810 Percentage of the requests served within a certain time (ms) 50% 568 66% 591 75% 610 80% 622 90% 661 95% 693 98% 738 99% 760 100% 810 (longest request) Built-in Page cache enabled: Concurrency Level: 10 Time taken for tests: 6.809 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 11576500 bytes HTML transferred: 11370500 bytes Requests per second: 73.43 [#/sec] (mean) Time per request: 136.178 [ms] (mean) Time per request: 13.618 [ms] (mean, across all concurrent requests) Transfer rate: 1660.35 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.3 0 4 Processing: 93 135 17.6 132 249 Waiting: 90 130 15.7 127 236 Total: 93 135 17.7 132 249 Percentage of the requests served within a certain time (ms) 50% 132 66% 137 75% 141 80% 144 90% 154 95% 166 98% 187 99% 211 100% 249 (longest request) ProCache Enabled: Concurrency Level: 10 Time taken for tests: 0.117 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 11529500 bytes HTML transferred: 11370500 bytes Requests per second: 4260.61 [#/sec] (mean) Time per request: 2.347 [ms] (mean) Time per request: 0.235 [ms] (mean, across all concurrent requests) Transfer rate: 95942.85 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.2 0 1 Processing: 1 2 0.5 2 4 Waiting: 1 2 0.5 2 4 Total: 1 2 0.6 2 5 Percentage of the requests served within a certain time (ms) 50% 2 66% 2 75% 3 80% 3 90% 3 95% 3 98% 4 99% 4 100% 5 (longest request) ProCache Documentation and Order/Download page.

I agree with Macrura73 that you don't want to use a repeater for images unless you need more metadata than what the images fieldtype provides. This is also a bit confusing from the code side because 'images' is representing a repeater rather than an images field. But sticking what what you've already got -- based on the examples that you say do work, you should be able to reduce it to this below. I'm also assuming that image_field is set to contain a maximum of 1 image. If not, the code would be a little different. if($page->featured_project->id) { // $page has a featured project $item = $page->featured_project->images->first(); // $item is repeater item if($item->id && $item->image_field) { // there is an item, and it has a populated image field $thumb = $item->image_field->size(100,100); echo "<img src='$thumb->url' alt='$thumb->description' width='$thumb->width' height='$thumb->height' />"; } }

I'm not sure that I totally understand what you are attempting, but I'll pretend I do. With modals and such, you are already relying upon javascript, so it seems like everything else could be accomplished with javascript as well. What you would do is probably link to anchor names in PW, like "#this-item" and "#that-item" or whatever. And those anchor names could match up to <div id='this-item'>...</div>, <div id='that-item'>...</div>, etc. Or you could just look for them to trigger a modal window. Your $(document).ready() function would add click event handlers to any such anchor links. $(document).ready(function() { $("a[href^=#]").click(function() { var anchor = $(this).attr('href'); $(anchor).show(); // or open a modal or something }); });

Joshua, I'd actually like to do a full HTML Kickstart profile for ProcessWire, if that'd be alright with you. Maybe we could collaborate on it sometime?

Sounds like a good idea for a future Inputfield type though.