poljpocket

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?

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