kongondo

That's coming from ProcessWire's file compiler; it is not a bug on Blog's side. Try clearing your file compiler cache to see if it solves the issue.

Maybe two options to consider: WireCache: Create a natural sort field, say nat_sort. Have this hidden; we don't need to see it in the admin. Add that to the template of the pages you need to sort naturally + paginate (let's call the template 'nat-sort-pages'). Create your Hook and add a function that will build/refresh a non-expiring Wire Cache every time a page that uses 'nat-sort-pages' template is created (no need to do this when the page is edited; just when added). The cache will save the new page's ID, Title (the field to naturally sort) and a 'nat_sort' value of 0 (or whatever your starting index is; here we also assume this is the first page created). Subsequently, when another page is added, your Hook will retrieve the cache, add the details of the new page to the array, use PHP natsort() to sort that array (by Title) + change the values of nat_sort within the array, save it back to the Wire Cache, then use SQL to insert the values in your nat_sort field. Your nat_sort field will be an integer field, so you SQL (pseudo code) will INSERT nat_sort_value IN nat_sort WHERE id=page->id. That should be a very fast operation. In the frontend, use a find sorted by your 'nat_sort' field (sort=nat_sort in the selector) to retrieve paginated results. getById() + SQL nat sort: This approach does not require a nat_sort field nor a Hook. It is an on-demand method for use in the frontend. Use a suitable SQL workaround to naturally sort a limited number of results (i.e. see links above + you'll need to use SQL LIMIT and START). Your SQL will only need to fetch the IDs of those pages. Then use getById (see example here) to retrieve those pages, which you then pass on to your pagination. Both approaches have their pros and cons, obviously.

@Doc, please wrap your code in code blocks using the <> icon (7th from the left). Much easier to read that way, thanks.

Depends on the scenario: If I want to retrieve a limited number of pages (with no requirements for pagination), then have those naturally sorted, I'd go for PHP. If I want paginated results, it means I need them to be already 'naturally-sorted' as they are retrieved, meaning, doing it at the database level, then I'd go for SQL. The present case: Using a Hook to amend the values of a group of pages every time a new page is created. If that group of pages is substantially huge, if using PHP, it means, first retrieving the whole group, sorting them naturally, then saving them. That in itself could be a big hit on the server (we are loading lots of Page objects in memory). Assuming pages are created at a high frequency, that further compounds the issue. In such cases, SQL will most likely be faster and use less memory.

No, it is not possible out-of-the-box but there are workarounds: http://www.mysqltutorial.org/mysql-natural-sorting/ https://www.copterlabs.com/natural-sorting-in-mysql/ https://chrisjean.com/mysql-natural-sort-order-by-on-non-numeric-field-type/ If we are talking a potentially huge result set, I would consider a SQL solution (see links above) to update that field for each page in the result set.

Welcome to the forums @TJB. You seem to have made that page's template a system template. You cannot delete system resources like that. You would need to do it using the API. An example here:

Have a look at these discussions: Edit: Not sure will work for you actually, i.e. if you need a database level sort. @fbg13, I'm not sure that will produce desired results since that sort will take place in-memory, i.e. after the PageArray has been retrieved. I think @Jason Huck wants the sort to take place at database level.

@mel47, Please see this note on how to call a menu in a multi-lingual environment: If that doesn't resolve your issue, try refreshing your file compiler cache.

Hi @MaryMatlow, Same way, really. renderPosts() takes 3 arguments, the third of which is $options. Since you need to pass in the 3rd argument, in blog-post.php, line #56, you also have to specify the second argument like so: $options = array('post_comments'=>0); $content = $blog->renderPosts($page, false, $options) . $blog->postAuthor() . $renderComments . $blog->renderNextPrevPosts($page); The 'false' is the second argument. The post will be rendered in full since what that says is that $small = false.

http://processwire.com/blog/posts/roadmap-2017/#whats-in-store-for-processwire-in-2017

