Peter Falkenberg Brown

Dear Teppo, Thanks for your excellent feedback. And yes, as soon as I turn on caching in the templates, I'll start testing with a non-logged in browser. I already ran into an issue with that, when I had some permissions incorrectly set. I could view some things as the admin that normal users couldn't. Thanks to you, and everyone, for such excellent help. Hey, maybe one day, I'll be able to help someone with ProcessWire, too! Best regards, Peter

Dear Teppo, Wanze and Soma, Thanks for all your responses. I appreciate it. Teppo, yes, I was talking about templates. I still find it a bit prone to error when I talk about an internal template (which to me looks like a definition of a set of fields), versus a template file that gets parsed from the disk. It's a fine line unless one assumes that the critical word is "file" (and doesn't forget to mention that critical word). About the $page->render() comments above: Most of my template files use a find command (except for article pages), and then they grab the data through the $page object. I only use the $page->render() function in my code on the home page, for blocks of lists, in this function: function render_block($inc_block_template_file, $page_ids_array) { if( count($page_ids_array) and !empty($inc_block_template_file) ) { foreach ( $page_ids_array as $page_id ) { $page_id->template->filename = wire(config)->paths->templates . "$inc_block_template_file"; echo $page_id->render(); } } else { echo "No Content Found"; } } Is $page->render() a necessary call for things to be cached, or does it also happen when one just uses the echo $page->field method? Also, Teppo, I haven't run into the conflict you describe above. I use different templates for list pages and article pages. I wonder if that might be an issue. Thanks! Peter

Hi All, I've set up a website with three or four main templates: - one for the home page - one for "list" pages (i.e. section type pages) - one for article type pages - and some other ones. All the templates point to a custom template file that acts as a controller, and checks a custom template file field for the actual template file to include from the controller template, defined when the various pages are created. For example a "multi-section" page would use the list type template structure, but would have a field that defined the final output template file as "multi-section.html". A sub-section page would use the "section.html" template. (the multi-section pages are not paginated, and the section pages are paginated). An article page might use a regular "article.html" template or an "article_plain.html" template, to create a different type of page, depending on whether it was a simple contact us page (for the plain one), or a page that pulled in author information, etc. The Question: In the admin section, I can define each basic template field set to be cachable, but I'm wondering if that automatically caches the include files loaded by the controller template file. Here's the content of my controller file that each of the template field sets use: <?php ################################################################################################### # custom_template_controller.php ################################################################################################### include("./inc_functions.php"); block_future_publish_date(); $custom_template_file_id = $page->custom_template_file; $custom_template_file = $pages->get("$custom_template_file_id")->select_value; include("./$custom_template_file"); ################################################################################################### So far, everything is working fine. I just need to confirm if the final output, assembled by the $custom_template_file, will be cached, assuming that the template field set has caching turned on. My second question relates to the MarkupCache module. Based on the concept that the custom_template file has PHP statements and include function, etc, etc, will all of that output be cached by the template setting, or do I have to wrap the whole thing in a MarkupCache statement? Thanks for any clarifications... Peter

Dear Ryan, Thanks for your answers! I appreciate it. Varnish caches images and pages in RAM, so it decreases server load and increases response time dramatically. With ProCache as the base, I think that Varnish would probably only become relevant when the server got hundreds of thousands of hits, but it's a good alternative to using a CDN. One can use Varnish to cache things up to a certain level of millions of pages, and then use a CDN like Edgecast when the page views are too much for Varnish on a standalone server to handle. I see ProCache in my future. Thanks again for building such an excellent system. Peter

Dear Pete, Thanks for your answers! - Upon reflection, Varnish would be good for caching the images, which don't seem to be cached by ProCache. Is that correct? - Are the images in the page copied to that cached directory tree, or are they referenced in code, to their original location? - How does ProCache deal with deletions of pages, or url changes? Does it delete the cached files for deleted pages? (i.e. no orphans left over) - Is it correct to say that a ProCache page is an assembled unit of all of the code elements in that page, that were local to the system (e.g. not including 3rd party iframes)? Thus, the cached page would include all of the elements, even code that might otherwise be uncached, unless MarkupCache was used? (But not the images (i.e. the images are pulled in at run time?)) It seems like a very clever system. I'm looking forward to using it, when I have a site ready to go live. Best regards, Peter

