poljpocket

Hey. Interesting topic. First, and not to lecture you, Pages::find doesn't have a getFromCache parameter. The find method decides to fetch from cache based on what is queried. I did a little further digging and code reading. What I can come up with is that the cache gets invalidated every time a save is performed on the page itself or on it's parent. Move operations are handled by the ProcessPageSort module (part of core) and before the sorted hook is called, the functions in this module save the page and after, it's parent. Save operations seem to invalidate the cache from the page down across its children. This makes sense as the database doesn't necessarily hold the same data as the cached versions. To illustrate this, I have the following hooks with child ID 1017 and parent ID 1015 and performing the same move operation as in your example: <?php $wire->addHook(['Pages::saveReady(1017)', 'Pages::save(1017)', 'Pages::sorted(1017)'], function (HookEvent $event) { $eventPage = $event->arguments(0); $wire = $event->wire; $pages = $wire->pages; be($event->method . ' - ' . $event->when); $findPage = $pages->find(1017)[0]; $getPage = $pages->get(1017); be('$eventPage ' . spl_object_id($eventPage)); be('$findPage ' . spl_object_id($findPage)); be('$getPage ' . spl_object_id($getPage)); }, ['before' => true, 'after' => true]); $wire->addHook(['Pages::save(1015)'], function (HookEvent $event) { $wire = $event->wire; $pages = $wire->pages; be('parent' . ' / ' . $event->method . ' - ' . $event->when); $findPage = $pages->find(1017)[0]; $getPage = $pages->get(1017); be('$findPage ' . spl_object_id($findPage)); be('$getPage ' . spl_object_id($getPage)); }, ['before' => true, 'after' => true]); This gives me the following event log (the number is the object instance id): save - before $eventPage 243 $findPage 243 $getPage 243 saveReady - before $eventPage 243 $findPage 243 $getPage 243 saveReady - after $eventPage 243 $findPage 243 $getPage 243 save - after $eventPage 243 $findPage 187 $getPage 187 parent / save - before $findPage 187 $getPage 187 parent / save - after $findPage 196 $getPage 196 sorted - before $eventPage 243 $findPage 196 $getPage 196 sorted - after $eventPage 243 $findPage 196 $getPage 196 You can see that after "save - after", the find call loads a new version into cache. The instance IDs change a second time after "parent / save - after" which must be doing the same. In between these, the IDs stay the same. This should explain why you do not get your situation on saveReady, but then afterwards in sorted, you do get it since the sort functions save the pages in question before calling the hook.

Also, your cache function only works as expected if the $nameid variable is the same every time you use a cached version of the query. To get around this, you should make the cache key depend on it, e.g.: $name = $cache->get("cachedname-$nameid", "+2 minutes", function($pages) use($nameid) { return $pages->find("template=names, parent=1195, id=$nameid, status=published, limit=3"); });

I would assume the $nameid variable is not available in your closure unless you add use ($nameid) to include it. $pages is available only because WireCache supports optionally passing API variables as arguments. This should work: $name = $cache->get('cachedname', "+2 minutes", function($pages) use($nameid) { return $pages->find("template=names, parent=1195, id=$nameid, status=published, limit=3"); }); Here is some documentation about closures: PHP: Anonymous functions - Manual

You can use my composition as a starting point. It has a configurable ProcessWire version (must be a tagged one on GitHub) and supports DB dumps for complete version control. Be advised this is intended for local development and NOT for production! You should be able to add SSL and some more hardening to make it production-ready though (for sure remove the phpmyadmin container!). poljpocket/processwire-docker: Docker installation of ProcessWire for local development (github.com)

I would try to revert to a backup as close as possible to the last successful changes and see if the issue persists.

You souldn't abuse the unpublished state for that. A very watertight solution is to make use of Patreon's OAuth to make sure the page viewer is actually one of your supporters. This also eliminates the problem that any link out there which relies on "not being known to the public" doesn't add any form of security or "privateness". Imagine one of your Patreons sharing the direct link to his friends. EDIT: This would be a real candidate for a module ?

I think that the new TinyMCE field offers you exactly what you need. You can configure the toolbar to only contain the controls you want. You can completely redefine the styles menu available and you can configure tags to be removed. Have a look at @ryan's post here.

Interesting topic. Assuming you have enabled the override for "Details: fields in fieldset", the warning you are talking about applies to your case. It simply means that any fields not rendered bold in the Overrides list are untested and may cause problems when using an override on them. It doesn't say it wouldn't work, though. It says you must test whatever you enable. Now, I don't get how you achieved Overrides outside the template context. As far as I know, this isn't possible and from a frontend point of view also doesn't make any sense. You can easily create multiple templates (and their respective template files) which only differ in Overrides for a specific field. There is simply no need to have Overrides on a per-page basis. Can you clarify on that last part?

