Leaderboard

Hi, I just wanted to sing a song of praise of how smart actually PW is (designed). From my recent posts here in the forum you may know what I'm currently trying to do in my spare time - I port/migrate a fairly popular handbuilt 16 year old forum over to process wire. Reason is; the forum's users have grown to like the not-like-the forums out there look of the 16 year old originally perl/cgi based thing, which basically is nothing else like a nested list in most views, which then got enhanced whith loads of custom pages, functions, galleries and wutnot. 16yrs worth of procedural php code, created by at least 4 different and differently skilled developers. Bring it on! Whatever the reason, I thought this might be the perfect pet project to get to know PW in and out. And I really have to say: I'm deeply impressed. I have over 15 years experience wiith different CMSses, and I consider myself as fairly skilled in TYPO3 (yes, with that Typoscript riddles), know my way around cutsomizing and theming Wordpress sites since wp2.1 and I messed around with several other popular and not so popular CMSs as a part of my daily work. For like 1.5 years now I use PW as the "motor" of most sites I build. And now, with this "pet project" of mine, I'm really starting to fall in love : Being able to bootstrap the API and creating scripts that I can "fire" via the commandline, directly on the server, connecting to other databases, helped immensly with the task of getting 186000 posts by 5000 users into a processwire install. creating the relations between these posts (which one is the root of a "discussion", what is the "parent" of the current post) was easily done be using "Page" fields and again a script that scraped that info from the old structure and populated the page fields accordingly. I plan to write a detailed how-to once the migration is completed and working, but this could take some time ;-) Now the backend would time out if I wanted to edit one of the post. Caching the templates didn't help, so I thought about what was going on "under the hood" -- and after a little bit of head scratching it occured to me that maybe the 4 "Pages" field each post carried, were to blame, esp. the 2 fields referencing the whole collection of posts: "post_root" and "post_parent" -- each of which could theoretically be one of the other 185999 posts in the database. Since the default option for the visibility of "pages" fields are "select" and "open", PW needs to query the 185999 posts - and that brought down my php script execution limit and/or the allocated memory size of 152MB. Wow. But guess what, and that's where my romance with PW started for real: If you switch the visibility to "closed", or in my case to "closed with ajax on opening" the backend will run fast again. Now the selects will only be populated (with ajax) if I need to change the post_root or post-parent - which should never be necessary in the everyday use of that data. Initially I had imported the 4000 users not with the system's user template, but a custom one. While this worked without a problem, it brought down the lister, which wouldn't respond and time out after like 5 minutes. I still don't know why, but changing those users to the system user template got rid of that problem, and now they are behaving quite well. This is so cool. What started as a late night idea seems now to grow into a real project. With all that importing and moving imported data to pages data, I had like half a million pages in this install, and PW handled this quite nicely. In the meantime I have cleaned up and currently I'm down to about 186000 pages plus 4000 users plus some static pages. This wouldn't have been possible without the option to use the PW API from the outside. Thank you Ryan for this great piece of software. Cheers, Tom

this.look like a repleye to questiones here http://processwire.com/blog/posts/processwire-2.6.13-and-a-preview-of-prodrafts/#Comment11880 allso pw all ready having sweet versionings frm weekly.pw.teppo http://modules.processwire.com/modules/version-control/ i make draftas this like 1.installs processPageclone frm core 2.clicking copy.on page in.tree { page u want.draft of } 4.edit.edit.edit { keep unpublishas } 4.get mom to edit.fix.edit blahblahblah shutup mom 5.ready to publishas ? trash.originalas page 7.rename clones page and clicking publishas edit 8.ok mabe i will.try prodraft

