LostKobrakai

If you need this to work without get variables you need to build a own way to store the $q vars between pageloads. The simplest way, that does not involve javascript stuff to happen, is storing the variable in the session of the user. From there you can retrieve it as needed before doing your pages search. Edit: Now I know again, why I never used whitelist for that job

I think your problem is that you mix up search and pagination. The pagination always needs to be called on the exact same pagearray. In your case this means that you need to have the exact same pages retrieved by your selector for each paginated page. Therefore you need to have some way of storing either $q or the generated selector for the next paginated pages to make the pagination work. That's what the whitelist teppo mentioned does for you.

Actually Page::find does just add "has_parent=$id, " to the selector and then call Pages::find, so no need to do this manually. @heldercervantes What's the $q you check for in the if statement? Do you retain that query to the next paginated pages?

As the number of posts grow it may become more efficient to just check each user for potential posts instead of loading all posts to memory and reading their createdUser field.

It won't work because you're calling different methods even though they look the same. $pages->find() is calling Pages::find, while $posts->find() is calling PageArray::find. These are different in that the second one doesn't give you pagination values. You would need to set them by yourself, but it's not done automatically because having a PageArray suggests, that all pages are already loaded from the database.

There are quite dedicated options in each pagetable field about how created pages should be handled in cases where they would become orphans. You should really use them to clean up. For how to find those unused pages afterwards take a look at this https://processwire.com/talk/topic/9730-get-pages-used-by-a-pagefield/ or the hooks in FieldtypePageTable.module. B. 1. Nope. At least there's nothing in the core to do that. B. 2. It shouldn't matter to much which option you use. The mess will always be the same if unused pagetables are preserved.

Than yes you're limited to this ooperator. I'd suggest using FieldtypeOptions or pages, which are the more powerful options.

Depends on how which Select you're using. The 3rd party module FieldtypeSelect or FieldtypeOptions or by pages?

To circumvent the operator issue use or groups. $selector = "(ref|title|type|version%=$q), (state=$q)" https://processwire.com/api/selectors/#or-groups Edit: To search for each word independent you need to define it that way: $qs = explode(" ", $q); $fields = explode("|", "ref|title|type|version|state"); foreach($fields as $f){ $group = array(); foreach($qs as $q){ $group[] = "$f%=$q"; } $selector .= ", (".implode(", ", $group).")"; } resulting in (ref%=this, ref%=that), (title%=this, title%=that), …

You can even sort by multiple values like this "template=posts, sort=-date, sort=title".

Today I can finally share a project with you, that started about two years ago. Together with a colleague (the daughter of the client) I did the concept and design and a click-dummy for a course of my studies. Half a year later after finishing my studies we then did some clean-up and I programmed it in ProcessWire. And now nearly a year later all the content—texts, photos and a lots of tech. information—is ready, too, so it can soft-launch on monday. http://korona-licht.de/ The client is a small local company selling mostly LED lighting. They've a handful of quite flexible systems to build on, which can be adapted to a lot of use cases, as well as the ability to custom build things if needed. While they're not a very big company their portfolio has lot's of great national and even some international projects to offer. It was a really nice experience working with them and I'm really happy that even things like well written texts have finally found it's way into the website. Others may have just published it halfway through the project.

Theoretically it could be the case that the last update (by page-view) is a minute before your publish time. Now with the LazyCron hook set to [Every Hour] the earliest time of publishing would be 59 minutes late, while the latest time is anytime the next page-view comes in. This could even be many hours later on an infrequently used page. Lowering the interval only shortens the first variable, not the second one. There's no 100% guarantee the cron will run in any maximum timeframe. Lowering the interval will not result in any more "overhead" as the file with the timestamps will be updated for any interval on each page-view. Each interval is updated independently from each other. It just updates if it's (over)due.

That won't work with LazyCron, see below. Both. Exactly. LazyCron does not care about which function you hook to it. On every pageview it reads a file, which holds a timestamp for each available interval you can chose. If the timestamp is older than the interval it updates the timestamp and executes the functions for that interval. So if the timestamp for "1 hour" is older than one hour it will run the function, no matter of which time it is. Therefore it's dependent on when pages are viewed and therefore also changes each time the update happens later than an hour after the last update. Not if you don't need it. You specify the timezone that ProcessWire uses throughout the whole system in the config.php in the site folder.

First of all, the screenshot is showing CKEditor and not TinyMCE. You can set custom options for it in the field's settings. Here you'll find how the options look like: http://stackoverflow.com/questions/12464395/how-do-i-programatically-set-default-table-properties-for-ckeditor

There's even this for the multi-language one: $user->language->isDefault() // true or false

Made a small update so that InputfieldChosenSelectMultiple now respects the "Allow pages to be added" setting. Without it one cannot add tags anymore.

The culpit is not the new Options fieldtype, but repeaters not being officially supported.

You need to be aware, that assets need to be synced, or images will show up as unavailable in the installation they weren't added to. Also CroppableImage does make the chosen imagefield unusable on your production site as the used fieldtype is saved in the database. I don't know if it will throw any errors as long as you do not access this field, but it certainly will if you try to access it on the production site.

https://processwire.com/talk/topic/4383-how-to-set-language-active-via-api/

Have a look at this: https://github.com/ryancramerdesign/ProcessWire/pull/1128

I'm moving my mouse in a circle over the image list on the homepage (at medium speed, not like crazy) and then the hover effect is displayed on images I hit before the actually hovered one. It seems like it's lagging behind.

Looks really nice. One thing I noticed. When I circle over the projects with the mouse the hover effect falls behind, which leads to a quite unresponsive feeling. Also dat ascii art (I think you know what I mean )

Seems like you're still getting an array of images, even though it should just return the single image with this field settings. Try using "$user->userimage->first()" or using Format = single for a temp. fix. Additionally I think you need to use "$img->url" in the echo line. The field not returning a Pageimage, but Pageimages seems to be a bug. It would be nice if you could report this on Github. "Method Pageimages::size" The error says enough.

Strange thing is, that this error is thrown at a path, that shouldn't be available (…/v2/wire/core/ProcessWire.php). A quick look at the index.php shows, that this file is included by those two lines: $rootPath = dirname(__FILE__); … require("$rootPath/$coreDir/ProcessWire.php"); //$coreDir is just the wire/core part I don't see, where this could lead to the above path without dirname() having hickups.