Leaderboard

$news = $pages->find("template=news-article,sort=-publish_date, publish_date<$today,id!={$page->id}"); PS: if publish_date is a datetime field, then ProcessWire already knows 'today' (string) ?.

Cacheable Placeholders This module allows you to have pieces of dynamic content inside cached output. This aims to solve the common problem of having a mostly cacheable site, but with pieces of dynamic output here and there. Consider this simple example, where you want to output a custom greeting to the current user: <h1>Good morning, <?= ucfirst($user->name) ?></h1> This snippet means you can't use the template cache (at least for logged-in users), because each user has a different name. Even if 99% of your output is static, you can only cache the pieces that you know won't include this personal greeting. A more common example would be CSRF tokens for HTML forms - those need to be unique by definition, so you can't cache the form wholesale. This module solves this problem by introducing cacheable placeholders - small placeholder tokens that get replaced during every request. The replacement is done inside a Page::render hook so it runs during every request, even if the response is served from the template cache. So you can use something like this: <h1>Good morning, {{{greeting}}}</h1> Replacement tokens are defined with a callback function that produces the appropriate output and added to the module through a simple hook: // site/ready.php wire()->addHookAfter('CachePlaceholders::getTokens', function (HookEvent $e) { $tokens = $e->return; $tokens['greeting'] = [ 'callback' => function (array $tokenData) { return ucfirst(wire('user')->name); } ]; $e->return = $tokens; }); Tokens can also include parameters that are parsed and passed to the callback function. There are more fully annotated examples and step-by-step instructions in the README on Github! Features A simple and fast token parser that calls the appropriate callback and runs automatically. Tokens may include multiple named or positional parameters, as well as multi-value parameters. A manual mode that allows you to replace tokens in custom pieces of cached content (useful if you're using the $cache API). Some built-in tokens for common use-cases: CSRF-Tokens, replacing values from superglobals and producing random hexadecimal strings. The token format is completely customizable, all delimiters can be changed to avoid collisions with existing tag parsers or template languages. Links Github Repository & documentation Module directory If you are interested in learning more, the README is very extensive, with more usage examples, code samples and usage instructions!

That's an interesting point. As I understood the GDPR (but I'm not a lawyer, so not sure about that) a listing of the single cookies is not mandatory right now - but the upcoming ePrivacy could change that. When you want/need to implement this solution, KLARO could be a better choice at the moment. Currently this feature isn't included in PrivacyWire and I'm not sure if or when I could implement it. Or you could fork PrivacyWire and add the feature with a PR? ? Best, Joshua

What exactly is the resulting settings or options here with the size call? Have a look at it with: https://processwire.com/api/ref/pageimage/get-debug-info/ // instead of // $img = $image->size($size["width"], $size["height"], $size["settings"]); // call $debuginfo = $pageimage->getDebugInfo($size["settings"], 'string'); // 'string' | 'array' | 'object' // and inspect the $debuginfo with Tracy or a var_dump()

Hey @montero4, First of all, just wanted to say that I really need to figure out some way to handle these conflicts with Hanna Code — it's becoming a common issue. I'll see what I can do about that soon ? Technically there's nothing wrong in your code. It will work just fine on the front-end, where it's really intended to run. The problem is that in order to get useful index out of field content, SearchEngine actually gets it via $page->getFormatted(), which means that TextFormatters (such as Hanna Code) will also run in the admin side. In this case you're using $pages->get() to get another Page, and since the default in the admin is that output formatting is off, this means that this new Page will have output formatting disabled — and that's why $page->image actually returns an instance of Pageimages (instead of a single Pageimage). ... anyway, just wanted to explain what's going on in here ? Right now the easy fix would be checking for the type in the Hanna Code snippet. (Again, I'd like to automatically handle this in SearchEngine, but I can't say for sure when I'll get to that.) $page=$pages->get($id); //gets the page $image = $page->image instanceof Pageimages ? $page->image->eq(0) : $page->image; $image = $image->width(1240, ["suffix" => "srcset"]); //create image that is 1200px wide Alternatively you could make sure that output formatting state is on — it's mostly a matter of taste, really: $page=$pages->get($id); //gets the page $of = $page->of() // store initial output formatting state for later use $page->of(true); // make sure that output formatting is on $image = $page->image->width(1240, ["suffix" => "srcset"]); //create image that is 1200px wide $page->of($of); // restore initial output formatting state

There were lots of core updates this week, very much in the same theme as last week — major long term quality improvements for the core, but no shiny toys to play with… Just lots of good and solid foundational core improvements, and a few fixes too. It's mostly kind of technical stuff that's probably not that interesting to read about, so I'll keep this short, but for those interested here's the commit log. Thanks for reading and have a great weekend!

Hm, that's interesting - I didn't think about that ? I think it's not too late for that change and will make using RockFinder3 easier, so I just committed that change, thx!

Much appreciated, can't tell you how frustrating that was. Yes, I usually use /cms/ for the admin URL. Now I just have to remember this little trick next time it happens. Thanks again ??

Glad I could help someone! Another thing to keep in mind is your admin url. In most cases it is mydomain.com/processwire/, but it can also be customized to something else like mydomain.com/admin/. In that case you will also have to update your Cloudflare page rules.

