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.

And what was the solution? I too found this happened and I'm without right now. Luckily, the site isn't ready for multi-language launch, but it will be one day and I'd like a fix. Thanks.

Mr. Pirate, thanks for the pointer. I didn't know about ProcessPageFieldSelectCreator. Now I do . It could be useful to kick start a branch and to do the grunt work. It still creates two templates where (IMO) only one would have done. And it creates a page field whether I wanted one of not. But it's superb for a lot of purposes. Thanks.

@Macrura, yes, many do. It's also a question of presentation for the user. I use this for lookup tables. Say a resource that is findable on the site can have: - one of many neighbourhoods (neighbourhood have a map) - one of many sizes (a size has a title, but also a numerical value) - one of many amenities (no special field here, just a name). All these (and maybe more) each have a container node on the root of the page tree, or in a sub-root like "lookups". Each container only hold a specific template, but every container is identical other than that.

@horst, thank you for giving this some thought. I'll confess I did not follow all your listing. I think you're describing what is in the DB. What I'm describing is what is the admin user interface. I think you're concerned with the possible performance issues of injecting a module in the mix when you believe it's redundant. And you're concerned there will be a lack of transparency in the structure if some new meta data is introduced to control the shape of the tree. On the one hand, I like that the template collection can be very structured. It's a strength of PW. It reflects what the shape of the page tree can be. On the other hand, when I'm creating a new site, every time I need to insert a new type of object in the tree for the users to maintain, I have to create a container as well as the actual object of interest. The container is often very generic -- its ONLY purpose is to constraint the type(s) of children under it. Most of the time, it's a single child type (template) that is needed. When I need to modify templates, I have to exclude from my gaze the container ones. It "looks" messy to use. Also, when I set up a "container" for pages of a particular template, I usually don't want the user to change it. They might change the title(s), but that's about it. In those cases, a dedicated template instead of a generic one feels not "DRY". So, after I wrote my previous post, before reading your further thoughts, and still believing this isn't redundant, I went and built a simple module to deal with issue. I'm going to start using it for myself. I hope some find it useful. I hope I'm not trampling on some of the principles behind PW. I'll say it again, I think PW offers a fantastic model for building sites. Its "object tree" is brilliant in its simplicity and transparency for the user and the developer. And yet here, I think there's a hook missing. https://github.com/jeanrajotte/processwire_module_PageAllowedTemplate Looking forward to feedback. Thanks.

I found this thread because I was looking to solve the very same problem. It does look like a new module would be needed. The "problem" that I see is that you end up with an explosion of templates "polluting" the list, where they don't do anything else than constraining what their children can be. colour colours image images member members news-item news-items region regions Double the noise, double the funk. So, I'm with @MarcinP and I might (maybe, perchance) do something about it...

@LostKobrakai, thanks for your reply. I see what you're saying. I'll go in that direction. There aren't as many colours as there are things, of course.

Hi all, I'm wondering what the faster, most scalable, way to populate a search criterion <select> control would be, in a case as follows: Let's say there's a list of colour pages: red, blue, etc... They are referenced as thing->colours in the thing template, in a multi-value Page field. It's possible not all colours are actually assigned to things (e.g. maybe no thing has green in its colours field). Now, in the search form, if I build a <select> as follows, I'll end up w/ "green", which invites empty search results -- teasing the user... foreach($pages->find("template=colour,sort=sort") as $item) { ... } Here's my current solution. I'm wondering whether it'll scale and perform. In the following code, I exclude MarkupCache to keep the logic clearer: $things = $pages->find('template=thing'); $ids = implode( '|', array_unique( explode( '|', $things->implode('|', 'colours')), SORT_NUMERIC)); foreach($pages->find("id={$ids},sort=sort") as $item) { ... } $things could be a rather large PageArray. Is PageArray->implode() efficient? Is array_unique efficient? Yes, I could do measurements, but I was wondering whether this common problem already had been given some thought? Bueller? Many thanks. Jean

In my copy, this is what it looks like now. I don't know whether I'm missing something. I haven't created a module w/ hooks like this yet. public function ready() { // backend hooks $editedPage = wire('pages')->get($this->config->input->get->id); if(@$this->page->process == 'ProcessPageEdit' && !in_array((string)$editedPage->template, $this->excludedTemplates)) { $this->addHookAfter("ProcessPageEdit::buildFormContent", $this, 'addSEOTab'); $this->addHookBefore("ProcessPageEdit::execute", $this, 'saveSEOTab'); } // frontend hooks // if($this->method == 'auto' && $this->page->template != 'admin') { if($this->page->template != 'admin') { $this->addHookProperty("Page::seo", $this, 'hookFrontendPage'); $this->addHookProperty("Config::seo", $this, 'hookFrontendConfig'); } } Actually, why are you even explicitly skipping the 'admin' template if you have a mechanism for excluding templates in place and the 'admin' one is added by default? Then, maybe, this is it: It works, not stress-tested... // frontend hooks if (!in_array((string)$this->page->template, $this->excludedTemplates)) { $this->addHookProperty("Page::seo", $this, 'hookFrontendPage'); $this->addHookProperty("Config::seo", $this, 'hookFrontendConfig'); } ?

I'm very excited about this module. Thanks galore Nico. I need all the help I can get w/ SEO. This is a boon. From my reading, I agree with a prior comment that the automatic rendering should not be at the bottom of <head>, so I set the method to "manual", and tried to use <?php echo wire('page')->seo->render; ?> long-hand toward the top of head. It smoked! In your ready() function, $this->method == 'auto' should not be a condition for initializing the front-end hooks. Thanks.

I'm with mr-fan -- I have an analogous data structure. Reading the code in InputfieldPage.module isValidPage(), I come to the conclusion that the field's option to select pages using "Custom PHP code to find selectable pages" should not be used until you can actually save the pages, which you can't right now because they don't validate. I just replaced if($field->findPagesCode) { // TODO: we don't currently validate these } with if($field->findPagesCode) { // DONE $inputField = $field->getInputfield( $editPage, $field); $validPages = $inputField->findPagesCode( $editPage ); // if the page is in the list, it's valid. No more questions asked! return $validPages->get( 'id=' . $page->id) ? true : false; } Can't it be this simple? I must be missing something? Is it a performance issue? I'll submit a patch and see whether it passes mustard with the head dogs