Robin S

I think the features of Lister Pro could be suitable. You can set permissions to any given role to access any given Lister, lock down which pages the Lister can display, use Actions to perform bulk field edits for selected pages, and also allow individual fields to be edited inline without needing to open pages for editing. In other words, it's pretty fantastic.

Wow, I need to up my prices. US$5000 for a 4-9 page CMS website with no special features? Nice work if you can get it.

+1 for that suggestion. In the meantime, if you wanted to add that feature to your site you could copy the FieldtypeComments module to your /site/modules/ folder and edit the methods in CommentForm.php (because unfortunately the methods aren't hookable). You would add the honeypot inputfield in renderFormNormal() and renderFormThread(). And then check that the inputfield is empty in processInput(), changing empty() to !empty()... if($key = $this->options['requireSecurityField']) { if(!empty($data[$key])) return false; }

The tabs "Pages", "Setup", etc are just pages under the Admin branch of the tree. You can add your own pages here to make new tabs. To put content on that page you can use the Admin Custom Pages module. Or it's not difficult to create your own simple ProcessModule.

Most (all?) links made to individual replies/posts before the forum upgrade no longer work correctly in the new forum. This is frustrating because you have to hunt around for the actual reply that was referenced and reduces the usefulness of all the older posts that supply solutions to problems by linking to a specific reply. It seems like this should be possible to fix. Compare these two links to the same post, from the old forum and new forum: https://processwire.com/talk/topic/3474-admin-custom-pages-module/page-5#entry56657 https://processwire.com/talk/topic/3474-admin-custom-pages-module/?do=findComment&comment=56657 Can we get old links redirected or updated to the new syntax? Edit: what's worse is when you get this... When the new forum tries to be smart and make an iframe out of a broken link there seems to be no way to find out what thread/reply was linked to, even by inspecting the page source.

The documented example for $session->login() sets the returned user to a variable and then tests the variable (and this is how I use the method in my custom login). $u = $session->login('bob', 'laj3939$a'); if($u) { echo "Welcome Bob"; } else { echo "Sorry Bob"; } The way you are doing it should be fine, but try setting a variable and then you can log/dump the variable to see what is being returned. I guess it is returning null but it pays to check. You could also test if you can log the user in successfully by using $session->login() directly as per the example above, to narrow down where the problem lies.

FYI: there is a GitHub issue open for this problem.

Check that the MarkupSimpleNavigation module is actually installed. The class returned for $treeMenu should be "MarkupSimpleNavigation".

Looks okay to me. A couple of minor things that won't be related to your problem: $sanitizer->username is deprecated in favour of $sanitizer->pageName I don't see where you set the default state of $error, so you may get an undefined variable notice when an exception is not thrown. Things to try: log $username and $password before $session->login() to check that the variables are holding the correct information. can you login with this username and password at the PW admin login?

Not working as in fatal error or as in no menu? I take it that there are some pages in your top level that you don't want to include in the menu - can you describe what you're trying to achieve?

Are you sure you're using the "selector_field" option correctly? What is the contents of this field on pages where you are using it - is it a valid selector? I would consider "selector_field" to be an advanced option that isn't needed for most menus. For most situations the "selector" option is sufficient.

How about making the title field non-global and removing it from your newsletter template? Maybe you can set your page name automatically using the "Name format for children" feature so users don't need to worry about typing a valid page name.

In /site/init.php... $config->css_files = new \ProcessWire\FilenameArray(); $config->js_files = new \ProcessWire\FilenameArray(); In your Hanna Code PHP... $config->css_files->add('/site/templates/path/to/file.css'); $config->js_files->add('/site/templates/path/to/file.js'); Wherever you output your <head>... foreach($config->css_files as $css_file) { echo "<link rel='stylesheet' href='$css_file'>"; } foreach($config->js_files as $js_file) { echo "<script src='$js_file'></script>"; } See the code for the FilenameArray methods available: prepend(), remove(), removeAll(), etc. P.S. you can use the existing core $config->styles and $config->scripts FilenameArrays but other files might be added to these by certain modules so cleaner to create your own FilenameArrays I think.

Just used this snippet - really great solution!

I think the problem here is the way you are mixing PHP and HTML together: <? foreach($page->home_sliders as $home_slider) { <li class='orbit-slide'> This isn't valid PHP - you need to either echo all the HTML or switch in and out of PHP like so... <?php foreach($page->home_sliders as $home_slider): ?> <li class="orbit-slide"> ...more HTML... <?php endforeach; ?> As an aside, the short PHP open tag <? is discouraged - the short echo tag <?= is okay though.

Better to store the selected pages in a PageArray: $children = $page->children; $uniques = new \ProcessWire\PageArray(); // assumes PW3 foreach($children as $child) { $uniques->import($child->size); } $uniques->sort("title"); foreach($uniques as $unique) { echo "<button class='filter' data-filter='.size_{$unique->title}'>{$unique->title}</button>"; }

In a related topic in the ProFields sub-forum @ryan has said: So please log any SQL mode issues at GitHub as they arise so they can be tracked and resolved.

If you mean they display content from your web server in an iframe then it doesn't matter what server technology is involved (PW or otherwise) because the iframe content loads on your server not theirs. You could use a URL segment such as /embed/ so that pages loaded with this segment do not include header, footer, etc but only the panorama content. Might not be something you want to tackle but just wanted to point out that it's possible. I'm not aware of any existing module that does this, but as I mentioned in an earlier post above wouldn't be difficult to create your own module that lists directories as options in a select field. The trick is getting the names of the valid directories you want to include as options into an $options array.

Two possible solutions for your author/member pages: 1. Use separate templates for your author and member pages. For the author Page field (used in the publi template) your "Custom selector to find selectable pages" is: template=author|member To differentiate between author and member in your foreach loop: if($item->template->name == 'member') { // do something only for members } 2. Only use a single template for all authors (including members), but add a checkbox field 'member' to the author template to signal if the author is a member or not. To differentiate between author and member in your foreach loop: if($item->member == 1) { // do something only for members }

Using $page->render() to render the page with its template file (or another file you specify) has been around much longer than the $page->render('some_field') introduced in PW3 but the documentation has been a bit lacking. The cheatsheet doesn't help much and it's not covered in the new API reference - the best explanation I have found is this post from Ryan. Personally I think it would be clearer if individual fields were rendered exclusively with $page->renderField(). Using the existing $page->render() method when that was previously used for rendering whole pages with different options (e.g. the ability to pass your own array of variables) leads to some confusion.

I think you access the array with $options rather than $page->options.

$author = $pages->find("template=member, title=$page"); This part doesn't make sense unless you have a page using the member template whose title is a page ID. I don't think you need this line.

More thoughts... 1. Could you reproduce the path to the PW page as a folder structure inside /site/templates? If your page is at mydomain.com/gallery/location-1/pano-1/ then you put the dependent files in /site/templates/gallery/location-1/pano-1/ and build the path to the files with: $config->paths->templates . $page->path() Then you don't need to select a folder in the PW admin (you just have to remember to upload your files to the right folder). 2. I reckon that by inspecting the code in the dependent files you'll be able to work out how to output it directly from your template file. Then you don't need to deal with these folders of dependent files at all - just upload the images to an image field on your page. Could you share an example of one of these pano folders so we can see what's in the code?

$page->render("some_field") is an alias for $page->renderField(), and passing in an array of your own variables is not supported currently. I agree that it would be useful and have opened a feature request on GitHub.

For a Map Marker field named 'map'... function renderLocationsXML($locations) { $out = '<?xml version="1.0" encoding="utf-8"?>'; $out .= '\n<markers>'; foreach ($locations as $location) { // use any fields of $location $out .= "<marker name='{$location->title}' lat='{$location->map->lat}' lng='{$location->map->lng}' />"; } $out .= '\n</markers>'; return $out; } $locations = $pages->find("template=location"); header("Content-Type: text/xml"); echo renderLocationXML($locations);