poljpocket

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

You could actually pass an array which contains all other content like <?php $vars = [ 'items' => $items, 'homepage' => pages(1), 'category' => $category ]; echo $files->render('path/to/file.inc', [ 'vars' => $vars, ]); and then use that to pass on. To still have the convenience of global variables, you can use <?php extract($vars); in the template file to be rendered. My code is untested though!

I am not sure I get your question exactly right, but nonetheless: A given Fieldtype is in itself just a fancy form of a ProcessWire Module and thus, I assume you are talking about the defaults of the form rendered on the Modules > Configure > NameOfYourFieldtype screen, correct? To get a list of any Module's configuration, you can use: wire("modules")->getConfig("YourFieldtypeName") as found in the docs here. Ultimatively, this calls Modules::getConfig() or as of 3.0.219, ModulesConfigs::getConfig() which just reads whatever the database has stored for given WireData (a parent class of Module). This will at least give you the Module's current config (possibly amongst others AND as possibly modified by the user). I know this isn't the solution because there isn't any given default way to set values for a Module. It is really up to the Module's author. Also, not every Module must have a config. I am afraid, there might be no general solution at all.

Do you have the module LanguageSupportPageNames installed (ofc no need to install, it's a core module) and enabled? It is what adds the localUrl method to Page.

@gebeer I have added another commit. I am not proud of that solution, but it works. I have changed the input type to text and added a simple pattern moving most of the validation burden to the server. This circumvents browsers' non-support for RFC6530 and uses the already-working implementation in $sanitizer. This will never ever get added to core like this but at least this way, a custom fieldtype and inputfield could be extracted for your use case. Let me know if that works for you.

I have drafted a new PR for this feature. The backend implementation is simple enough. The description strings for sure need some work. See here: https://github.com/processwire/processwire/pull/259 It turns out, this is more complicated than anticipated because the browser validation fails. In order to test the new feature, I have to change the <input>'s type to text or the browser won't allow sending the form.