Metadope

First. @kongondo, thank you for these modules. I have encountered a small bug in the MarkupBlog module (I believe). When I invoke renderPosts() with just default options, it renders my example set of posts just fine. When I use the API to invoke the option to make comments (and categories) appear in a post's footer, however, renderPosts() creates some broken content. Specifically, the $numCommentsStr (line 965 in MarkupBlog.module) comes back with HTML-as-text. Background: I installed a new server with PW 2.6, which I then used to DL and install (the latest?) ProcessBlog via the Admin interface. I chose the demo-files option in phase 2, then switched to my own template code, just using the API (and here's my blog.php ): $blog = $modules->get("MarkupBlog"); $myOptions = array( 'post_comments' => 2, 'post_author' => 0, 'post_categories' => 2, 'post_large_headline_tag' => 'h3', ); $content = $blog->renderPosts("limit=11", false, $myOptions); Straight forward and simple, (inheriting the same appearance code as the main PW example site). Meanwhile, rendering a single post with the same option (put the comment count in the post's footer) works just fine. Here's that file ('blog-post.php'): $blog = $modules->get("MarkupBlog"); $blogConfigs = $modules->getModuleConfigData('ProcessBlog'); $renderComments = $blogConfigs['commentsUse'] == 1 ? $blog->renderComments($page->blog_comments) : ''; $myOptions = array( 'post_comments' => 2, 'post_author' => 0, 'post_categories' => 2, 'post_large_headline_tag' => 'h3', ); $content = $blog->renderPosts($page, false, $myOptions) . $renderComments . $blog->renderNextPrevPosts($page); I examined the module code and couldn't determine what is corrupting the $numCommentsStr. I did notice a difference in the syntax used to render the same element (top uses an if statement and just appends to $out, while bottom uses a ternary op and temp var and concats a bunch of stuff at once), and the odd re-usage of a var $comments (which everywhere else is used to hold an array of comments), It is interesting to recognize that the badly-rendered post (the one with comments) renders out HTML that actually belongs to the post from the previous iteration. Here's the screenshots (multiple page with bad content and single page with good render): I'm a vet C++ programmer, just ramping up to really learn PHP, so forgive me if I'm missing something obvious. Maybe it's a combination of having two non-default options (no Author output + bottom comment count)-- I haven't tried all combos to help with the debugging. I thought I'd call on more experienced PHP folk first... TIA for any comments.

@tpr, thanks, that leads me down the path to diogo's old post about Sisyphus.js, which I can integrate into my version of the default Admin template code. I do feel like Sisyphus today. But this trip up the hill, I'm learning, I'm learning...

@Horst, thank you for the link to the Firefox add-on. As just a user who has suffered from POST fails in the past, that's a very useful tool to add. And, thanks for the forum welcome too. @Diogo, yes, thank you, I do usually work that way, simple Notepad or TextEdit local, then cut-and-paste and Send. Live and re-learn.

Okay, I'm recovering. And, I've found the first part of the answer I was looking for. The session timeout is set in the config.php file (and now don't I feel even dumber than I did before), and it defaults (in PW 2.5) to 24 hours, which is a sane default. I knew that. I just forgot. I left my Admin session open overnight, got timed-out, and lost my work. I've learned this same lesson once before, in other online editing sessions. Never hit save or send a Post until I'd first saved (cut and paste) a local copy (because POST requests fail, for a variety of reasons, and Javascript-based editors are not robust). That's my habit; I was rushed today. But I sure would love to solve this problem once and for all. It is just so counter-intuitive to have to keep remembering that Save means Lose, sometimes. Is there anything I can do with ProcessWire to solve this problem? Maybe a client-side bit of JS to auto-save for the editor, or a session-timed-out message box.... or, other server-side intervention, like creating a temp JSON representation of the refused POST, to be reprocessed after re-authentication...?

Hi all, I screwed up. I just lost a few hours of writing work, and I'm undertaking to understand how and why, and looking for some PW-specific tips on how to prevent this from happening again. I am serving PW 2.5 via Nginx on an AWS micro-site. I was editing the About page (having launched my site (http://Metadope.com) with a slightly modified Example template). I took a long time editing. I wrote a lot of carefully crafted sentences. I was using the default Admin template that ships with PW. When I hit Save, however, I was prompted to log in again. After submitting to the new login prompt, I was horrified to discover that all my edits were gone, and there was no getting them back. The Save had been refused, the edits discarded. I'd like to edit the ProcessWire session timeout so this never ever happens to me again. Can I do that? There's no obvious setting available in the Admin interface, so a that-a-way pointer from more experienced PWers would help. Without changing the default session timeout value (which is what?), I'd also like to understand how the edits were lost in the re-authentication flow. Did ProcessWire drop the ball (new code needed in the session-timed-out handling of a pending POST request)? Or is this something that failed me in my server configuration (Nginx and php-fpm, or mySql)? Any help (or commiseration) is appreciated.