adrian

Welcome John, We're a pretty friendly bunch around here. As long as you're willing to learn, you'll get plenty of help! I am certain you'll find PW a huge relief after the pains of WP!

Kongondo - just wanted to send a big thanks for this - just used it for the first time as a way to provide a preview of content from a hidden page tree and a modal edit link to edit that content - really very handy!

Just a quick FYI - thanks to a tip from Ryan I have been able to remove the need for making the numChildren method hookable, so if you are interested in the new features on the dev version for hiding the children from the page list view, go take a look now - no need for the core modifications.

A quick look at your source code shows that it is Royal Slider: http://dimsemenov.com/plugins/royal-slider/

This looks fantastic kongondo - thank you! I will try out soon and let you know if I have any problems/suggestions.

Just a quick screenshot of the Lister mode in action - note that I have toggled editing on for the first "Story"

I definitely thought about not hiding the children for superusers - just didn't worry about it too much for this first version. Determining which roles they are hidden for is definitely another option. The config settings for this module are definitely getting complex - maybe I have already passed a critical feature-bloat point, but I definitely see your point. The main thing I want to improve on is the Lister mode option in this new scenario - I think that it is the most powerful and unique option due to the inline ajax editing - the only catch at the moment is that it is embedded in an iframe (like Ryan did with newish Template > Usage lister. The inline ajax editing works awesome (if you have Lister Pro), but right now Add New and modal editing don't work. I will try to tackle these again shortly.

Bernhard - that's a good question. In general hiding pages in the Page Tree can be problematic with child count and pagination, but I don't think this will be a problem for BCE given that when it hides pages it hides all the children of the page (not a select list). That said, this new feature is not well tested yet (which is why it is in the dev branch), but I am implementing it on a live site in the next day or two, so it will get some good testing pretty soon. Give it a go and let me know what you find - I am undecided at the moment if this is a good idea or a bit of a hack, but I really like the way it looks and works!

There were some changes made a while back - can't remember if they were just changes to the module, or also the core - I think the core, because there was a limit that prevented it showing more than 10 modules. That looks to be BFD Calendar's issue - not sure if the same for you too. Can you try the latest dev version of PW?

Hi everyone, New version committed to the dev branch which adds some interesting new features. I have had some clients confused by the use of child pages for repeatable elements. I know we have PageTable, but a couple of versions ago in BCE I introduced the ability to embed the editor within the Content tab (or a new tab, etc). This provides an alternate interface for editing child pages within the parent page. I think this was useful (and has become my default over PageTables). It can be especially cool in Lister mode where you can have inline ajax editing of child pages. This new version adds the ability to hide the child pages from the Page Tree and and also if you want, to hide the Children Tab. This means that clients have no idea that the content is stored in child pages. I know that you can also do this with an external page tree for PageTables, but that hidden "black box" still makes me a little uncomfortable at times, so this is a bit of a best of both worlds. The only catch with the hiding of child pages in the Page Tree is the count of child pages. To make it work I needed to make the core Page::numChildren method hookable. I have asked Ryan if he'd be willing to do that in the core, but for now if you want this feature to work properly, you will need to make this change yourself. Here are some screenshots of the new options and functionality. Two new settings: Note that the About page has no children listed: Child pages are editing within the content tab, but nowhere else because the Children tab is also hidden:

Have you seen Martijn's great module: http://modules.processwire.com/modules/admin-custom-files/

2.6.1 is the stable version, but 2.7 is due out in about a week, so for a new project I would definitely say go with the dev branch (https://github.com/ryancramerdesign/ProcessWire/tree/dev). Just don't use the devns branch yet - it will be the 3.0 version down the road a little!

I decided to have a look around and discovered the problem is that the rebuildForPage method is not being called when a new page is added. This fixes it for me (note the addition of !$page->created): } else if(count($changes) || !$page->created) { $this->rebuildForPage($page); }

True enough - it depends on how you are looping through the child pages. Perhaps something like this: foreach($page->children() as $dam) { echo $dam->country->title; }

I think you are using a pagefield called "country in the dam template. If so, then: $page->country->title

I have a similar (I think) issue to soma - I need to restrict a role to only be able to edit all pages in one branch of the page tree. Initially it looks like this module makes very easy work of it, but what happens when a new page is added to the page tree - the index is not rebuilt, which means that the new child page won't be editable by the dynamic role. At the moment it seems like the only fix is to open this module, change one of the selectors, save, then change it back to what I want and then save again - then the new page is added to the index of pages that are editable by the dynamic role. Am I missing something?

List of PW modules on Packagist: https://phppackages.org/s/processwire https://packagist.org/search/?q=processwire Makes me wonder - should all module authors be submitting their modules to this list, especially now that PW 3.0 will have composer support?

I just tested Macrura's group approach and it works for me on an ImageExtra field. It's modified slightly to match the fields/templates I have in my current sandbox install. I can't imagine why CroppableImage would affect this. $q = 'testtag'; $matches = $pages->find("template=home, (title|first_name|body%=$q), (images.tags*=$q), limit=150"); foreach($matches as $p) { echo $p->title; } What happens if you strip it down to the basics, like this: $q = 'testtag'; $matches = $pages->find("images.tags~=$q, limit=150"); foreach($matches as $p) { echo $p->title; } Also, try putting this as is in a template file to make sure nothing is going wrong in getting $q to the selector. Of course you could also just echo the value of $q in your search template as well, but you see where I am headed

Could you post a list of the modules you have installed on the site that is having the problem. A quick glance might give us a clue of where to look.

This post shows how: https://processwire.com/talk/topic/5610-field-template-context-on-frontend-forms/

Ok, so in the Blue VR Site Profile take a look here: https://github.com/gayanvirajith/BlueVrSiteProfile/blob/master/templates/_done.php#L84 This is where menu functions are being called. Try replacing that one line with this: $homepage = $pages->get('/'); $children = $homepage->children(); // make 'home' the first item in the navigation $children->prepend($homepage); echo renderTopNav($children); Untested, but I think that is what you need in that situation.

I completely agree - I think it would be more targeted and efficient that way, although I am guessing he probably won't want to bother with the str_replace option I just introduced. My need for that is probably an edge case though

Just made some changes to the gist. It now uses square brackets [ ] and not curly braces {} It now limits replacements to just description and notes paragraphs You can now define str_replace $search and $replace like this. In this example I needed the dashes in $page->name replaced with underscores, but you can use however you want. [page.name.(-|_)] Not sure that my code/regexes are the cleanest - I needed this is a bit of a rush, but it seems to work well and I am really finding this very useful in many of my fields. I'd definitely be keen on hearing feedback from anyone else who tries it and if you think it warrants being included in the modules directory. I think I will likely use it on most new sites, but maybe it's just me

There are many different ways to do this, so without seeing your code, it's hard to know what would work best to match what you have, but take a look at this: https://github.com/ryancramerdesign/ProcessWire/blob/cffb682836517065d7dd7acf187545a4a80f1769/site-beginner/templates/_head.php#L21 See how the homepage is prepended to $children so that when it is foreach'd it will be included. Does that help?

Ryan wrote this one: http://modules.processwire.com/modules/fieldtype-events/ as an example / starting point for writing your own fieldtype/inputfield. Of course there are others in the modules directory as well that you can steal from