rajo

> I'd really like to build these out if we can get some community contributions. Gotcha. I look forward to exploring that space over the coming weeks. This is for a volunteer project that has nothing to do w/ my day job, hence my wanting some prefabs if possible. I like the component-based approach you're describing. To be continued...

p.s. I'm finding my bearings around here again. I think "Site Profiles" represent what I'm talking about, either in part or wholly. I'll go learn there also. I must say, I couldn't find a definition of "Profile" in the docs, I didn't know what that meant at large. https://processwire.com/ promotes the trees but doesn't say much about the forest and its varied on-boarding trails.

@psy thanks for the warm re-welcome and pointers. @adrian thanks for all that. I'll go see and learn, and perchance embrace.

Hi, Has this community looked at site patterns and created some reusable getting-started models? I know PW is the malleable backend crafters use to roll their own brilliance, but no doubt, by now, some patterns have emerged for the best practices of how to layout the DB, what templates go with what pages, what fields go where, etc, when you're contemplating implementing a News site, vs. a Gallery, vs. a Corporate site, etc. If indeed such "best practices" have been documented, maybe the next step would be packaging those in an installable getting-going thang. I haven't used pw for a couple of years now. I'm currently looking at creating a site that's somewhat like a News site, with prominent articles, archives, some media. But I'm balking at having to roll the whole thing myself from scratch, versus getting a leg up with Bob's News Site Template, a distilled getting-started framework. There's barebones, which gives the most freedom, then there's flesh and bones meant to be extended. I'd think that as PW is maturing, there's enough repeatable history that something could be packaged. Are there such artifacts in this community? Or would that betray PW's anti-WP origins? Of course, these need not be free, as long as the "store" allows you to really grok the package before buying. Thanks.

FYI, I now changed ready-to-edit from 3 to 0. This should make the crazy explosion of empties go away. I notice in the noisy rows that they come in 3's, so... It will make the problem go away, but I still don't have an explanation. Oh well. Onward.

I'm sorry I cannot give examples and have very little clue what's happening. Did I change a flag months ago? Did I experiment and save something wrong in a config somewhere? I don't know, but this is what's happening: Thousands of pages are created over time (months). They appear to be repeater "ready pages". The pages are of status 3073 (statusOn | statusHidden | statusUnpublished). They are children of legit pages, but invisible, yet dragging every query down to the point of timing PHP out. The template is a repeater field w/ 2 fields in it. There is no data in the field_* tables for these pages; there are only pages rows, lots of them! Using version 2.5.3. To clean is up I do: delete pages WHERE templates_id=245 and status=3073 and the noise goes away. However I have no idea how the noise gets introduced over time... ? There were 9,368 pages the last time I did this. Here's the data for this template. Any hint would be appreciated. thanks. === template row: id : 245 name : repeater_boooking_price (sic) fieldgroups_id : 299 flags : 8 cache_time : 0 data : {"noChildren":1,"noParents":1,"slashUrls":1,"noGlobal":1} === fieldgroups_fields rows: fieldgroups_id : 299 fields_id : 344 sort : 0 fieldgroups_id : 299 fields_id : 337 sort : 1 === fields row: id : 345 type : FieldtypeRepeater name : booking_price flags : 0 name : ----- label : ----- data : {"template_id":245,"parent_id":1585,"repeaterReadyItems":3,"repeaterFields":[344,337]} === pages row: id : 1585 parent_id : 1039 templates_id : 2 name : for-field-345 status : 17 sort : 1 name1258 : status1258 : 0

And since I'm wasting cycles here, that Weird Al video criticizes "I could care less" as wrong. This article says otherwise: http://www.slate.com/blogs/lexicon_valley/2014/03/18/why_i_could_care_less_is_not_as_irrational_or_ungrammatical_as_you_might.html

Thanks Mont, your suite, you're sweet.

And, just sayin', you yourself, Martijn, have taught a lot to the community w/ your generosity and code contribution. Have a drink on me. And SteveB, peak at this: Its only fare! [ deobscurifying left as a time-waster for the reader :^]

Martijn, I totally agree, meaning and communication trumps grammar, and processwire stuff trumps anything else in this forum. Which is why I took this to the pub, not to actual work threads. And just in case this conversation takes a turn "to the right", as it were, i.e. with "shoulds" and flags flying for purity, I'll just state my intention clearly: Correct use of language is essential for computers to work, but not for people to work. I like that people correct my grammar in either case, because I like to learn, but I do get ticked off when they do so at the wrong time, distracting from the point I try to make. Peace and love.

Thanks @Mont. The corrected the unit test to: assertTrue( in_array( meaning_of( $phrase ), array( "it is", "it has") ) ); I had had it wrong, now I have it right right?

As a speaker of English as a second language, I really notice this quirky error. I notice it a lot in this community, in the blogs and forum entries, but also on official pages (the latest: The PW Directory, front and centre). "its" means the thing belongs to the thing. "it's" means "it is". The simplest test would be: assertTrue( "it is" == meaning_of( $phrase ) ); IOW, if you can write "it is" right there, it's OK to write "it's". Otherwise, always always write "its". Sorta grumpy today.

Thank you for confirming it's not built-in. IMO, it should be the default so as to be symmetrical w/ the admin UI.

Puzzled! I'm using the API to create child and grand-children pages in an app with more than one language. When a new page is created, I expect to see it via the API regardless of the current $user->language. However, it's not the case. I see that the pages I save in the API have a status field for the language set to 0. (e.g. status = 1, but status1563 = 0), which causes them to not be found when searching in a different languages than the default one. i.e. $page->children()->count() -------> n $user->language = <some other language>; $page->children()->count() -------> 0 This seems very weird to me, in principle. In practice, is there a different way to change the default behaviour of $new_page->save() to set $new_page->status1563 = Page::statusOn ? Thanks. Merci.

@soma: Merci. I knew that once. Much appreciated.