Soma

If the garbage collector on server is set wrong this can happen. The good news, there's is now DB session module in PW since some versions in dev already to handle session via DB. Just install it. https://github.com/ryancramerdesign/ProcessWire/tree/dev/wire/modules/Session

I'm not sure this was already before but when editing page there a token doublicate in html source: <label class='ui-widget-header' for=''>Children / Subpages</label> <div class='ui-widget-content'> <div id='PageListContainer' data-token-name='TOKEN1566834131' data-token-value='e633e7ae0a8d5d91d6a630f0d180853b655a560ade29f71a8f9c1e279bc2c09d'></div> <div id='PageListContainer' data-token-name='TOKEN1566834131' data-token-value='e633e7ae0a8d5d91d6a630f0d180853b655a560ade29f71a8f9c1e279bc2c09d'></div> <ul class='Inputfields'> ...

Thanks Ryan, this sounds great news!

Or url segments on the root template.

The above example already has lots of overhead so the more optimized way would be to avoid as much get or find and template stuff and do something like this: function segmentUrl(HookEvent $event){ $url = $event->return; // requested url $segment = "/about/"; if(strpos($url,$segment) == 0){ $event->return = str_replace(rtrim($segment,'/'),'',$url); } } $wire->addHookAfter('page::path', null, 'segmentUrl'); Will be a lot faster.

As example to "rewrite" the url of certain pages, this is possible within the template code: function segmentUrl(HookEvent $event){ $url = $event->return; // requested url $pages = wire("pages"); $page = $pages->get($url); $segment = $pages->get(1001); // get segment we want to strip // for example only for certain pages under a certain section if($page->template == "basic-page" && $page->parents->has($segment)){ // set event return the stripped new url; /about/childpage/ becomes /childpage/ $event->return = str_replace(rtrim($segment->url,"/"),'',$url); } } $wire->addHookAfter('page::path', null, 'segmentUrl'); Or similar as in a autoload module (HelloWorld.module) it would be almost same code, just $this->addHookAfter("page::path", $this, 'segmentUrl');

Do you really think "domain.com/drills" is a good strategy? Have all pages on the root? You miss a lot of if you reduce it that way. There's no way to surely determine a single page name, because there can be multiple of it, and you can't control it anymore. I'd consider this for shortcut urls you use in print or something, but not as a general approach to the site on all ends. At least have a category domain.com/powertools/drills/ that gives you powertools as a category. There's maybe too many ways and scenarios with build a urlSegment system, and I would advise to use it only where really needed. How you approach it also depends also a lot how you structure your page tree with what templates. To construct some category/product urls segments are great. Where category is itself a page you use with a page field to categorize product. Then the category pages with url segments enabled and list products that belong to that category, or if url segment present show a detail page. That's how I use url segments to virtualize a structure that is different from the admin. But leaving the real url intact would sure make sense to use canonical urls or redirects to solve it. You can alter the url path PW generates, so a hook into page::path or page::url would do the trick to strip out segments. Once you have that url hook in place it would also effect the Wysiwyg urls generated. But this comes maybe with some overhead added to what might get called thousands of times, though not noticeable unless you go wild. You can also have the template file for those pages redirect to a shorter url and use that template only to construct it.

you have "page-edit" permission in module info. So my editor can see it. Is this intentional? Could you change it to "batcher" or something to give it to users instead?

Sure you have to do some extra efforts but it's not that hard as it might first seems coming from others systems. No problem. But this way you are in full control and can change it the way you like and are not restricted to some built in feature.

Maybe also look at this example here https://gist.github.com/somatonic/3558974

If something I learned over the years, it's to watch your css for navigations ... as simple as possible pays out. However since older browsers are left behind it good to move on. I updated the Module to 1.1.7 to fix the warning. Thx for mention.

I dont really get what the problem is. You have the current parent and the section. list_field_class => 'p{id}' Then in css li.parent.p1001{..} Or li.parent.p1001 > a { ..} To style active section item with parent id 1001

Thanks mats for the heads up. I think It was late when doing this. Have to take a look a again at that $class variable. I should practice what I preach As for the wish, I'm not sure what you mean because you can aleady define what you want: parent_class : class for all active parents has_children_class : class for parents that have children now new list_field_class: add classes like {name} to each item (which is what you need not?) so a active parent of the current page will have <li class="parent has_children about">... I didn't just add this new feature to "parent_class" because adding the possibility to add {fieldname} to all items covers all needs and not just for parents.

Ah se you already found a solution... Here how it would be done. Simple. // html output echo "<ul id='$repeaterPageId' class='gallery'>"; ... <script> $(function(){ var options = {}; $("#<?php echo $repeaterPageId;?> a").photoSwipe(options); }); </script>

Add photoswipe init once through a class you then give to all galleries and be done. <script language="javascript" type="text/javascript"> (function(window, $, PhotoSwipe){ $(document).ready(function(){ var options = {}; $(".gallery a").photoSwipe(options); }); }(window, window.jQuery, window.Code.PhotoSwipe)); </script> No need to create a javascript code with an unique id for each gallery you add in html.

Its a real pain to scroll 2km code down on mobile. Just to get to the next message.. And while im down here already I thought I'd say something.

Use filter on template screen above to show system templates. Select user template add fields to it you want.

I noticed that when I resize the image in TinyMCE in Chrome it wouldn't resize really. The dragged image is smaller and width and height set in image tag. But when saving and looking at source the image is still the original! I noticed this because of responsive image css with max-width: 100%; It wouldn't show scaled version but still same size. In FF it worked and I tracked it down to in Chrome the click event check for the nodeName wouldn't return IMG for the first mousedown event for some reason. The check for the nodeName on the selection of TinyMCE would not return "IMG" . After trying to find a solution deperately I found a really minor fix that solves the issue in Chrome while it still works in FF. The trick is to just get the event.target instead. And I hope in other browsers it still works too but I'm sure it will. But maybe with IE could test this out? I made a pull request on the responsible TinyMCE PW plugin file. https://github.com/ryancramerdesign/ProcessWire/pull/174 Changed file https://github.com/somatonic/ProcessWire/blob/7c4d160152aae3aeb33b68a852c45c35008b0b54/wire/modules/Inputfield/InputfieldTinyMCE/plugins/advimagescale/editor_plugin.js

Thanks Nico! It's still 2.0.5 on http://modules.processwire.com/modules/process-preview/

Nico already showed how to get it. $repeaterPage = $page->get("name_of_repeaterfield")->first(); // gets first repeater $repeaterPageId = $repeaterPage->id; echo "<div id='$repeaterPageId' class='gallery'>"; Is same as: $repeaterPage = $page->name_of_repeaterfield->first(); // gets first repeater $repeaterPageId = $repeaterPage->id; echo "<div id='$repeaterPageId' class='gallery'>"; Or loop through repeater as if they're pages (they are) foreach($page->name_of_repeaterfield as $repeaterPage){ $repeaterPageId = $repeaterPage->id; echo "<div id='$repeaterPageId' class='gallery'>"; }

Just pushed an new update today to replaced the "page-edit" permission from module config and replaced it with 'modules-manager', as editors with page edit permission were able to see this module in the admin. So please update to the latest version in case you don't want you're editors to see Modules Manager. Thanks @jkenters for the issue report.

I just commited an update to 1.1.6 While editing the wiki documentation page it somehow was deleted after editing doh! So updated readme a little and copied that to the wiki. `list_field_class` option (new in 1.1.6) You can optionally define custom classes using a string that can contain tags for field names of pages. For example: 'list_field_class' => '{template} p{id}', will add ' basic-page p1001' to each 'list_tpl' class string.

I might add a list field class option string, so you can add fields you want to each <li> item. so you could add whatever classes and do: 'list_field_class' => '{template} p{id}', and it would add this to every page list_tpl. And if left empty (default) it won't output. I think then with this one can cover all aspects a basic navigation needs more or less.

You're welcome. I can't see where you say, I changed it all I thought. nevermind found it... thx.

Hey @mats, can you tell a little more what you want to do or better why, so I can think a little better?