Robin S

Best thing would be to strip it back to basics to try and narrow down the problem: Remove any textformatters applied to the field. Try removing all the content from the field. Try the simplest template file possible, that just echos the field with no prepended or appended files. Try adding the field to a new template that doesn't contain any other fields (besides title) and see if you still get the problem there.

There isn't a PW module that will give you a front-end RTE out-of-the-box. But seeing as it is front-end it doesn't need to be PW-specific; I'm sure there are many JS scripts that turn a textarea into an RTE with varying levels of functionality. This post suggests it wasn't difficult to get CKEditor running on the front-end. I have my doubts about how easy it will be to get images embedded in a front-end RTE. I think it would be better to keep images confined to a dedicated field if possible. The Jquery File Upload module could be useful for handling the image uploads - it can do client-side image resizing. If you want to try and get image embedding working with the native PWimage plugin there is a thread about it here.

Saying an inputfield does not support AJAX loading often just means the inputfield doesn't initialise properly when it is added via AJAX. Probably because it only initialises on dom ready: $(document).ready(function() { initialiseMyInputfield(); }); But if there is an event fired when a new repeater item is added the author of the inputfield module can update it so it will support AJAX loading: $(document).ready(function() { initialiseMyInputfield(); }); $(document).on('repeaterItemAdded', function() { initialiseMyInputfield(); }); But in InputfieldRepeater.js I don't see events being triggered for repeater item add, sort, delete, etc that we can monitor for.

I think that is what this reply covers: GAPI looks like a nice interface for accessing Google Analytics stats.

I agree that repeaters should be firing events, especially on AJAX add. Otherwise how are JS-powered inputfields in the repeater items meant to initialise properly? Currently there are problems like this:

I managed to get the Embed plugin working by following the steps you outlined (adding all dependency plugins, manually adding toolbar button), and then also: Uncheck "Convert div tags to paragraph tags" Set "Use ACF?" to "No". I suppose you could keep ACF active but then you would have to add all the elements/attributes/classes that could potentially be inserted by the plugin into the "Extra Allowed Content" field. Looking at the Embed plugin source it only adds div[!data-oembed-url] as allowed content, but when you check the markup that is added for a YouTube embed (for example) you see a lot of other markup besides the div. There also something going on regarding allowed content in the Widget plugin but I found it difficult to decipher.

Looks like the markup for post-headline is set here: https://github.com/kongondo/Blog/blob/master/MarkupBlog.module#L916 This should work I think: $out .= "<$h class='post-headline' style='background-image:url({$page->blog_images->first->url});'><a href='{$page->url}'>{$page->title}</a></$h>"; You may want to resize the image - see the API methods for this. There is a support thread for the blog module. I believe @kongondo is away at the moment but if you post questions there other users of the module may have advice.

I'm not familiar with the blog module, but I assume that "blog_images" is an images field in the blog post template. If so, you don't want to iterate over the images in that field but rather you want to iterate over the PageArray of blog post pages. So something like: <?php $posts = $pages->find("template=blog_post"); foreach($posts as $post): ?> <div class="blog-post"> <div class="post-thumbnail" style="background-image:url(<?= $post->blog_images->first->url ?>);"> <h3><?= $post->title ?></h3> </div> Other summary content here... </div> <?php endforeach; ?> No doubt the blog module has some cool features, but it's not difficult to build blog functionality into your website using the basic PW fields and no module. Give it a go! That way you'll know exactly what's going on behind the scenes, learn about several different field types, and buzz-out when you see how easy PW makes it to build whatever is in your head.

Yes. In the example... $authors->sort("articleCount"); ... $authors is the PageArray (WireArray) and "articleCount" is the property we sort on.

Another option is to set the article count as a property of the author Page object. $authors = $pages->find("template=author"); foreach($authors as $author){ $author->articleCount = $pages->count("template=article, author=$author"); } $authors->sort("articleCount");

Thanks for the explanations. Is there an instance-aware way to get API variables in function scope?

Getting the authors with the most articles would be simple if the article pages were added to author pages rather than the other way around, but of course that's not so good for workflow. But there have been some posts on the forum that suggest linking two Page fields, where changing one updates the other. Gist by @Martijn Geerts, discussed here Gist by @Soma, discussed here and here These may also be relevant:

In that case your template should be "author" with a checkbox "is_member". foreach($page->author as $a) { if($a->is_member) { $out .= "<a href='{$a->url}'>{$a->title}</a>, "; } else { $out .= "{$a->title}, "; } } $out = substr($out, 0, -2); If you don't want non-member author pages to be viewable on the front-end then at the top of the author template: if(!$page->is_member) { throw new \ProcessWire\Wire404Exception(); }

I think typically a sitemap does not include paginated pages. You can include a "view all" page if you have one, or the first page of results (make use of rel="next" and rel="prev" in your pagination links). Google says:

@mr-fan has made a module that does this: AutoImagePages

If the select fields are Page fields you can use a function like this: function calculateProportions($field_name) { $pages = wire('pages'); $field = wire('fields')->get($field_name); // Only proceed if field is a Page field if($field->type->name !== 'FieldtypePage') return; // Get templates the field has been added to $tpls = $field->getFieldgroups(); // We need a page object to supply to some upcoming methods $p = new \ProcessWire\Page(); $inputfield = $field->getInputfield($p); // The options for the field $select_options = $inputfield->getSelectablePages($p); // Use whichever type of total suits you best... $total_pages = $pages->count("template=$tpls"); // pages that contain the field //$total_pages = $pages->count("$field_name!=''"); // pages where the field is not empty $out = array(); foreach($select_options as $select_option) { $count = $pages->count("$field_name=$select_option"); $proportion = $count / $total_pages; $out[$select_option->title] = $proportion; } // Function returns an array: option title => proportion return $out; } And for each question (Page field)... $results = calculateProportions('my_page_field_name'); If you are using FormBuilder with fields of the "Select" type you could modify the function to suit. I think you get the array of select options with... $form = $forms->get('my_form_name'); $select_options = $form->get('my_select_field_name')->getOptions();

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?