kongondo

Its not straightforward and sometimes frowned upon . Have a look at this thread. And this one: And this one for changing published date: OK, if you've decided to carry on, first, some quick by the way technical tips. If unsure whether something is a runtime or DB property, I check the API: http://processwire.com/api/ref/page/ For $page->created, it says: That gives me an idea that when setting, I should probably set in the same format (Unix timestamp). If unsure, I can check the code or try to pass it a normal formatted date. You never know, ProcessWire can convert it behind the scenes. I sometimes check the database table of the field. This case, the table is pages. This helps me to check out the schema and if the property is runtime or saved to DB. There they are. They are columns in the pages table. If need to, I also check the table structure, but don't need to in this case. OK, to the code. // CURRENT DATES // timestamps echo 'Created Date: ' . $page->created . '<br>'; echo 'Published Date: ' . $page->published . '<br>'; echo 'Modified Date: ' . $page->modified . '<br><hr>'; // formatted date echo 'Created Date: ' . date('D d M Y H:m', $page->created) . '<br>'; echo 'Published Date: ' . date('D d M Y H:m', $page->published) . '<br>'; echo 'Modified Date: ' . date('D d M Y H:m', $page->modified) . '<br>'; // MODIFY CREATED DATE $page->created = 1425898824;// Monday, 9 March 2015 11:00:24 $page->published = 1426762824;// Thursday, 19 March 2015 11:00:24// will not work; @see links to threads above $page->of(false); #$page->save();// @NOTE: WILL NOT WORK; you need below $page->save(array('quiet' => true));// @NOTE: ONLY WORKS FOR CREATED // MODIFIED CREATED DATE echo '<hr>'; // timestamps echo 'Created Date: ' . $page->created . '<br>'; echo 'Published Date: ' . $page->published . '<br>'; echo 'Modified Date: ' . $page->modified . '<br><hr>'; // formatted dates echo 'Created Date: ' . date('D d M Y H:m', $page->created) . '<br>'; echo 'Published Date: ' . date('D d M Y H:m', $page->published) . '<br>'; echo 'Modified Date: ' . date('D d M Y H:m', $page->modified) . '<br>';

Ryan committed a fix for this yesterday. I'll make this thread as solved, although a subsequent potential issue was raised.

Excellent! Glad we got there in the end .

OK. However, index.php will work even without .htaccess. This is what I am confused about. If the .htaccess file is working, you should have seen a server 500 error when you added random gibberish text at the very top of the htaccess file. If you didn't, it means the htaccess is not getting read. Maybe repeat the test to confirm? Could these posts be of help to you?

Using ProcessWire's in-built multi-site support (option #1 here), is it possible to bootstrap the various sites? To bootstrap ProcessWire, the only requirement is to include /path/to/processwire/index.php/. In option #1, there is only one index.php. So, including index.php defaults to bootstrapping the main site (i.e. the site at /site/. Is it possible to bootstrap the other sites, i.e. site-dogs, site-cats, site-birds, etc? I've searched the forums but nothing relevant comes up. Thanks.

Glad it helped .

Welcome to the forums and ProcessWire @h365. Some have found this topic useful when it comes to content/data relations

options_field=value should do the trick. It doesn't matter if your options field is of single of multiple type. ProcessWire will find the values. $page_category = $pages->find("template=single-forniture, your_options_field_name=value");// e.g. oak

OK. But what error do you get in the browser when you remove your supports rules (i.e., using PW .htaccess file as is).. Do you get a 500 Error or 404 Error?

Brilliant! That did it! Meanwhile, I submitted an issue report here.

Thanks. I feel like I'm light years behind! That's what happens when you are a late adopter!

Hmm, that means .htaccess file is not working. What happens if you remove the rewrite rules provided by your support? What errors are shown? Apache logs, what do they say?

the idea was to check /site/config.php to confirm the details in $config->httpHosts were correct.

Have a look at these topics to see if they can help.

Thanks. I'm a bit confused though. $pages should not work in a bootstrap context (you need wire('pages') or equivalent, so how come you are using that, or you'd defined $pages earlier?

Hi @horst. Why did you have to bootstrap ProcessWire? Were both sites not ProcessWire 3.x sites? Thanks.

Aah, I see. I don't know how that module works so I can't comment further. Hopefully others will chime in. I'm still curious though whether Page status can be made to work in runtime context only. Please let us know if you come up with a solution .

Just had a thought. What is the use of the new pages in the live/production site if they are not meant to be seen until they are ready? Are editors updating them with content? If they are not getting updated on the production site, maybe you can just create them on the dev site then when you are ready for them to go live, use the API of either multi-instance or page export/import to re-create and pre-populate (basically mirror) these pages in the production site? Just a thought...

How else would we change the status of a page via the API then ? We use these methods and save the page to commit to the database.

I see. FWIW, MSN can take a PageArray and build a menu off of that. However, they will be first level entries only. I am out of ideas, sorry :-).

I forgot to ask, is this your personal requirement?

I assume you mean do not show in the frontend (via search or in menus) but do show in the backend pages tree, right? If my assumption above is correct, then keeping them unpublished in the live/production site should do the trick without the need for the page field check. This supposes that in the production site, no other user apart from you the supersuser has the permission to publish those pages. Menu in the production site (www.mysite.com): $items = $pages->find('template=some-template');// this will not return unpublished pages // generate menu foreach($items as $item) { // simple menu here } Menu in the dev site (dev.mysite.com): $items = $pages->find('template=some-template, include=all');// this will return unpublished and hidden pages // generate menu foreach($items as $item) { // simple menu here } You can of course add other checks, e.g. if your new pages share a template or parent, you can exclude them from your menus by checking if the current user is you (superuser), etc. Wouldn't the above work or I'm still missing the point? Edit: Yes, there are other techniques to viewing different templates/styles depending on whose viewing the site. I can't find the relevant threads in the forums at the moment.

I haven't tried, sorry. I'll check when I get a bit of time. I've never used the custom user template feature so will have to do a bit of reading first. Have you tried with wire('page')? This post might also be handy (i.e. establishing process context)

Welcome to the forums @xu_phann. Your post reads as if you were responding to some other post. Did you create this topic by mistake?

Aha. I see from the code in your OP that you are bootstrapping ProcessWire? If that's a yes, in bootstrap situation (because output formatting is off), image fields return arrays irrespective of your settings, i.e. similar to module context mentioned above . https://processwire.com/api/fieldtypes/images/