Thanks for that! I have been stuck on this all morning. It never even occurred to me that it could be CloudFlare causing the issue...ugh. You, sir, are a scholar and a gentleman.

The nifty code: $base = wire('config')->urls; $cssUrl = $base->InputfieldPassword."InputfieldPassword.css"; echo '<link rel="stylesheet" href="'.$cssUrl.'">'; $jsUrls = array(); $jsUrls[] = $base->InputfieldPassword."complexify/jquery.complexify.min.js"; $jsUrls[] = $base->InputfieldPassword."complexify/jquery.complexify.banlist.js"; $jsUrls[] = $base->JqueryCore."xregexp.min.js"; $jsUrls[] = $base->InputfieldPassword."InputfieldPassword.min.js"; foreach ($jsUrls as $jsUrl) { echo "<script src='$jsUrl'></script>"; }

If you are using cloudflare.com you might also want to create a page rule like: *mydomain.com/processwire/* Security Level = High Cache Level = Bypass Disable Apps Disable Performance This should prevent any of the Processwire admin from being proxied by cloudflare.

Ah ha! That makes sense from my end. At the time I was having problems, it was on a server that was using Cloudflare. I had disabled Cloudflare for other reasons (namely their CSS caching drives me bonkers) and that resolved my issues, but I had never made the connection between the two. Thanks for coming back and chiming in with your findings.

Hi, I just wanted to point out that we recently ran into the same issue when using Cloudflare's CDN. Weird is the fact that we were able to reproduce the logout issue with a specific user when editing a specific page. Every time the user clicked "Save" for this specific page, she was kicked out. I assume that at this point the IP address changed - from Cloudflare to the actual user's IP address or the other way around. The error is the same as in the quoted post above: User 'somebody' - Error: Session fingerprint changed (IP address or useragent) (IP: 162.158.XX.XX) The IP address is - just as above - in the Cloudflare range: https://www.cloudflare.com/ips/ We are currently working around this issue by using a different Domain name to access the ProcessWire backend. This domain is not routed through Cloudflare and the approach works fine for us so far. I can provide further information if required.

Besides the hidden admin page approach, you could use a module config page to return the AJAX data. You would need to have an additional module because an inputfield module doesn't autoload. So your module folder consists of: TestAjax.module InputfieldTestAjax.module InputfieldTestAjax.js TestAjax.module <?php class TestAjax extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'TestAjax', 'version' => '1', 'summary' => 'Installs and is used by InputfieldTestAjax.', 'installs' => 'InputfieldTestAjax', 'autoload' => "template=admin", ); } public function init() { $this->config->js('admin_url', $this->config->urls->admin); $this->config->js('module_name', $this->className()); $this->addHookBefore('ProcessModule::executeEdit', $this, 'ajaxResponse'); } public function ajaxResponse($event) { if(!$this->config->ajax || $this->input->get->name !== $this->className()) return; $event->replace = true; $data = '{}'; if($this->input->post->test_ajax) { $test_ajax = $this->input->post->test_ajax; // populate $data } $event->return = $data; } } InputfieldTestAjax.js $(function() { var test_data = { test_ajax: 'my string' }; var url = config.admin_url + 'module/edit?name=' + config.module_name; $.ajax({ url: url, data: test_data, type: 'post', success: function(data) { alert(data); }, error: function(jqXHR, textStatus, errorThrown) { console.log(textStatus, errorThrown); } }); }); InputfieldTestAjax.module ...whatever you need for the inputfield.

By any chance, did you add cloudflare or something like that? I ran into this issue recently. The session logs said "Error: Session fingerprint changed (IP address or useragent) (IP: 108.162.219.219)." That IP address is Cloudflare IP. Then, after searching on this forum, I added sessionFingerPrint = false in config.php. The problem then went away. Good. However, the next day I removed that line to test the login/logout issue. Interestingly, I didn't notice any issue. So -- I don't really understand why the problem didn't reappear after I removed that sessionFingerPrint line.

I have a site where Chrome on Android, with all history removed, on a re-booted phone, will not login and I am seeing User 'admin' - Error: Session fingerprint changed (IP address or useragent) (IP: xxx) in the session log. If I open an incognito window it will login. If I login to Android as a new user (and so virgin chrome) it will login. (the delete all history not fixing it surprised me) I was able to fix this with: $config->sessionFingerprint = 0; in /site/config.php Is it 'safe' to leave this set this way? There's no danger of two users logged in getting their sessions 'mixed up' with this set to 0 is there (i.e this isn't the only thing that keeps the identity of a client to their session 'understood' by PHP/PW is it)? Thanks for pointers and sorry if I missed answers to these points from other threads. Cheers, -Alan

2. Or, add a meta generator tag within your document <head> <meta name="generator" content="ProcessWire"> Mine has ProcessWire 2.6.1 is that ok?

Session fingerprint also keeps track of useragent. So if your useragent or IP is changing, then the session is considered no longer valid. This can help to prevent session hijacking. But it can be a nuisance if your IP and/or useragent are changing for a valid reason. In that case, you should disable session fingerprint from your /site/config.php file. Locate this line and changed it to 'false' as shown below: /** * sessionFingerprint: should login sessions be tied to IP and user agent? * * More secure, but will conflict with dynamic IPs. * */ $config->sessionFingerprint = false;

Mmmmm... donuts.