poljpocket

@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?

@ryan I am very curious about the decision to limit deletions for non-admins to single pages. It would be great, if you elaborated a bit about the reasoning behind this. Thank you! My sites mostly use the page tree for page section content aswell and in this situation, it is completely reasonable to assume a "normal editor" to be able to delete a page and it's children/sections/contents in one step. Maybe we could work on introducing configurability for this. Thanks for considering!

I can definitely reproduce this. The exact reason for it can be found here ProcessPageListActions.php @ line 221. The ability to trash a branch of pages as non-superuser is specifically not allowed. Why that is, probably only @ryan can shed some light into. This would also explain why "Edit" > "Delete" tab does not have the same restriction. The commit introducing this functionality from 2018 can be found here.

Is this also true if you try to delete the page in question with "Edit# >> "Delete" tab?

The code injects any files uploaded to the page into the field with name files. You go edit the page in question and paste this into the tracy debugger console. Be aware that you need to change any $page->files to match your field name e.g. $page->my_field_name Also, this only works correctly if there is only one Images / Fields field present in the template (if there are multiple, the field would just contain all the files ever uploaded to the page in question).

I would advise you to install TracyDebugger on a staging copy of the site, set it to forced development mode and have a look if there are any errors when submitting the login form. Or if that is too much effort, have a look at the access/error logs of your server. For anything else, you probably need to provide more context.

Any chance your .htaccess for PW is non-standard?

Well this should be easily solvable by injecting some simple CSS based on e.g. the role of the current user. div#pw-mastheads, footer#pw-footer { display: none; } You can hook into ProcessProfile's execute method, check the user's role and add your CSS file with wire()->config->styles->add('...');

Then you could restrict access to the "Pages" page by using the example provided by @Wanze here. In much the same way, you could hook Page::editable to only allow pages be edited which belong to the user. Further the link provided in your email would then be like https://youdomain.com/adminurl/page/edit/?id=pageId Like that your quasi-guests are locked out of seemingly the whole backend. Another possibility is to add all the fields to their user profile and add only profile-edit capability. This will show an empty backend with a "edit profile" button. And the url in the email then needs to be https://youdomain.com/adminurl/profile

OP wants to use InputfieldImage in the frontend with all the bells and whistles to interactively edit a FieldtypeImage field. Problem is, all the infrastructure provided by ProcessWire assumes a login session.

Indeed, it assumes you have a $loader as in FileSystemLoader or similar. Anyway, you must use a hook so that your code works. From the docs of the Module you are using, you can find this: wire()->addHookAfter('TemplateEngineTwig::initTwig', function (HookEvent $event) { /** @var \Twig_Environment $twig */ $twig = $event->arguments('twig'); // add your extensions to $twig here }); You should add this to ready.php. Here you have the $twig variable which is exactly what you want according to the snippet provided by @Jan Romero. Sadly, this seems to use Twig version V1 or V2 whereas Jan's example uses V3. Twig V1 and V2 don't use namespaces whereas Twig V3 does. A quick composer.json scan shows me, TwigTemplateEngine still uses Twig V1.

Well in this case, ProcessWire won't give you an out-of-the-box solution. Other things coming to mind are PageFrontEdit (bundled with PW) but this also only works with an active login session. You would need to use a frontend component to handle the user interaction and also handle the backend on your own. Nonetheless, you are opening almost direct edit capability to anyone but must reimplement everything the PW backend would offer you for free. Also note that "not knowing a direct edit link" doesn't infer security or authentication. You are still adding backend edit capabilities to the frontend without any form of access control. The sheer existence of such a function is a big security hole. And on top of all this, file uploads. I strongly advise against this!

I completely agree with @dragan. The response from your developer doesn't make any sense. Assuming the request actually works correctly, you can use WireHttp which is part of the PW core and has a much nicer interface (and in the end, is a wrapper for curl).

Let me start with this: No matter what your goal is, allowing unmoderated edit access to your page is never a good idea! With guests, do you really mean not-logged-in users? Assuming you mean "specific people with a login", why not let them use the backend and all of the tools available there to accomplish this task? You can introduce a new Role and limit that to just being able to edit whatever pages you need them to. With this approach, you do not have to be concerned about validating and sanitizing your form which in turn is another possible weak spot in itself. If not, there is the PRO Module "FormBuilder" which might come in handy in your case. It particularly lets you create pages from form submissions (even unmoderated). With it's hookable interface, you can add whatever functionality you need.