I'd say go for it! Not only do I wish you success in your endeavour, but I am hopeful that this will also give ProcessWire some good exposure .

$pages->get() will always get you ONE page only. In your case, it gets you the first child of $store, i.e. Page A. This is because Page A, via sorting, comes first (i.e. before Page B and Page C. $pages->get() returns a Page. If you did a $pages->find(), this will always return several pages (if it found them, of course). The important thing, as noted earlier, is that $pages->find() returns a PageArray. That means, several Page Objects. So, you cannot directly echo like so: $results = $pages->find('template=basic-page'); // cannot do this; it doesn't make sense since you have multiple items inside $results //...so, you would need to loop through it using a foreach echo $results->title; Think of it this way: // FRUIT: this is very specific. You are requesting a banana; not an orange, not an apple, but a banana. //...We will get you a banana $fruit = $pages->get('banana');// @note: pseudo code! // hence, you can do echo $fruit->title;// outputs 'banana' // BUT....if you want FRUITS...there are several fruits... $fruits = $pages->find('fruits');// @note: pseudo code! // if you did this, the question would be, what fruit was that again? // direct 'echo' doesn't make sense; // ...you need to tell us what fruit you want; apple? orange? banana? There's several fruit in here! echo $fruits->title; // aaah, so, we loop through the basket, one fruit at a time... foreach($fruits as $fruit) echo $fruit->title;// this will output each fruit in here in turn...apple; orange, banana, etc... Hope this makes sense.

Update: Menu Builder Version 0.1.7. Changelog Fixed a bug that caused titles of menu items with apostrophes not to display properly in menu settings. Thanks @LMD Code cleanup and refactoring.

In the frontend, have you checked to see how many pages are being retrieved? Something like this: $prevEvents = $player->child("name='history'")->children("date>=$prevDate"); echo $prevEvents->count();// does this output the number of pages you are expecting? In addition, any repeaters in the fields you are retrieving?

Seems you've been away for a while . That's what the file compiler is for. It allows version 2.x modules to run in version 3.x.

Good point.

What about an autoload module that will make the changes on save? This way, it's done once. Or maybe JavaScript to make changes client-side on click' insert-link'? Hmm, maybe not be as elegant though. Just some rumblings....

I see what you mean. Meanwhile, maybe there are workarounds to accomplish what you are after. I have nothing concrete atm .

How is that different from selecting a checkbox, one each for btn, btn-success and btn-sm? Works for me just fine. <a href="/blog/" class="btn btn-success btn-sm"></a>

@MaryMatlow, Seems you missed the third link in my post above . The array indices were changed to 'post_image_tag' => 'whatever', etc..Please see the whole list there or within the module code itself

Yeah, that's a lot of post . Let's see if we can take it bit by bit. I believe this line will grab ALL the children (a PageArray) of history from the database, then return the first (in-memory manipulation) of these retrieved results: $lastEvent = $player->child("name=history")->children("sort=-date")->first(); Instead, try this, to actually grab ONLY one child from the database: $lastEvent = $player->child('name=history')->child('sort=-date'); This line doesn't make sense to me: $prevEvents = $player->child("name='history'")->children("date>=$prevDate"); How can previous events' date be greater than the previous date?

In a hurry, so a quick (and not thoroughly tested) part answer Actually, the 'normal' selector is an AND not an OR (i.e. the comma separated selector). 2a. Both terms in at least one field (@see docs) // both terms in at least one field $sel1 = '(title%=foo, title%=bar), (body%=foo, body%=bar)'; 2b. At least one term in at least one field (@see docs) // at least one term in at least one field $sel2 = 'title|body%=foo|bar'; 3 LIKE (@see docs). Here we use %. See the notes in the docs about the alternative + matching order, etc

Seems like a CKEditor quirk. Rather than going to the source code, you can highlight the heading and change it to 'normal' before deleting it. Not ideal, I know...

Excellent work as usual! Question; when the rectangle shifts to the right, the e sits right above the browser's scrollbar (see attachment). Is that intentional?

Aah, link?