What the guys said above - I hadn't thought about it like that and was going to suggest something else, but the more I think about my own requirements draft pages would only have been used in less than 10% of projects I think, and even then they would warrant the price tag so not an issue really and it shouldn't be core. The only draft I need most of the time is as I'm writing something before it's published, so the unpublished state does that for me. This does come up from time to time with new pro modules (pretty sure I remember a similar conversation way back when FormBuilder or something was released) but there's usually a good answer like the guys have made above. I prefer that everyone who has paid for Pro Modules gets the benefit of everyone else's questions and answers in the relevant support forums. If the modules were free to all, other community members would undoubtedly help out non-paying folks in the forums which is fine, but given that there are a lot of people here generous with their time and knowledge, folks might not need paid support or see the need to buy that option so it would be a bit of a gamble. Having said that, some aspects would be nice in core, but not to the extent as in this module. But someone could easily build a more basic module for drafts - how do you think the Dev Directory works when you post updated content? (It actually clones the current entry, you edit the clone, then when approved it's copied over the original - a very rudimentary draft system built in a short time using just a few API commands in a small module).

The autocomplete and pagelist inputfields are the ones, that load their pages via ajax and/or paginated, so these are the goto inputfields for this number of pages. What I would really dig is, if there was an inputfield, that just opens a modal window with a lister, where you can filter available pages and select/deselect them. This would be the killer inputfield for large numbers of selectable/selected pages.

Hi All, I've finally! installed v2.6.1 on a dev site, and will be making it live on our magazine site soon, after I finish a new responsive deployment using Pocketgrid. I've been reading the weekly newsletters with great interest. PW just keeps getting better and better! Just wondering: Is 3.0 the next production version of PW, after 2.6.1, or will all the great new changes since then get released in an interim version, like 2.7? Any idea when that might be, etc? I don't really want to install a development version on my live site, but the new changes since 2.6.1 look really tasty. Thanks to Ryan and All for making PW such a truly flexible and powerful programmer's CMS. It's a joy to work with. Peter

I think the problem with drafts really is what apeisa is saying: It's most of the time an overused and therefore overrated feature. As long as you're not catering to the big corporations where content is really managed by a dozen or more people it's arguable if it's really needed. Sometimes having a live and a draft-state would be nice for already published content, but everything else is not a widespread requirement. I think about multiple drafts, draft comparison or diffs and enhanced permission handling. But the other argument about the competitors is true. All of them handle drafts by default without even thinking much about it. It's always handled like kind of a must have feature.

Template caching won't help, since it is purely for frontend. Are you using select as inputfield for post_root and post_parent? In page fields where you can have very many options (like thousands) you really should use inputfield that doesn't load all pages, like autocomplete. Also editing that value comes easier instead if dropdown with 185999 items

Having used ProcessWire for 5 years and in 50 projects (or so) without drafts, I don't think it's fundamental functionality by any means. Very rarely requested and much more rarely actually needed. For Avoine, I don't see big need for drafts, so having it as pro module is much better for us than sponsoring.

New version 0.1.2 * fixes CSRF token validation (Thanks!) * adds option to overwrite email message * adds "from name" for generated email * allows multiple recipients

Cool - let us know how you get on with the front-end as I'm always interested to hear about large data projects. For topic lists on the front-end, pagination is obviously your friend, but also so is autojoining some oft-used fields in your post template - things like topic starter, topic start date, last reply date, last reply user, avatar (just guessing at fields here). Basically for the most common fields that are always going to be required whichever way you're viewing a topic (full topic or in a list or search results etc) if you autojoin them it saves on queries. This page explains it better (no idea why I've not bookmarked this one myselef yet ): https://processwire.com/talk/topic/26-what-is-the-autojoin-feature-in-the-fields-editor-and-how-do-i-use-it/

Jumplinks for ProcessWire Latest Release: 1.5.60 Composer: rockett/jumplinks ⚠️ NEW MAINTAINER NEEDED: Jumplinks is in need of a new maintainer, as I’m simply unable to commit to continued development. As it is, Jumplinks v2 has been in the pipeline for around four years now. The current state of the project is this: backend is mostly functional, and the frontend was being re-written in Svelte (though whomever takes over is free to change this) after having been partially done in jQuery (I no longer use it for anything). If you are reading this and are interested in taking the project over, please pop me a private message and we can take it from there. Thanks! ? What’s Jumplinks? Jumplinks is an enhanced version of the original ProcessRedirects by Antti Peisa. The Process module manages your permanent and temporary redirects (we'll call these "jumplinks" from now on, unless in reference to redirects from another module), useful for when you're migrating over to ProcessWire from another system/platform. Each jumplink supports wildcards, shortening the time needed to create them. Unlike similar modules for other platforms, wildcards in Jumplinks are much easier to work with, as Regular Expressions are not fully exposed. Instead, parameters wrapped in curly braces are used - these are described in the documentation. As of version 1.5.0, Jumplinks requires at least ProcessWire 2.6.1 to run. Documentation View on GitLab Download via the Modules Directory Read the docs Features The most prominent features include: Basic jumplinks (from one fixed route to another) Parameter-based wildcards with "Smart" equivalents Mapping Collections (for converting ID-based routes to their named-equivalents without the need to create multiple jumplinks) Destination Selectors (for finding and redirecting to pages containing legacy location information) Timed Activation (activate and/or deactivate jumplinks at specific times) 404-Monitor (for creating jumplinks based on 404 hits) Additionally, the following features may come in handy: Stale jumplink management Legacy domain support for slow migrations An importer (from CSV or ProcessRedirects) Feedback & Feature Requests I’d love to know what you think of this module. Please provide some feedback on the module as a whole, or even regarding smaller things that make it whole. Also, please feel free to submit feature requests and their use-cases. Note: Features requested so far have been added to the to-do list, and will be added to 2.0, and not the current dev/master branches. Open Source Jumplinks is an open-source project, and is free to use. In fact, Jumplinks will always be open-source, and will always remain free to use. Forever. If you would like to support the development of Jumplinks, please consider making a small donation via PayPal. Enjoy! ?

What does autojoin do? Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. What sites should use autojoin? Autojoin is most applicable with larger sites. On smaller sites, there may be no benefit to using it or not using it. But it's good to know what it's for regardless. Where do you control autojoin? Autojoin is controlled per-field. You can turn it on by editing each field under Setup > Fields > [your field], and you'll see it under the 'Advanced' heading. When should you use autojoin? Autojoin causes the field's data to be loaded automatically with the page, whether you use it or not. This is an optimization for fields that you know will be used most of the time. Fields having their data loaded with the page can increase performance because ProcessWire grabs that data in the same query that it grabs the Page. Autojoin is a benefit for fields that are always used with the Page. This is best explained by an example. Lets say that you have a template for individual news stories called news_story. The news_story template has these fields: title date summary body sidebar We'll assume that when you view a page using the news_story template, all of the fields above are displayed. Fields that should have autojoin ON: Now consider a separate news_index template that displays ALL of the news stories together and links to them. But it only displays these fields from each news story: title* date summary In this case, the 3 fields above would be good to autojoin since they are used on both the news_index and news_story templates. If your title, date and summary fields didn't have autojoin turned on, then ProcessWire wouldn't go retrieve the value from the database until you asked for it it (via $page->summary, for example). Because the news_index template displays all the stories at once, and always uses the title, date and summary fields, it will perform better with title, date and summary having autojoin ON than with it OFF. In this case, it reduces the query load of the news_index template by 3 for each news story. To take that further, if it were displaying 20 news stories, that would mean 60 fewer queries, which could be significant. Fields that should have autojoin OFF: Now lets consider the body and sidebar fields, which are only used on the news_story template: body sidebar It would be desirable to leave autojoin OFF on those fields because there is no reason for the body and sidebar to be taking up space in memory when they are never used on the news_index template. While it might mean 2 fewer queries to view a news story, that is not significant and certainly not a worthwhile tradeoff for the increased memory footprint on the news_index template. Keeping autojoin OFF reduces a page's memory footprint. Conclusion Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. But if your situation doesn't involve lots of pages or data, then you don't need to consider autojoin at all (and can generally just leave it off). Additional Notes Not all fields have autojoin capability. You won't see the option listed on fields that don't have the capability. *The title field has autojoin on by default, so you don't need to consider that one. It was included in the examples above because I thought it's omission might cause more confusion than it's inclusion. Be careful with multi-value fields that offer autojoin capability (page references and images, for example). Because MySQL limits the combined length of multiple values returned from a group in 1 query, autojoin will fail on multi-value fields that contain lots of values (combined length exceeding 1024 characters). If you experience strange behavior from a multi-value field that has autojoin ON, turn it OFF. If you want to play it safe, then don't use autojoin on multi-value fields like page references and images.

A ProcessWire Fieldtype storing files in a customized location, outside the web root. This module is primarily useful if you need to store sensitive data which should not be accessible directly from the web. Normally, ProcessWire stores all files under /site/assets/files. Direct URL access to these files can be restriced by setting $config->pagefileSecure = true. Still you need to make sure that your template permissions are setup correctly. If something goes wrong, those files could be accessed from outside. GitHub: https://github.com/wanze/FieldtypeSecureFile Modules Directory: http://modules.processwire.com/modules/fieldtype-secure-file/ How does it work? After installing this module, you can create a new field of type SecureFile. Enter your configuration under the "Details" section when editing the field: Storage Location Enter a path outside the web root where the files are stored. You need to create the directory manually. Also make sure that the user running the web server has write permission. Roles allowing to download a secure file Users with a role selected here are able to download the files if a download is requested via the API. Allow Download in Admin If checked, users having a role selected above can download the files when editing a page. I needed this functionality for a recent project, so I created this module and thought to share it, mabye this is useful for someone else Consider it beta, I'm using it on one site but I'm sure it could be improved here and there. Feel free to suggest additional features! Cheers

discussed or not, i think lance's point is valid and i also think it would not be a mistake to have such a list either under about or under "download" where i would have looked for it. maybe with a little hint that updates are only necessary if you want to get the newest features and NOT because of security issues and everybody should be happy

I like ProcessWire, and I've used it on almost every project in the past three years. But to state this in the way that you have is borderline trolling. You are of course entitled to your opinion, but in my world, things aren't as easily defined in black and white. And they aren't for my clients, either.

Copied this from what I'm using, so you'd need to change some names and variables around. $selector = ""; // Start date inside $selector .= ", range=("; $selector .= "datefrom>=".$input->whitelist("datefrom"); $selector .= ", datefrom<=".$input->whitelist("dateto"); $selector .= ")"; // End date inside $selector .= ", range=("; $selector .= "dateto>=".$input->whitelist("datefrom"); $selector .= ", dateto<=".$input->whitelist("dateto"); $selector .= ")";

Actually the issue is not what I thought - it is a recent PW dev problem. I checked a PW 2.6.1 stable site and it works fine. I am not sure what has changed in PW dev to cause this - I will need to investigate further - hopefully I can find some time in the next few days to figure it out. EDIT: This is the PW commit that breaks things: https://github.com/ryancramerdesign/ProcessWire/commit/fd719abc6ad4dc12792592b6715f986d29af2625

Are you sure all those missing pages are active (I mean their non-English versions)? (check the Active checkbox on the Settings tab of pages under the Name field)

Hi BernhardB, I'm aware of the issue and actually have an update to support the single page autocompletes which I'm already using on one of my projects, but haven't gotten around to merging it with the Github project yet. Believe it or not, I've also been experimenting with adding an "add new" link just like you suggested here. The biggest problem I'm having with this is figuring out how to automatically populate the field with this new page once it's published. I'll have to study how Ryan does this when creating a new field in the template editor.

Hi Sergio, this is a fairly run of the mill managed server; it is hosted at/by german provider 1&1, who don't excell at their shared hosting offers, but the servers are quite ok Intel® Atom™ C2750 8 Cores x 2,4 GHz (2,6 GHz Turbo Boost) 8 GB DDR3 ECC 1.000 GB (2 x 1.000 SATA) opt: 240 GB ( 2 x 240 GB SSD) Intel® S3500 / Software RAID 1 The issues I encountered were mostly time outs by either the php/apache or the mysql server. calling the import scripts via the php/apache led repeatetly to "gateway timeout" after about 5 minutes. I didn't test the import scripts from the console, though. I maxed the php ini settings, but it seems that the server has some settings that I cannot override; for example the max allocatable memory for php is 152mb, no matter what I may set in php.ini. And the mysql server will time out after about 5 minutes, even with settings as high as 1hr or more in the config. cheers Tom

Thanks for the great feedback and comments @ryan, yeah we need to do a bunch of performance work. Poco a poco (little by little) we are filling in some of the optimizations. We are very excited! This is v1 and we have a lot more in store for this site. If you guys ever need someone to show you around in the Yucatan, be sure to give me a call. Processwire made this site a pleasure to build and administrate. I can't imagine using anything else. Thank you!! Also, I will add it to the directory

hi, this feature would fit perfectly in a project i'm developing right now on 2.6.13 with a autocomplete pagefield. unfortunately it does not work with the new condensed format of single page selects! https://processwire.com/blog/posts/new-ajax-driven-inputs-conditional-hooks-template-family-settings-and-more/#improvements-to-the-page-autocomplete-input on multiple selects it works as expected and it's really helpful!! thanks for the module and i hope there's an easy fix for that edit: what do you think about a link to a modal to ADD a new page to a defined parent. i know one can define "allow adding of pages" but i think there are situations where that is not really user friendly or even not possible because you have some required fields that you can't populate in one line of a pagefield. at least in my scenario (invoicing app) it would be great to have the possibility to create a new invoice, select the receipient and if it's a new client have the possibility to click on "create new" and it opens a modal where you can fill in all the necessary data. in this scenario it would just need an additional field for storing the parent of the newly created pages. but maybe a more flexible solution would be to define the parent dynamically (like "return $page->siblings('title=clients');" or the like) what do you think? dreaming of something like "page field enhanced"

That's wrong. The template object does have a __toString() method, which returns the name, therefore comparing without type check does work. // For a page using a template named "products" $page->template == "products" // true $page->template === "products" // false (object !== string) $page->template->name === "products" // true (string === string)

Hi Gayan, Happy to provide feedback and thanks for a quick reply. While at it, I noticed some css play is off. If you create a new 'Common page block' (like Contact us banner) the link in the content does not get wrapped with the same attribues. eg. "Contact us banner" <a class="btn btn-default btn-lg" href="/contact-us/">Contact us <em class="fa fa-fw fa-angle-right"></em></a> eg. "Some new banner" <a href="/sandbox/pw/page/">Go to my page</a> Both are using same template of 'Common page block' and source code is the same in the body field and 'Render Image as a background' option is used. All the best.

Hello Gayan, Thank you for sharing this profile! I have been away from PW for a while and it was nice surprise to see the community thriving and all the improvements over the revisions. One of the aspects that PW lacked was 'themes' to get the end users to start blogging and publishing content right away. I know this sample profile is geared towards developers and admins but if I may suggest different naming of Pages. Honestly, I had to look up 'hero unit'...never came a cross this concept in any language but I guess design and development are merging in web world. Anyhow, here is what I would suggest for Tools pages: - It would be nice if 'Featured Content' could trim and pull field(s) from existing content like other Pages rather then static entries on their own but it works well for this scope. - 'Storage & settings' for SEO is bit misleading as well, maybe just 'SEO and Page Blocks' since there is not much 'storage' per say? - SEO fields = if left empty they do not use the 'Title' and 'Description' of the current page but rather what is specified on 'Home' page. Wording is little misleading and will cause every page to be presented as the same. While handy, IMHO, every page should pull its own SEO even if only from 'title' and 'body' fileds of the current page. - Top drop-down menu seems a bit redundant where Parent page is listed twice. Any suggestions? I have only spent an afternoon working with this profile and it absolutely fantastic. If fact, it will be the core of what I use for my next project. Thanks for your time. All the best.

Perfect! Now works! I have around 90 redirects to do, and the site receives about 360 pageviews per day. The site produces revenue, so I'd like to not lose any speed. For this numbers( 90 and 360) do you think I should stick with .htaccess file or should I use a module? Thank you very much!

Thanks, that is more than I thought first but I tend to (very) underestimate things. Migrating content is especially pita, knowing that from self experience

Great site Joshua! It really drew me in and I ended up reading a few articles there and started thinking "hey maybe we should move to the Yucatan someday". I think you guys totally nailed it, the site is an experience, felt native to the region, and your client must be very happy. I actually liked all the navigation options myself, though agree some kind of hover effect would be helpful. The only thing I'd mention here (beyond that I love the site) is that pages loaded a bit slowly from here in Atlanta. Run it through webpagetest.org, as it has a lot of suggestions that could make a big difference (especially setting expires headers on the image and css/js assets, of which there are a significant amount). The time to load first byte is also pretty high, which–if not something to do with server/bandwidth–indicates a lot of work is being done on the PHP/template file side, and enabling template cache or ProCache could make a big difference, even if you only use a 5-10 minute cache. Would you mind adding the site to our site directory?

Hi @ArtArmstrong - thanks for your efforts with this and for sharing here. Just in case you missed it, the PW core now has FieldtypeOptions (http://processwire.com/blog/posts/new-options-fieldtype-processwire-2.5.17/) which is an enhanced version of FieldtypeSelect which works with InputfieldRadios, InputfieldChecboxes, InputfieldSelect, InputfieldAsmSelect, etc. Perhaps there is still an advantage to your module - I'd be curious to hear more. Thanks again!

UPDATE: Just got it to work using: $remind = "<img src='http://kathep.com/site/templates/img/remind.png'>"; $content = $remind; I discovered my FTP client (Transmit) was not updating my experiments due to a weird later timestamp on the remote copy of the file. There's nothing like posting to the forum to make things seem obvious that seemed unsolvable before posting. Hopefully documenting this simple noob error will help someone else

No response after four days. So I have to do it myself. Right now I got two custom inputfields working (title and rating), but yet without the stars. Thats the next step. I will post the result in the forums.

Dagnabit! Y'all have quick trigger fingers.

I would also like to add to what thetuningspoon posted. The bigest problem that I have observed with develpopeing any application is where users not knowledgeable in the technology request more and more 'one-click' solutions to the tasks they wish to perform. I'm not knocking these users at all -- We all started with no understanding (and we should never forget that). I personally, however, do not think it is the correct approach to modify PW in this manner. It is a framework upon which we as developers build an application, and subsequently a simple-to-use interface. I only ever intend to expose the PW administration to any of my clients that are qualified, otherwise, I will construct an interface for them to use. As developers, our target audiences have a wide range of skills; from no skill at all, to the skill levels seen from the members of this forum (excluding myself). Although PW is presented as usuable by skill levels between this range, I think the responsibility lies with the user to learn the platform we recommend (assuming we pick the platform that best fits their capability and functional requirements). If they are unable or unwilling, then they might want to stick with - *shudder* - wordpress. Being new to ProcessWire myself, I am learning more and more about its capabilities, and my capabilities using it, as my framework of choice. Does PW fit every requirement? Of course not. But, in my humble opinion, it is the most robust and developer-friendly CMF I have found.

I think most of your issues are gone when you understand a little more about processwire. I would suggest to install a 'play install' where you can mess around and are allowed to break anything without issues. Especially take a look at permissions and roles and all template settings. 1. New pages. solution: Set your family settings right in the admin. 2. Overview. Again family settings & give examples and explanation at field level. 3. Clutter in the tree structure. Put settings in /processwire/settings/ folder (Don't forget te set access for settings folder) 4. User error risks. Setup proper permissions and it's solved. 1. Buttons. Already there (parental relation in template settings) PS: How do I create "apps" nav items a left menu (example)? Create a page under /processwire/

I have observed clients having issues knowing which "New" button to use, but I'm not sure how this could be made more intuitive. It would be interesting to hear some different ideas. That said, the page tree is very intuitive, in my opinion. Most CMSs require you to do a two step process: create a page in some sort of massive "content bin" and then create a menu item that links to it. Usually the interface for creating the item is far less elegant than PW's page tree. In my experience, PW is a breath of fresh air for clients. You do have to put in some effort if you want to make the experience as seamless for clients as possible. In my opinion, the "Family" settings for templates is not optional. You really need to put the time in to set these-- Clients shouldn't be able to create a blog entry or news article outside of the blog or news section. That's just asking for trouble! Also, you can do a lot by setting access/permissions on your templates. You can prevent certain pages from being modified, while still allowing access to modify their children by giving the child templates different access settings. You can also lock pages. I really recommend playing around with some of these settings and logging in with your editor permissions to test them out until you get things fool-proof.

Set a cookie and check if present. I would do it JS only.

hi dev_panther, whenever you have a strange behaviour you can make use of debugging: https://processwire.com/talk/topic/4550-debugging-tips/

Here you've the statement from Ryan about this: https://processwire.com/talk/topic/580-encrypted-urlsegment/?p=4652 @Evan Most likely you're tags will be created as pages, therefore they'll already have a pageName. Just use this as urlSegment and you're good to go. If you want to use the new options fieldtype you could instead use the value|Label syntax. E.g: A german tag "Männer" would could get the name "maenner" (Page) or be defined as option like this: "1=maenner|Männer". Both would work for this url: example.com/tags/maenner/

Try this one: http://processwire.com/docs/tutorials/troubleshooting-guide/page3

for the project in question, i think for a custom design, the # of pages doesn't matter so much as the information architecture; charging by # of pages is sort of old fashioned, now that the CMS can generate unlimited pages using various templates; more sensible to charge by # of templates; does the client want a blog, how often do they need to change their homepage content, and how much seo, do they want open graph, RSS, Atom, RDF, Schema etc; it is sensible to break the hours up into areas, like Planning & Discussions (discovery) Graphic design, asset preparation & management CMS setup, back end development, custom admin stuff Front end development testing, QA, launch SEO Most sites will clock in around 40+ hours even for a basic site - makes sense to estimate on the high side - i have yet to complete a project in less then the # of estimated hours...

This looks similar to (but a little simpler than) pagination to me. Have you tried a straight pagination solution to this? Otherwise, something like this might do if you don't need access to the $page objects themselves... $list = $pages->find('whatever'); $titles = array(); foreach ($list as $p) { $titles[] = $p->title; } $chunked = array_chunk($titles, 3); print_r($chunked); Even simpler, plus you get access to the object with all its data; $list = $pages->find('whatever'); $chunked = array_chunk($list->getArray(), 3); // Output plaintext titles by iterating over chunks and pages in chunks. // Access protected fields as needed using $page->fieldname and format as required. foreach ($chunked as $i => $chunk) { echo "Chunk $i\n"; foreach ($chunk as $page) { echo $page->title, "\n"; } }

Solved with 777 on the sessions folder and all contents. I seem to hit this (it feels) every time I make a site live :/

I still think this strategy would be fragile over time. It's not the job of a web service to keep track of deleted things, that's the job of the client accessing the service. I don't know of any major web service that attempts to bundle deleted items in a feed. The problems arise when something really does get deleted, and your web service has no record of it. If the client accessing your service expects you to keep track of all deleted items, then this will break sooner or later. You can't count on everything being in the trash. That is just a temporary container. Sooner or later it has to be deleted. Not to mention, showing deleted items in the feed means your feed has unnecessary overhead. The responsibility has to rest on the client side or else the system will break down at some point. Here's what I usually do on the client side: Keep two extra fields per record in the feed: import_id (integer) and import_time (unix timestamp). The import_id reflects the unique ID of each item from the feed, and is needed to connect items from the feed with your local items. The import_time reflects the timestamp of when the item was last updated. Before the feed is pulled, the client records the current timestamp and keeps it somewhere, like in a variable: $startTime = time(); Then they pull the feed, iterating through each item in the feed and updating or adding an associated page item for each. Note that the import_time of each page item is updated regardless of whether any changes occurred. You are essentially identifying all the items that are still active by updating their import_time field. $parent = $pages->get("/path/to/items/"); $http = new WireHttp(); $feed = $http->getJSON('http://domain.com/path/to/feed'); if(is_array($feed) && count($feed)) { foreach($feed as $data) { $item = $pages->get("import_id=$data[id]"); if(!$item->id) { // add new item $item = new Page(); $item->parent = $parent; $item->template = 'some-template'; $item->import_id = $data['id']; $item->save(); } else { $item->of(false); } // populate item $item->title = $data['title']; // ... // update import_time $item->import_time = time(); $item->save(); } // after importing the feed is complete, find the pages that were NOT updated // these pages may be deleted or trashed foreach($parent->children("import_time<$startTime") as $item) { $item->trash(); } } I like if the web service also provides an "exists" function, to determine that an item really has been deleted. This returns a thumbs up or down for each item requested, as to whether it exists or not. It's not entirely necessary, but it adds a little extra peace of mind as a backup in case something goes wrong. This is described in one of my posts above. Combined with the code above, the part that does the $item->trash() would just be preceded by a call to the exists feed to reduce the list of $items to only those that are confirmed to be deleted: // find which pages weren't updated $ids = array(); foreach($parent->children("import_time<$startTime") as $item) { $ids[] = $item->import_id; } // send the IDs of those pages back to the feed, asking it to confirm deletion $feed = $http->getJSON('http://domain.com/path/to/feed/exists?id=' . implode(',', $ids)); foreach($feed as $id => $exists) { if($exists === false) { // deletion confirmed, so page may be deleted $item = $pages->get((int) $id); $item->trash(); } } As for memory issues: any feed dealing with a lot of data needs to provide pagination of feed data (example), otherwise it will not be able to scale and will break if there is too much data. Pagination of a feed is a lot simpler than you'd expect for both the service and the consumer. It not much more than wrapping everything in a foreach.

Or check with a string: `hidden, locked, unpublished, system, systemID` $page->is('unpublished'); (Teppo was quicker !)

Hey Jim, getArray() is a lower-level internal method (inherited from WireData) that's not intended to be part of the external $page API (http://processwire.com/api/variables/page/). Instead, getArray() just returns a picture of what's loaded in the class at that time. So your workaround is actually a pretty good solution. But I think this may provide more what you are looking for: $a = $page->getIterator(); The above will return a PHP ArrayObject that you can iterate or index-dereference like an array. If you need a native PHP array, you can do this: $a = iterator_to_array($page->getIterator()); I think this might also work (though haven't checked to confirm): $a = (array) $page->getIterator(); Some fields will be objects (like Page references, files, images, comments). Most can be typecast as strings, which may be what you want to do in exporting a CSV. But if you want the full raw data for the field, you may want to look at doing this: <?php $a = array(); foreach($page as $name => $value) { if(is_object($value)) { $field = wire('fields')->get($name); $value = $field->type->sleepValue($page, $field, $value); } $a[$name] = $value; } That sleepValue() function essentially converts a field's data to the appropriate format for storage in a DB. That should leave your array has having only values consisting of strings, nulls, ints or arrays (no objects, hopefully). In addition to the data you get from the above, you may also want to add these into your CSV: $page->id $page-parent_id $page->templates_id $page->name $page->status $page->sort $page->sortfield (string) $page->template