ryan

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.

Looks great Netcarver -- very impressive tool. This is a great list coming together here too.

Thanks I was able to duplicate with the example you posted on one server and not on another. The htaccess file shouldn't send the request on to PW if it contains anything other than "-_.a-z0-9/". But it looks like on some servers, Apache itself doesn't accept the other characters and just removes them, sending the URL on to ProcessWire. The result of something like "/*/" is double slashes, like "//". That's an unexpected condition--we don't expect this from Apache. So I updated ProcessPageView.module to expect it, so that it throws a 404 rather than a fatal 500 error.

Rebooting has fixed more problems in more computers than any other solution ever. I suppose the same could apply to things like restarting APC. I'm guessing that made it clear the cache that was holding it up. But keep an eye out for it. What turns up once might again.

When you say "ID" of an image, is that a number? The reason I ask is because images don't have an ID. They are referenced by their filename, and that is their "ID". So if you are seeing a number when accessing your field, chances are you are really accessing a Page (or repeater item page) rather than an image.

Why not just use $session? Of course, that's represented by a cookie behind the scenes, but the actual data stored in it remains server side and not manipulatable by the user. So it's safer than a cookie from that standpoint. Nearly the only time I use cookies is from Javascript/jQuery, as $session tends to accomplish anything I might use a cookie for on the PHP side.

Since it seems to be specific to the most recent version of both PHP and APC, lets wait it out unless it turns up for more people--maybe there's a bug in APC or PHP. Did you try clearing your APC cache, just in case?

Some $_SERVER variables like HTTP_REFERER can be manipulated by the client, so it's probably not safe to utilize without sanitization. However, since you are trying to keep track of the last page, I'd suggest using the $session variable. Place this at the top of your page before output: if($session->referrer_id) $page->referrer_page = $pages->get($session->referrer_id); $session->referrer_id = $page->id; Now anytime you want to access the last page, you'd do this: if($page->referrer_page) { echo "Last page you visited was: " echo "<a href='{$page->referrer_page->url}'>{$page->referrer_page->title}</a>"; }

Also take a look at this thread, which is related.