Exactly, I was going to suggest something like that. But be aware of any side effects this might have because this will act on ANY page added and renders the checkmarks on the "Add New Page" screen useless. You might want the hook to be a bit more specific e.g. $wire->addHookAfter('Pages::added(0:template=_YOUR_TAGS_TEMPLATE_NAME_)', ... or also $wire->addHookAfter('Pages::added', function($event) { $page = $event->arguments(0); if ($page->template->name !== '_YOUR_TAGS_TEMPLATE_NAME_') return; foreach ($this->wire->languages as $lang) $page->set("status$lang", 1); $page->save(); }); Still, the better solution would be to eliminate this inconsistency in core / core modules. EDIT: You should only do this for non-default languages, e.g. with $languages->findNonDefault(): $wire->addHookAfter('Pages::added(...)', function($event) { ... foreach ($languages->findNonDefault() as $lang) $page->set("status$lang", 1); ... });

Sorry for the late reply! Can you post some more context about how exactly you are accessing / rendering the output with Twig? Why am I asking this: Your first line with render(title) does probably not use any Twig output and thus works as intended. Your second render line does use Twig! I have found, there are some problems with Twig's way of looking for methods' and properties' existence using PHP's reflection API. And this is not always very compatible with the way PW is able to "invent methods" or "add properties" using hooks. Especially stuff like Pageimages::first methods don't behave as they would in plain PHP. In your case, there might be a problem with hooks not being executed when Twig is accessing your data. But this is just an idea. You can try to debug this by adding something like var_dump($page->title) in your template outside of any Twig output. Then, check if the title is properly rendered in multiple languages but the Twig's content is not. If not, the problem lures somewhere else.

Since this is the second time I see this "issue" arise, I have posted a new issue in the PW-issues repo: https://github.com/processwire/processwire-issues/issues/1826

Yes I know. You should see the Ekonomi and Finans pages somewhere in the page tree. Depends on how you configured your field. Go to find Ekonomi and edit it via the tree. There you will find the Settings tab and checkbox as described. Is it checked?

Hi, I believe, I have run into some similar issue. I am creating new pages using the API, something like that: $newPage = $pages->newPage([ 'template' => '...', ... ]); $newPage->set(...); ... $newPage->addStatus(Page::statusUnpublished); foreach($languages->findNonDefault() as $language) $newPage->set("status$language", Page::statusOn); $newPage->save(); If it wasn't for the foreach-loop, the new page is only active in the default language. You can find the checkbox @ngrmm is talking about here: Page edit screen >> Settings >> Name There, the page name is displayed for each language and at the end of the non-default ones, you find said checkbox. This is exactly what my foreach-loop is "checking". Maybe there is an oversight in the Language Support module @ryan? Creating the very same pages in the admin enables the languages by default! Shouldn't the API do the same? @Flashmaster82 is the checkbox marked for you? If not, you might have run into the same "bug" I have...

@da² for me, this isn't the case... For transparency, that is how I quickly put together a test file bootstrapping PW: use ProcessWire\Languages; use ProcessWire\Pages; include 'index.php'; /** * @var Pages $pages * @var Languages $languages */ $page = $pages->get(1); $languages->setLanguage('english'); echo $page->render(); This renders the homepage of my install perfectly using english as the language. Maybe you post yours? Also, please attach which LanguageSupport modules you actually have installed. Is multilingual support maybe disabled on a per-template basis? What is the output strategy set for non-existent translations (in Modules > Configure > LanguageSupportPageNames)?

Two ideas, both untested: Could you try resetting the language between calls? More info here (Languages::setLanguage). Make sure this happens even if you supply the same language twice. This would assume there is a problem related to the render call and not the languages.

Most of our sites are running InnoDB with 10.5.19-MariaDB-0+deb11u2 or later and so far, absolutely no issues.

In ProcessWire's frontend, you can do whatever you want. There is absolutely nothing stopping you from using vuetify. To better understand how PW handles it's frontend output, you can start by looking through the Getting Started section of the official docs found here: https://processwire.com/docs/start/ Specifically the section about template files would be where you will find what you are looking for: https://processwire.com/docs/start/templates/

Well.. that might be something, yes! In the end, Repeater Matrix is just an extended form of a Repeater (RepeaterMatrix literally extends Repeater in PHP) and thus might inherit such behaviours too.

Okay, please check the setting of the page's template you can find under "Access", then "Prevent direct access to file assets owned by pages using this template?". Did you configure something there?

Have you compared the URL of the images in the superuser / non-superuser cases?

Right now, this pack should be in line with PW's 3.0.210 release and I will update it to .227 in the next few days.

Hi everyone, At my agency, we usually speak in a non-formal way ("per Du") which led me to create this deviated version of @dotnetic's German language pack for Swiss German which uses non-formal language and doesn't use ß (we use ss). The module can be downloaded here: https://processwire.com/modules/swissgerman The source can be found here: https://github.com/poljpocket/processwire-languagepack-dech Changes & suggestions are very welcome. You can post here to inform me of any mistakes or make a PR on GitHub. Thanks already for helping out ? Big thanks to @dotnetic for letting me use his language pack as a starting point. Big thanks to @Nico Knoll and @yellowled for their initial work on the translations before @dotnetic took over.

You can start off by following this guide here: Get Started - Conversions API (facebook.com) There is no ready-made code samples but fear not, it isn't as complicated and also doesn't force you to code anything. You install a so-called "pixel" and let Facebook do the rest (meaning: you configure the FB stuff just as you would do with e.g. Google Analytics). Once you have created such a pixel following the guide above, you are also guided through installation and testing. There are more complicated ways allowing for more fine-grained conversion control, but for 99% of the cases, the pixel is enough. Important: be very aware of GDPR if you are in the EU! Edit: Since you aren't, just be very aware of your local privacy laws!

Since search is usually done using GET, no. You are not actively POSTing something which has side effects and thus CSRF is not feasible / applicable.

PW has quite strict session spoofing protection enabled by default. It is called a session fingerprint. Take a look at the session fingerprint settings here. I would start by trying to relax this setting and try to log in again. I have encountered problems with the fingerprint when using proxies and multiple-forwarding as it is usually the case in a cloud environment. EDIT: Yes, in AWS environments, the SSL is usually done on the proxy and then internally, only HTTP is used. But I am pretty sure this is handled correctly (host rewriting and such) in order for PW to function correctly. What is your "HTTP hosts whitelist" configuration?