Dani

Hi Robin S Thanks for joining in This sounds like a promising approach, although it still looks to me like a work-around - I'd really like to have a solution where at a single point in my code I hook in and unpublish a page at runtime. But I'll definitely try your suggestion out. Maybe I'm just too optimistic and/or don't understand some PW principles which would prove my idea absurd...

First of all, I greatly appreciate your help. Thx! Note that I am running a multi-site setup (using Soma's / Apeisa's Multisite module), not a multi-instance setup. There are two sites (dev and production). So all pages live in the same PW instance. For that reason I intend to flag certain pages as "dev only" to see how they would look like in the context of the rest (i.e., on the dev site together with all the pages in production) while they are not quite ready yet. Such pages might not be ready yet because the still need some content to be worked out, or I try out new layouts, styles etc.

Well, in my opinion, this would just be a workaround for my original requirement. As I said initially, my ideal solution would be to set the status of a page at runtime (e.g., in the ready.php file or with a hook at the right place) and that the page thereafter behaves as if it had had that status from the beginning of the request. But maybe this idea contradicts some general principles of ProcessWire. Maybe the status of a page is supposed to be persistent in the DB and shouldn't be changed at runtime. But then, why do we have methods like $page->addStatus(Page::statusUnpublished); at all? Maybe someone can clarify the purpose of such methods. I am happy to learn

Yes, personal in the sense that I am webmaster and want to see the effects of new developments (changes in the layouts, new pages etc.). It's not the requirement of a customer. Regarding your question Yes. The idea is that on dev.mysite.com anyone (i.e., also guests) can see the changes. One doesn't have to be logged in to see the changes. I know it's kind of a "risk" because such a dev site would be more or less public (if one knows the subdomain - security by obscurity if you like). By "menu" I meant the front-end menu, which I generate automatically by Soma's Markup Simple Navigation module, i.e., I don't assembly it "manually" on my own. That's one of the reasons I want those dev pages to behave like normal pages on the dev site.

Hi kongondo Thanks for replying. The intention is the following. Apart from my production site (www.mysite.com), I have set up a development (dev) site to try out new things. I have a copy of the site/templates folder (site/templates-dev), where I change templates (layouts, CSS etc.) and which I access through a subdomain (dev.mysite.com) by changing the corresponding variables in the config file. I would now like to also create new pages that do not yet show in my production site, but do show and behave in my dev site like all other pages. In particular, these dev pages should also show up in the site menu. My idea is to have a page field, which determines if the page shows in the production and/or in the dev site. To show in the menu, e.g., such a dev page must be published - but nevertheless should not show in the production site. I hope I made myself understood. There might be other approaches that do the trick. I'm happy to hear

Hi all, I'm trying to unpublish a page at runtime, depending on the value of a page field. I tried to do it like this in the file ready.php: if ($this->page->hasField("showPageIn") && $this->page->showPageIn->has("title=Dev")) { $this->page->addStatus(Page::statusUnpublished); } However, it doesn't quite have the intended effect. When I render the page in the frontend, I get an error: Exception: Page '[my url]' is not currently viewable. (in /home/me/public_html/wire/modules/PageRender.module line 388)" I'd like the page to behave like a page whose "published" flag in the settings is unchecked. Any help/solution is highly appreciated. Thanks!

Dear community I've had an annoying problem for a few days that's driving me nuts. In short: When a user successfully logs in to my website (frontend login form), the session get's lost almost immediately afterwards. What I mean is: The user variable is set to "guest" again. Funnily enough, this only happens when the language is set to German, but not when it's English... Here's the longer story. First my setup: PW 3.0.62 Multilanguage: German (default) and English Multisite (using Soma's Multisite module) ProCache and FormBuilder in use The login is done in a separate browser (incognito Chrome), i.e., I'm not logged in parallel in the backend. The symtoms are as follows: Coming from a German page (i.e., URL starting with /de/...) and executing $user = session->login($username, $pw) wire('user')->language changes to English, which I don't understand. I assume it should remain German, shouldn't it? I read in a different post here that the user's profile language (backend setting) is ignored in such situations. Immediately after successfully logging in, I redirect the request to the user's account page: $session->redirect($somePage); After that, the session is lost. I.e., $user is set to "guest". I notice a similar behaviour when submitting other (i.e., non-login) forms when "Session tracking and CSRF protection" is enabled: I get an "Invalid form submission" error in German, but all's fine in English. I noticed it had to do with the session ID, which is used to validate the submitted forms. Can anyone explain these symptoms and/or give me a hint what could be wrong? I am happy to provide more details. Many thanks!

Hi Zeka Thanks for your answer, which was not only fast but also precisely what I needed. -Daniel

Hi there I want to render a page in a particular language, somehow like $page->render('de'). How can I achieve that? Some background information to my problem: I wrote a module that generates HTML newsletter emails. From the PW backend I use that module to send emails, which are represented by pages that are rendered and sent off. Now I want to control the email language. The email shouldn't be just rendered in the language of my backend user account, of course. Any help is much appreciated. Best, Daniel

Thanks, Robin! I'll give it a try.

Dear all, I have the following situation: There's a template with a PageTable field. All the PageTable elements may have different templates - let's call them element templates. These element templates use specific stylings and scripts. E.g., one element contains a contact form (built with FormBuilder) that needs form-specific CSS and JS. The page elements are not direct children of the page. They're attached to a separate page that serves as an element container. But that's just an aside. I general, when it comes to rendering my pages, I am following the "delayed output" strategy suggested by Ryan. Now my question is this: When I render the (main) page with all its PageTable elements (with possibly different templates), how do I include all the elements and their templates in the rendering strategy? Of course, in my (main) page template I could simply iterate over the elements and render them. However, at the time of rendering these elements, I haven't included their custom styling and script requirements yet. I should somehow do that before so that such specific stylings etc. can be included in the <head> section of the generated output. I hope you understand what I am trying to convey. I just want to do it the beautiful way, or the PW way Any suggestions are appreciated.