Dear Ryan, Can you either point me to a link where you might have already answered these questions, or could you share a bit more details about the ProCache method? * Does ProCache convert every page into a separate html-like file, and then add an entry to the .htaccess file, for each file? I wrote a Perl/MySQL CMS years ago that published all the pages to real html files, which of course was very fast, but it wasn't caching per se. If it was one .htaccess line for each file, a large site would end up with a very large .htaccess file, which would get loaded on every page request. I'm curious about your technical method. * How does ProCache work with dynamically updated content in iframes, like Twitter widgets, banner ads, etc? Does it ignore those third party elements as "pass-throughs"? * Also, how does ProCache perform with sites that have hundreds of thousands of pages? * Finally, would you say that ProCache could take the place of a highly tuned installation of Varnish? Thanks! Peter

Dear Soma, Thanks for that! Hey, now I'm using my Very First Hook! Woohoo! Your code works like a charm. Am I correct in thinking that I can rename the 3rd parameter, i.e. the local function? That's what I did, and it seems to work. Here's my code: function redirect_url_target_fix(HookEvent $event) { $page = $event->arguments[1]; if($page->open_in_new_tab) { $event->return = str_replace('href=','target="_blank" href=', $event->return); } } $treeMenu->addHookAfter('getTagsString', null, "redirect_url_target_fix"); echo $treeMenu->render($tree_menu_options); Best regards, Peter

Dear Soma, Also, as a followup, is there a way to add a parameter to the module so that a url or redirect_url could have a flag set in the page to open the url in a new tab? I.e. "target=_blank" if "open_in_new_tab=1" ? MODX had that with weblinks, and it was very cool. Most of the external url redirects that would appear on a menu (in my case) should be opened in a new tab. I added the target=_blank to the parameter: 'item_tpl' => '<a href="{redirect_url|url}" target="_blank">{title}</a>', but then that opens all links in a new tab. Thanks! Peter

Hi Soma and All, Thanks, Soma, for building this excellent MODX Wayfarer replacement. I've got it working with a special selector query, 'show_in_menu=1', which makes me happy, happy. But now, I've been looking around for some actual CSS examples, the way the old Wayfinder page used to have. You know, working examples of using it for a dropdown / flyout menu, etc. Does anyone have any links that use Soma's module? Menu CSS details make my brain freeze. I'm not sure why. Thanks! Peter

Dear Soma, Thanks for this info! I actually didn't click on the "Infos" link. This is very helpful. Best regards, Peter

Dear Pete, Thanks for this feedback. I think I may do the same. Best regards, Peter

Dear Soma, Thanks, that's very helpful. I've looked at the hooks page. I'm halfway done with my first "regular" PW website, and I know that the hooks are my next stop. Is there any other documentation on the hooks, besides just looking through the admin code? (Which I've started to do.) Thanks again! Peter

Hi Teppo, Thanks for the tips! Does that mean that the interface can't be built on the foundation of the admin interface? Just checking... . Peter

Hi Pete... I'm making a lot of very fun progress on a regular ol' magazine site, where only staff members enter data, in PW's default Admin pages. But -- I believe I'm still missing something about modifying things like a "ticket template", where you can add fields, etc, for users to enter data, and have it look different. Based on the view that a ticket system, or any kind of special app, might not want to use the default admin "look and feel", does one have to replace the admin system, or can one plug in a modified template for users with certain roles? I'd like to be able to have someone log in and then show them a specialized template that still uses all of PW's goodness, without having to roll my own forms and save functions. Can it be done by modifying, replacing or adding onto the PW admin backend? Although I *would* like to understand more about how to add hooks to those templates and forms. In an app that I built in Perl, I had "pre-processor" and "post-processor" hooks (i.e. subroutines) that ran before and after most operations, like viewing a record, editing, updating, adding and saving. For example, before the save or update functions, I would check for required fields, or other special needs, and in the post-processor, I would calculate fields and do additional save operations. I know I'm missing something. Do you have any quick tips about how to accomplish something like the above, for any kind of basic "custom forms" application? Thanks! Peter

