LostKobrakai

Maybe renaming the field to another name would solve the autofill issue as Firefox would only autofill e.g. "pass" and not "pass-change". At least it would ask if it should save the password, before autofilling it. Edit: Scrap that. The login does already use a different name.

@joey Can you tell us which page field didn't work and how it's set up?

It will be more flexible when using pages, but you can make it work with simple fields as well. I suggest reading this topic to get more insight: https://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/

Have a look at this topic: https://processwire.com/talk/topic/10886-passwords-do-not-match-message/ Basically it's supposed to work like you wish.

https://processwire.com/blog/posts/processwire-core-updates-2.6.1-and-more/#process-modules-now-support-external-view-files

That looks like a filesystem error. Sure the running webserver does have permission to read those directories?

Which sadly does compare to how we got to today's situation. It began with advertisers, which wanted to identify click bots and in the process our privacy got wrecked. @teppo That's also in the article But it's long I've read it in two times.

Try resaving the page (at best with changes to the current state). This should reset the cache.

That would certainly boost the publicity of ProcessWire by a great bit.

If ProCache is still stripping out the head I would consider that a bug. An element with attribute should never be stripped, if it's content is not the default content (e.g. <input type="text"> == <input>).

Do you use any server-side caching. ProcessWire does have multiple of those, but the only one that may be switched on by accident is the template cache. You can check this in the settings of each template.

Even objectively is the (current) community of processwire neither smaller nor larger just by the number of contributors that's shown at GitHub. It may not attract new people as much and it may downturn people who are – instead of taking a look at the cms itself – looking at the raw numbers, but so be it. It's Ryan's decision to not use the pull-request feature, which would increase this number a bit. The focal point of this community is either way this forum and the people here.

I can certainly see that that's a pain for advertising and everyone who's benefiting from it, but I see it like this article states it (in longer form: http://idlewords.com/talks/what_happens_next_will_amaze_you.htm). Advertising has turned their own industry to somethings really weird, that's just invading privacy to an extend which is just not bearable. Also in traditional media the one printing the advertising had to pay for the space/paper/ink, now it's the other way around and you could still "block" it with an "no advertising" label at your mailbox. If advertisers want to continue to be seen then they have to deliver something worth seeing. It's as easy as that.

There's currently only pageTableExtended, while essentially the answer is pagefields, the UI pov is the crippling point for such an workflow.

You could in theory set sublime text up in a way that it does highlight html in quotes.

Very nice indeed. A website, once in a while, where the one page design actually makes sense. Only small issue I just noticed. The active indicator in the menu doesn't jump to "contact" for me even if I scroll to the very bottom, but it's an iMac with 1440px display height. That may be the reason.

Delayed output is just another way to generate the full html markup, that is send to the browser. The browser won't get anything different, therefore everything js/css is unaffected of this.

If you mean by "in a template" "via the api" then it's this: $page->of(false); $page->image->tags = "Tag One Two Three" $page->save(); // If you want to persist changes Tags are stored as simple string, nothing more.

No. $content (as it's named in my example) will ever only be a string of markup. You'd build _main.php once and everything else happens in the template.php. You just part for part add markup to $content and in the end _main.php will just spit everything out what is in that variable.

Repeaters may seems like a good fit if you're new to pw, but they aren't. Use pages and create a page for each file. This way you've the full freedom of choice about which data is associated to a file and which access roles you need. For categorization and/or frontend-display use pagefields. I also suggest you to read this topic before beginning: https://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/

But keep in mind that this will only solve the issue of people hitting refresh after an successful submission (and redirect). I doesn't help if someone is hitting refresh while submitting the form, which will still send two requests.

CSRF is not there to protect your users from multiple submissions. It's there to ensure that the data send are from the exact user you send the form to, nothing more. If you additionally want to prevent multiple submissions, than use $session->CSRF->resetToken(); on successful submissions. But this would prevent other forms, that the users may already have requested on e.g. another tab, from working. There are other ways to prevent duplicate form submissions, like using redirects. E.g. one way with redirects would be: /my-page-with-form/ -> submits to "submit/" /my-page-with-form/submit/ -> on success redirect back, on error save submitted data, too, to repopulate form …, but you could also simply redirect to the same page in your current code just after $mail->send();

The delayed output is not much different from not using it. Instead of just echoing out content immediatelly (no matter if at once or in _header.php -> template.php -> footer.php <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Document</title> </head> <body> <h1><?php echo $page->title; ?></h1> </body> </html> you're going to construct the "content" of the page before any html is outputted. // _init.php $content = ""; // template.php $content .= "<h1>$page->title</h1>"; // _main.php <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Document</title> </head> <body> <?php echo $content; ?> </body> </html> The difference it that you're temp. storing the content (or whatever types you use/need) is stored in a variable until it's echod. The main benefits are that it does allow for later alteration of markup and sometimes cleaner code. Essentially just don't use echo in your template files, but only with the placeholder variables in _main.php and you've delayed output.

I haven't used it by myself, but I though I've seen it in a few laracast videos, as it seems like I falsely mixed this (https://github.com/fzaninotto/Faker) up with faker.js, which I already knew at that time.

The faker api is also really nice to generate dummy data. See the "hosted microservice" section in the readme: https://github.com/marak/faker.js