poljpocket

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.