Dear Diogo, I shall have to ask LiquidWeb why. Some hosting companies take a cautious approach, and don't install the newest software, for fear of breaking things. Peter

Dear Ryan, Yes, redialing BBSs... I remember that. A long time ago, far, far away. Peter

Dear Teppo and WillyC, Thanks: I'll check that thread out. Peter

Thanks, Nico! Ryan: Won't requiring PHP 5.3+ knock a whole lot of shared server accounts out of the water, in terms of PW? Even my site, which is a new VPS from LiquidWeb.com, has PHP v. 5.2.17. I've never upgraded PHP, and have no idea of the impact on code running under 5.2+, but it seems like a hurdle in many cases. Just curious. Maybe upgrading PHP is easier than I think. But I have a number of clients who use shared hosting, and upgrading is not an option for them. They would have to migrate to another box, which can be a real pain. Peter

Hi All, Thanks for your tips. It got my brain working again and I (gasp) *Googled* for the answer. Which I should have done in the beginning. Google is our friend. Well, sort of. I found this tinyMCE directive, added it, and it worked like a charm: apply_source_formatting:true Thanks! Peter

Hi All, I just noticed that the HTML of the body text field has no line breaks in the code, so that when you view source, the content is on one very, very long line. The line contains <p> codes, so the browser displays it correctly, but the source is very hard to read. I would also wonder if a maximum line length might be reached in the browser. Not sure on that. It becomes a significant issue for source code readability, especially with articles or stories that are long (e.g. a short story that is 25,000 words.) It seems like ProcessWire is not adding on \n line break characters after each </p> or < /br> code. Is there a setting that I'm missing? Thanks, Peter

Dear Ryan, Thank you! ProcessWire just keeps getting better and better! Peter

Dear Ryan, Thank you! This is very helpful. I browsed around and found some example scripts of using straight PHP or PHP with Curl, to send an array of data to a page, and also saw that when it was sent, the page just reads the regular POST data. Combined with your example above, it really seems like I don't need to provide them with an "API", as much as I simply have to say, "send a specific array of field names and values to xyz https url, including authentication", and then they can choose what language to send it in, as long as it arrives as POST data. Thank you once again!! Peter

Thanks, Antti! I'll work on it and see what I can do. P.

Dear Antti, Those are good ideas, thanks! I think my main question is, does PW have something in its code already, or in modules, to deal with incoming data, per above? Or, in a module? I didn't see anything. This may just be a PHP question, i.e. how one deals with post data sent as a batch, perhaps in an array, and the specs necessary for the remote programmer. I've been asked to provide that remote person with an "API" to send data to a PW website, but it seems like I'll have to roll my own from within PW. Any tips, anybody? Thank you all very much! Peter

Dear All, If this has been discussed, please let me know the url. Otherwise... A feature that I have to build into the web app I'm creating is that a new user has to be able to register from an approved third party website, which would collect all the standard user data (for their own use), and then send that data to my remote website app, via an "API", whereupon my web app would return some type of response, probably a double opt in link of some type, sent to the user's email address, as well as a status message to the 3rd party website. I'm thinking that the best way to go would be to have a special page that parsed the incoming data as if it was post data from a form. The page would run some routines to parse the basic data, plus look for a 3rd party authentication key, to stop anyone else from using the page except the approved site. Does that sound like a plan? Is it enough to just have a form action type page that looks for post input from a remote, authenticated site? In other words, I don't have to provide the 3rd party with an "API" -- I just have to say, "Send these xyz fields and key to this url, as post data, and use whatever language or method you want to send it." For example, I know how to send data like that in Perl, using LWP. (e.g. sending post data to PayPal, which looks for a hash, but I'm thinking that I could just look for a specific list of POST fieldnames.) Not sure if I'm missing something, but I'd appreciate any input. Thanks! Peter