Can

Thanks for your input Robin, Because actually it's even more about having one article always at second position (like a banner) I just prepended this one and reorder via css for now. more advanced sorting would still be great though

Hola amigos, I'm a little stuck on this one and I couldn't find any solution so far, which might be my fault but who knows^^ I got a blog with articles having a page field called "props" which lists (checkboxes) my hidden /processwire/page-properties/ tree containing properties like e.g. featured and gallery Now I want to get all those article pages all sorted -published so descending but featured articles first before I only used the featured property so sort=-props.name worked but now I'm using gallery prop too but I don't want them to be upfront, too $normal = $page->children("props!=[name=featured], images.count>0, sort=$sort, limit=$limit"); $articles = $normal->prepend($page->children("props=[name=featured], images.count>0, sort=$sort")); I also tried featured first then appending "normal" articles, my problem I'm not really able to limit the end result with pagination the above snippet works but limit is not as expected, I also tried the above without any limit and then doing $articles->find("limit=$limi"); which worked but without showing the pagination.. I know could simplify by using a checkbox inputfield called featured, but I really think it should work using page reference field as it's cleaner in the backend, but maybe I should just do this anyway?! would be nice to have selectors to be able to sort=[props.name=featured] than sort=-date or am I missing something here? saludos Can

Just a little update because of new API additions, so now you could just do foreach ($pag as $p) { foreach ($languages->find('name!=default') as $lang) { $p->setAndSave("status$lang", 1); } } Thanks @szabesz for mentioning I'm adding this here for completeness

By the way, I don't remember which version introduced this, but you can use $field->getLabel() instead http://processwire.com/api/ref/field/get-label/

maybe

I use piwik for a while now and love the extended statistics.. But you should be able to place a hidden image on the procached page which requests an uncached page of your installation which counts the hits that's whats piwik is doing in an <noscript> block for js disabled browsers e.g. <img class="hidden" src="/counter.php"> or <img class="hidden" src="/pathOfUncachedPage">

what do you mean by directly? It's taking the requested url and checking if there is a index.html within the same path as the url I'm not the rewrite pro, more trial and error style My rewrite checks if the file exists, if not it won't rewrite and I'm having the "-f" flag appended to make sure there is an actual file in that path

Maybe findMany could be of interest? https://processwire.com/blog/posts/find-and-iterate-many-pages-at-once/#the-new-pages-gt-findmany-method

Just let us know if you got another question

It's definitely one possible way to go, sure. the url names are received from the db or you define them in the template? If the first is the case make sure to sanitize them e.g. $sanitizer->pageName($url)

As far as I remember this is not yet possible as there is no "reverse" selector. This is discussed somewhere in the forums.. Think your way is the easiest. You could cache it using wirecache for example.. https://processwire.com/talk/topic/10548-my-way-of-using-wirecache-and-some-hints-to-make-life-easier-with-it/ Another possibility would be to store the needed information (number of articles) in a field e.g. "article_count", so every time an author writes an article you increment or decrement if an article gets deleted.. if authors use pw backend you would hook after Page::save (or maybe Page::saveReady) and update the value accordingly, like this you could hook into trashing or unpublishing etc of pages. but maybe you got some front end form where authors post their content then you could just add something like $user->setAndSave('article_count', $user->article_count+1) (there might be a shorter syntax but I can't test right now..) after your existing article save logic..

conventions sure..but we're talking about coolness

For everyone interested in disabling cookies at all to avoid every possible need for this plugin checkout out this blog post from Ryan http://processwire.com/blog/posts/multi-instance-pw3/#more-session-control

Finally! http://processwire.com/blog/posts/multi-instance-pw3/ Working just as described for me =) (site note: I've both installs running on 3.0.30)

Now it's officially documented and at least for me it works using PW 3.0.30 (I have both installs running 3.0.30) http://processwire.com/blog/posts/multi-instance-pw3/

Why hasn't this renaming already been made?

I would say JSON is a good solution if Alamofire likes or requires it..."just" use the format most convenient for your app or the framework..pw doesn't care I don't know why you wouldn't get any output, just tested your code and I'm using something similar for sitemap.xml as suggested by Ryan Nowadays (don't remember which version introduced this feature) you don't need to set the header in your template yourself you could set the template in the backend to json what pw version are you running and how does your template setup look like? do you have a pre- and appended template file (think this is called delayed output)? But probably not if it's just you app backend and not a "normal" website.. And what do you get when you request this page from your browser?

@tpr https://github.com/CanRau/MarkupCookieConsent/commit/3f7b71a659759693ae5dcdeb7436887a5a2c97f4

@tpr sure would work, too. Maybe faster? Otherwise shouldn't matter?!

good catch @flydev never considered this as most of my projects are multi lang tested and pushed your fix, should work now @csaeum Please let me now if it works for you, too EDIT: Just bumped version so you should be able to just update the module using ProcessWireUpgrade module (if installed)

What a pitty, just found this http://meta.stackoverflow.com/a/329022/3484824 and PW got 16 questions so far :/

You mean $this->config in LinkCrawler.php? Would say it looks quite good, I put a var_dump($this->config) on line 151 (right after $this->config has been populated) and I'm getting this in the error message after clicking on check now on /processwire/setup/link-checker/ Don't now what you mean? Here /processwire/module/edit?name=ProcessLinkChecker right? don't know what I have to look for?! No but for the tests I exit; right afterwards and those lines are the very first lines right after opening php and bootstrapping pw.. Thanks for your workaround @arjen think I'll give it a try soon

Internet too slow to answer fast^^ Also check out processwire.com/api/ref

Maybe this helps # # check if file in /essays/ folder RewriteCond %{DOCUMENT_ROOT}/essays/$1/index.html -f # # serve static html version RewriteRule ^(.*) %{DOCUMENT_ROOT}/essays/$1/index.html [L,QSA] You probably need to adjust it a little, uh this expects your essays folder at your domain root (which seems to be from your main post?) Let me know if you get it working

Wow finally I can answer internet is quite slow at the moment and the new PW forums seem to be a little hungrier or dependent to load fully for the reply form to work/load so I can read but answering is a hard task for me..and here's now link anymore pointing to a stand alone reply form (which could maybe be more lightweight, I don't know..) anyway..now it works So as @kixe requested the policy link text is now translatable, too. I'm not sure but I think till now the translations weren't reflected in the cookie notification at all, or maybe I confused myself and missed something don't know.. Anyway now it works (at least for me). Don't know if this is the proper way of coding this and I'm open to suggestions, maybe there's a PW way in doing this? And as I'm a little more gitty now (working more with git, just found out what gitty actually means haha^^) I included a devns branch now..maybe it's a little confusing? (just now came the idea to call the branch namespaced or something) as it's not the development version of MarkupCookieConsent but the namespaced version meant to be used with PW 3.x devns. So the only difference is added namespace in the module and the config file and module info now reflects the need for PW >= 3 to install the devns branch