kongondo

Maybe no need since others encountering the problem will probably hit the 'wrong results returned' issue first (like you did). It's your topic though, so, if you wish, just edit the Title of the thread by editing your first post.

No worries. I get your point . In this case, though, the module in question has its own support forum, hence, all questions regarding it should be directed to its support forum. Edit: I think our forum guidelines could be clearer in this regard, though. I'll have a word with the other mods.

Nope. You can delete it if you want. In that case, let PW know what to use for 404 config (see below) Yes. Quite the overkill . just move page with ID 27 under /admin/ (i.e., re-parent it). Editors will not be able to see it. OR Create a new 404 page under /admin/ (and delete page with ID 27 or reuse it for whatever). Editors will not be able to see it. Add this to /site/config.php $config->http404PageID = 1234;// ID of your new hidden 404 page. That's all there is to it.

Some blog pages are missing style sheets: /blog/categories/ /blog/tags/ + children /blog/authors/ + author pages /blog/archives/ + (year and month) blog/post/

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?