Leaderboard

There is already some information on how to do this but it's a bit scattered, so here's a quick tutorial... This is how $session->CSRF->hasValidToken() handles AJAX requests, by getting the token name and value from request headers: if($this->config->ajax && isset($_SERVER["HTTP_X_$tokenName"]) && $_SERVER["HTTP_X_$tokenName"] === $tokenValue) { $valid = true; } else if($this->input->post($tokenName) === $tokenValue) { $valid = true; } So all we need to do is to pass the name and value to our JavaScript and set the right headers with our AJAX request. We could instead of setting headers put the name and value pair into the body of a POST request, as the second conditional doesn't care if the POST request is received via AJAX or not. But this limits the request to POST and the body data type to either multipart/form-data or application/x-www-form-urlencoded (because that's all that PHP's $_POST superglobal will handle). Admittedly this might be 99% of use cases, but for example if a GET request invokes significant processing then CSRF protection could be used to prevent a DOS attack on the endpoint. So, for the sake of a bit more flexibility, and to be more in keeping with what PW expects, we'll use request headers. I find it neater to write the token name and value into HTML and retrieve that using JavaScript DOM functions, instead of writing JavaScript with PHP ?. So somewhere, maybe in init.inc.php, get the token name and value: $csrfTokenName = $session->CSRF->getTokenName(); $csrfTokenValue = $session->CSRF->getTokenValue(); Then in a global footer template: <div class="js-csrf-token" style="display:none;" data-csrf-token-name="<?php echo $csrfTokenName; ?>" data-csrf-token-value="<?php echo $csrfTokenValue; ?>"></div> Now to retrieve the token in JavaScript: function getCsrfToken() { const csrfTokenNode = document.getElementsByClassName('js-csrf-token')[0]; return { name: csrfTokenNode.getAttribute('data-csrf-token-name'), value: csrfTokenNode.getAttribute('data-csrf-token-value'), } } Then in any AJAX request: const csrfToken = getCsrfToken(); let xhr = new XMLHttpRequest(); // ... // open the request and do some configuration // ... xhr.setRequestHeader('X-Requested-With', 'XMLHttpRequest'); // tell the server and PW that it's an AJAX request xhr.setRequestHeader('X-' + csrfToken.name, csrfToken.value); // create a header with the token // ... // send the request // ... And that's all, in the endpoint just do... if ($session->CSRF->hasValidToken()) { // works for AJAX! } This has used the default CSRF token created for every session, but to create and use a different token just specify an id: $csrfTokenName = $session->CSRF->getTokenName('myAjaxToken'); // this creates a token if one with the given id doesn't exist $csrfTokenValue = $session->CSRF->getTokenValue('myAjaxToken'); and... if ($session->CSRF->hasValidToken('myAjaxToken') { // ... }

I saved a copy at the time - here they are (I think!) ?

Regarding those API examples on the homepage, there is an error in the first one: echo pages('/')->children->each('<a href='{url}'>{title}</a>'); Exception: syntax error, unexpected ''>{title}'' (T_CONSTANT_ENCAPSED_STRING), expecting ')' You need to replace the single quotes around {url} with double quotes so it looks like this: echo pages('/')->children->each('<a href="{url}">{title}</a>'); That said, I don't like this example - firstly there is the use of the functionsAPI (which I mentioned above will be confusing unless you are planning on turning this on by default in new installs), but also it outputs this with all titles on the one line. Perhaps a more useful example would be this, especially given that you state it as: "// Render your site’s primary navigation" This is OT, but did I just discover a bug with these? EDIT: https://github.com/processwire/processwire-issues/issues/779 This doesn't work: but these do: Why does getting the homepage ('/') in the first example NOT work?

I don't wanna waste to much words on this but i have to write you my feelings a) i love the concept and design from ryan! b) and i love how constructive and good are all the input on this topic is! (no bashing or i would do it in red...or somehting like that) I know that such a open disscussion could take many wrong turns on other places, but not here! Great people here - wish all a great 2019

As a one-off example of putting Sanitizer to work, I'm currently working on a module in which I convert template names to pascal case class names, so recently added $sanitizer->pascalCase() came in handy there. On the other hand, $sanitizer->pageName(), $sanitizer->selectorField(), and $sanitizer->selectorValue() are probably what I've used the most. Even if I know that ProcessWire has some sort of validation built-in, I much prefer to filter data before passing it to ProcessWire: not only does this provide an extra layer of safety, but it also allows me to display more helpful error messages to the end-user. $sanitizer->option() and $sanitizer->options() are also useful. They're basically shortcut methods to whitelisting values, and who doesn't need a whitelist every now and then? Some Sanitizer features are more about formatting, really: $sanitizer->truncate() is a good example of this, as it's basically creates excerpts of longer text. Definitely useful. All in all, it really depends on what you're doing with ProcessWire, where you're getting your input, and so on. If you're handling raw user input a lot, Sanitizer is particularly useful. Similarly if you tend to enforce more specific rules for your data (say, only allow specific values, or specific characters, etc.) you can get a lot out of Sanitizer. Personally I'm also a firm believer in the "defence in depth" practice: can't have too many layers of protection ? By the way, in your code you mention that Inputfields run Sanitizer methods. It's probably worth noting that Inputfields won't interfere while you're storing data over the API, and thus they won't prevent anything from being saved to the database either. Fieldtypes handle data storage, and Inputfield settings kick in when you edit that value in the Admin.

Back to the idea of the demo site having a Tracy Console - esque sandbox/playground with pre-saved API examples. Obviously this is just the Console in its current version, but you can see that I've saved the examples from the new homepage into the snippets list so that users can select and run them and edit as they wish. I think with a bit of work this could be cleaned up nicely to work as a way for users to see just how great the API is.

I also don't necessarily agree with design by committee, but since this is the first thing you see I feel obliged to dive in... Personally the iMac sans apple branding is a bit weird for the landing page gif since you end up with a big grey bar wasting space, and so much screen realestate is taken up by the display itself and not the content you are trying to show (pw in action). Also, it is such a ubiquitous image that most people will automatically notice something is off, and there may actually be legal ramifications for doing this. Not sure what the solution is, I'll have a think and pm you. Secondly, the poor quality and artifacting in gifs are really noticeable, especially on retina displays, and nothing can be done to be rid of them. Have you though of a <video> for this? This is also an interesting solution: http://www.sublimetext.com/~jps/animated_gifs_the_hard_way.html I'm pretty sure someone will have turned the above into an easy to use library and put it on GitHub. Otherwise, as mentioned, great work!

+1 to giving contrast more consideration. Overall the site could use a bit of brushing up in terms of accessibility – some quick observations: Providing a skip to main content link would be nice, and while we're at it, providing another one for certain long lists of items (such as the showcase items) could also be a good idea. At least on the home page the logo icon and the text next to it are separate links, but still lead to the same location – I'd recommend hiding one of them from keyboard / screen reader users. There are no focus styles for the top navigation, so keyboard navigation feels quite strange; the cursor seems to simply disappear somewhere. The search icon doesn't seem to have label for screen readers to read, so it's just "link: newsite". Same thing with the close icon for the search. One more keyboard navigation issue occurs once I reach the showcase section: again the cursor disappears, and I actually have to browse all items (even though visually nothing changes on the screen) before it reappears. This might've been mentioned already, but I for one keep getting the "home" link wrong, since (in some cases) the text link right next (which is visually connected to the logo and thus I would've expected it to lead to the home page as well) takes me somewhere else. This is one of those "oh, I see what you did there" cases: now that I've clicked the wrong link a couple of times I know how it works, but surprises like that don't exactly improve the overall experience ? Additionally I find it very confusing that the navigation hierarchy doesn't match content structure. For an example, if I choose "Docs" > "API Reference" from the navigation, I'm suddenly taken to another area of the site – and probably for that reason there's also no indication about where I currently am in the top navigation, since this new area isn't included in the navigation, even though it's hierarchically a top level page. Finally, I would recommend adding some sort of indication to navigation links that take the user out of current site. "Community" for an example is (a bit weirdly, in my opinion) linked to the Forum, which may come as a surprise to the visitor. I've always instructed clients to never, ever link to another site from their top navigation – but if we really have to do that, at least we should make it obvious what's happening ? .. and all that said, this is definitely an upgrade to the old site. Sure, there are rough edges, and I must agree with a lot that has been said in this topic, but I'm sure we'll figure it out. Great job, Ryan!

Can you please disable autocomplete on the site search field - the browser's results get in the way of seeing/clicking the ajax returned results.

This week I’m glad to report the development progress on the new ProcessWire.com website is ready for preview and I’ve placed it in a subdirectory for testing. You can find it here: https://processwire.com/newsite/ Of course, this is just version 1 of the new site, but it’s now got quite a bit more updated content than the existing site, so I don’t want to wait much longer to replace the existing site. I’m still working out a few small details, but it should be 99% functional. I expect to replace the existing main site early next week. If you have a chance to test it out, please let me know how if you come across anything that isn’t working or any browser/platform specific issues. Thanks for taking a look and testing it out. I’ll have more details next week, along with a new core version on the dev branch with several updates currently in progress. Have a great weekend!

We already had some discussion about something like this in the AdminThemeBoss thread: Did a quick try today and it looks promising: Currently this parses the LESS on each request, so I need to implement caching of course. But I think this is the way to go for adjusting the backend to your needs and CI. Creating custom themes for that task is just not efficient! Happy to hear your opinions. Does anybody want to take it further? I am really busy this year and that will not change soon...

github clrux a11y-toolbar maybe? or this link: https://github.com/downzer0/a11y-toolbar

Could we maybe deal with this with an optional high-contrast mode? I know accessibility is important but aesthetics, depth and some degree of subtlety are also important. If we insist that all text everywhere has a contrast ratio of 7:1 to cater to the most visually impaired visitors then we give up things like using reduced opacity to differentiate primary/active text versus secondary/deactivated text, and must largely abandon the brand colour as a background. Also its arguable that a high-contrast design is harsher on the eye to the majority of visitors who are not visually impaired. This issue is improved by setting a max-width for the layout. Personally I'd rather see an increased text size for wider viewports than having the main text column floating in the middle, with looks off to me. And if we change to a different font that is less condensed and has a bit more letterspacing built into it then we can achieve a comfortable line length without compromising the aesthetics. Here is my Work Sans variation with the font-size bumped up a little - line length is at a comfortable 100 characters, matching @teppo's suggestion. The main content column could have a slightly reduced max-width on wide viewports if we wanted to bring the line length down a little further. https://sitemod.robin.nz/render/?url=https%3A%2F%2Fprocesswire.com%2Fnewsite%2Fstore%2Fpro-fields%2Frepeater-matrix%2F&amp;css=https%3A%2F%2Fsitemod.robin.nz%2Fnew-pw%2Fmod-2.css

Hey @Mike Rockett ? Have you somewhere your re-design mockups posted almost exactly 2 years ago? I remember they were very well crafted and appreciated by all of us, especially the lighter version. Does anyone remember them? Maybe we could visually iterate over those in order to point the new website in the right and smarter direction, I'd love to hear some kind of feedback about it.

$wire->addHookBefore('InputfieldPage::processInputAddPages', function($event) { $field = $event->object; $page = $field->hasPage; if($field->name == "model"){ $brand = $page->brand; if($brand){ $dynamicParent = $page->brand; $field->set("parent_id", $dynamicParent->id); } } }); I think this should work! Let me know if it does ?

It should be sg like this: $user->language->name === 'en'

I prefer this... +1

I tested this module sometime ago before the release of DataSet and I had to fix the hardcoded admin url. I will sent you the new pull-request this afternoon concerning the following fix/change, feel free to merge it or not. install / uninstall written: fields and template created on installation / removed on uninstall fix: corrected admin page link in module and js file process module link moved under setup (can be moved later by the user without messing the admin url) about, tips markup improvements @mtwebit do you have an idea from where I could start to begin to port this module under Windows as the PCNTL extension isn't supported by this last OS ? I have already in mind implementing pthread to consume a Messaging Queueing System or something like that. And for people who wonder how it works with DataSet, there are a small screencast (shortened) importing a CSV DataSet :

Ooh, that sounds cool! ? Yeah, that makes sense. Forgot about that lovely new addition! Looking forward to not writing my own functions ? Agreed that there's no harm in guarding against any potential changes. AH! ?Right, so in the example code, $form->processInput applies the Inputfield sanitizers but $pages->add does not? Thanks for the wide-ranging examples!

@ryan, having had a chance now to read some of the new text I want to say: great job! It's clear, insightful, and highly persuasive. I notice that "I" is used regularly within the text - no problem with this at all, as I think it's the fact that PW is largely the brainchild of a single individual that has ensured the system has stayed lean and focused. But I feel like we need a profile page to introduce Ryan so people know a bit about who this "I" is. I like the longer-form text, and I think people are often wanting detail. Many information sources these days seem to assume that everyone has a short attention span and it means that things are treated very superficially, which is frustrating for readers who want to learn more. There's a way to have the best of both worlds - a summary at the top and longer information below for those who want it. Regarding the summary, rather than this being just a list of jump links (which is too limited to be a summary) I think a linked heading with a single sentence summary underneath would be good. I agree. Using showcase thumbnails is fine as a last resort so the sidebar isn't empty but these thumbnails are not that relevant or useful to the visitor. I think the sidebar should be used for links to other content related to the current page. We have a lot of blog posts and documentation pages that could be drawn on for this Related section. I think it would be good to highlight Repeater Matrix a bit more prominently - because it's sold as part of the ProFields bundle it doesn't have as much visibility as the other standalone Pro modules. The "builder" functionality possible with Repeater Matrix is trendy right now and other CMS products are selling builder-type features hard. Frankly I think page builders are probably overused and not such a great approach for most situations, but they are popular and we should advertise prominently that this approach is possible in PW.

If I were explaining why I love PW to another developer I'd say... Unopinionated Powerful stable API Security Extremely active, friendly, *knowledgeable* community. I feel like that covers the major pain points that CMS/CMF developers feel, particularly 1) and 2). PW has so many great points that it's tempting to want to cover them all. I kinda agree with others that maybe there are too many points, and too much content.

Love it! The only thing I'm not sure about is the emphasis on... I feel that a low maintenance overhead is already strongly implied by reliability and security sections. I like to run updates if only to keep the CK Editor plugin up-to-date, which *does* have semi-regular security patches. It might not appeal to developers for whom updates are bread and butter. I'd rather see something like... Lower maintenance costs, because security, reliability, and a stable API resulting in painless upgrades. Yeah, I once did a major version PW upgrade on a fairly complex 30,000+ page site and *nothing* broke! Zero. Zilch. Nada. It brought tears to my eyes. A lack of breakage that is unheard of in CMS land. Compare with regular minor version breakage for some other CMS ?

Hey guys, Czech Language Pack was updated for PW 3.0.123. http://modules.processwire.com/modules/czech/ You can download it from Github. If you need older translation, just take a look at releases.

Well I couldn't get sitemod.io working (at least not the way I wanted) so I built my own version - using PW of course ? https://sitemod.robin.nz/ This lets you render any site with a custom CSS file and/or a custom JS file added. Links on the site are rewritten so you can browse around the site and keep your custom CSS/JS. Not much testing done yet so expect some bugs. Here is the new PW site with a max-width applied and the font switched for Work Sans. As I've said elsewhere, I'm really not a fan of the current font and I think this looks much more professional. https://sitemod.robin.nz/render/?url=https%3A%2F%2Fprocesswire.com%2Fnewsite%2F&amp;css=https%3A%2F%2Fsitemod.robin.nz%2Fnew-pw%2Fmod-1.css

The offcanvas toggle icon is using the slightly older approach (the markup got updated at some point during UIkit 3's development): Replace: <a id=offcanvas-toggle class=uk-hidden@m href=#offcanvas-nav uk-toggle> <span uk-icon='icon: menu; ratio: 1.3'></span></a> With: <a id='offcanvas-toggle' class="uk-navbar-toggle uk-hidden@m" uk-navbar-toggle-icon href="#offcanvas-nav" uk-toggle></a>

@ryan, the site is beautyful in so many details! I directly fallen in love with those little wire-loops and plugs etc. ? ! I will have some more in depth looks next week, as I have to work this weekend. Only one thing I want to show you know: Unfortunately the fonts render very bad on my machine, win7 firefox 64. I'm aware that it do not render that bad on all win7 machines, but I'm also not aware of any special settings regarding fonts rendering on my machine. I setup my system completly new from scratch last year, and I left the most things by default settings where applicable, (to reduce time with the setup, as I have to change in 2019). There are, maybe 15% webfonts in websites that behaves like this one too. (?) A 1:1 PNG screenshot is uploaded here, so that it doesn't get rendered through a forums image engine. Please look at it in 100% scale. https://biriba.de/pw_pop3/new-pw-site---fonts-rendering-ugly-win7-ff64.png

@ren Great tutorial, thanks.

I tested it too, and the problem occurs when the paragraph is longer than the truncate length, causing there to be no closing </p> tag present in the truncated string. There is an option for the fixUnclosedTags() method used by truncate, to close instead of remove unclosed tags... * Fix/close unclosed tags: * ------------------------ * When the remove option is false, it will attempt to close unclosed tags rather than * remove them. It doesn't know exactly where they should be closed, so it appends the * close tags to the end of the string. ...but the truncate method calls fixUnclosedTags() with remove = true and doesn't provide a way to do otherwise. I guess you could use WireTextTools::fixUnclosedTags() before calling $sanitizer->truncate but it would be nice to have the option built into the truncate method. Maybe an oversight by Ryan? Edit: request opened here: https://github.com/processwire/processwire-requests/issues/253 @bibsch, because your truncate length is short and will only contain a single paragraph you can achieve your objective by adding <p> tags around your truncated text: echo '<p>' . $sanitizer->truncate($child->body, 200) . '</p>';

+1, forgot to mention this one. WCAG AAA requires that line length is never more than 80 characters, but depending on the source comfortable range can be around 80..100 characters, and sometimes as high as 120. Anything above that is way too long considering readability, and I'd recommend not going past the 100 character (or glyph) mark.

Exactly ? I'm just not sure what would make the most sense. Using Inputfields would be the most comfortable, but I'm not sure if that would make sense at all. Because the question would be which options (colors) to make available via Inputfield and which not. Then I think it's better to leave everything in LESS. So one has also the benefit that it is possible to control all other aspects as well (like paddings, margins etc). https://github.com/oyejorge/less.php That would make live changes possible/easy. But I guess we would need to rewrite all the LESS files? (edit: more below) @Robin S you are right, it already works if you download the theme via github, setup a parser, save the css, set PW to use the new theme, set the theme to use a custom css file. And then there is an update to the repo and you have to do everything again... That's way too much effort imho! I want to install PW, adopt the main colors to fit my clients CI, save and go. I plan to build the less parser as a separate module, because I'm using it for a frontend module as well where I need the same features (parse less and create css, but cache the result if nothing changed). New idea: What if we extracted only those LESS files and images into a folder. Similar to the existing "main css file" Inputfield we could have a "main less file". I've already done this in my current module: Putting this in a separate folder we could zip them and share them with the community without the need of installing a new admin theme, changing only the SKIN (I like that wording, thx @adrian ). But I guess that would be too much... for me it would already be enough to adjust the main colors.

Pushed another update. All strings are now translated! ?

Actually, what you want is this:

@bernhard, could you explain a bit more about what you're proposing? I'm not quite getting it. Would this be a new module with new features - e.g. config inputfields to select theme colours, maybe a bundled PHP LESS compiler for people who don't already have a compiler or don't know how to use a compiler? Or would it be more a tutorial for how to use the customisation features already possible in the AdminThemeUikit module? As far as I know, you can already download and customise the LESS files used in AdminThemeUikit (a development/customisation process is outlined briefly in the module readme). And then when you've customised the LESS and compiled it to CSS you would set the path to that file using the config field in AdminThemeUikit: Or have I misunderstood what the idea is?

Lots of consideration going on here ? Hope @ryan will be patient enough with us all! ? I've made some visual arrangements of an inside page too: - Font in Montserrat from Google Fonts - Title of the page is smaller - Bodycopy is smaller on larger line-height - Paragraphs titles are uppercase - The incipit on the top of the middle column is a bit muted and smaller - Blockquotes stand out better with a slightly green background - Sites thumbnails are no longer visible (they look off to my eyes) - The main container is 1600px boxed

Also I just noticed that "speed" could be mentioned a bit more on the start page. I would say back in the day the phrase "ProcessWire open source CMS is fast. ProcessWire with ProCache is insanely fast!" piqued my interest and made me try the system.

I've played a bit with the homepage, trying to adjust what is off IMHO. I've changed the font with Open Sans, improved padding and spacing, changed the main background color with the one we have right now in the header of the backend. Replaced the logo with the "old" one (I really love the color combination and fonts pairing). Moreover I've quickly swapped the iMac with a flat browser with a (really rough) image of the backend. Of course the double icons you see scattered here and there are not intended to exist (they appeared when I've saved the html, dunno why).

I will check on that flag, @horst ! Thank you for clarifying and to offer your help. ?

First of all @ryan thank you for your work on the new website. It is already looking promising. ? You have already much feedback, but I wanted to give also some first suggestions: Container As @Robin S already mentioned, for very large screens (for example 27 inch iMacs) it would be better in my opinion to limit the container width to uk-container-large. Section Right now every sections is either default or primary. You are are aware of this, but the section component also offers secondary or muted sections. I think it would be nicer to spice things up with more different sections. For example the footer could be first be muted (twitter, forum and news) and then secondary (copyright), Blog I also don't like the current blog overview. In my opinion it would be nicer with cards. Navigation The search should be in my opinion be the last item in the navigation. Although the new search is now really powerful, searching should be the last thing a visitor has to do after all contents are discovered. That was it for now and keep up the great work. ? Regards, Andreas

I think Tracy is great, but it is not part of the core. So when users decided and finally download PW, then Tracy is missing. However, it would be good as a playground like Codepen where you can directly test API snippets. But please also think about, what destructive commands could mean. They could destroy the whole demo site. Don't know, what is possible when demo mode is enabled in PW config. I strongly believe, that Tracy should be part of the core, as it is simplifies development and debugging very much. How can we convince Ryan to integrate it into the core? Maybe this another thread because it is off-topic here.

love it and think most little bits have been picked up. On the design side if possible restricting wide text sections like quotes on the homepage to a restricted width so that word count on each line is between 10-16 words will help people read it without getting lost on the jump to a new line. This both helps people read and looks nicer as it adds white space on wider screens breaking up the sections.

Hi, yes and it's very easy to implement (less than a minute really without styling) : https://modules.processwire.com/modules/ajax-search/ Others results : https://www.google.com/search?q=site:processwire.com/talk/ ajax search

Quick one on the blog comments - it is technically possible to have the forums automatically create a new topic in this forum when a blog post is published, show comments from that topic below the blog post, but also allow you to sign in on the website at the location of the comments form itself and comment there as normal. Would that be preferable to keep all comments in the forums from what people are saying? If you're logged in on the forums already there would be no requirement to login from the blog post again - it would know you're logged in. The form itself would likely be more basic there as I've found embedding the full-featured forum editor tricky in the past, but think this solution might be the best of both worlds to keep the conversation happening here in the community forums if that's what people would prefer?

Working on this, which I hope to finish off at some point in a couple weeks after the main site launch: It will be 2 minutes and 11 seconds long, which is the length of the audio (full audio here). I will try to make it show off the power of ProcessWire as much as possible (tree, fields, matrix, front-end editing, api, docs, formbuilder, procache, github activity). I may need to extend the music a bit for it all to fit. Anyway, this is happening!

A few more thoughts: I feel like the Selectors page (http://processwire.com/newsite/docs/selectors/) needs to be more prominent. To me, this is more useful than the current "Getting Started" and "Tutorials" pages. Or at least, it should be a page that is listed on the Getting Started page. Speaking of the tutorials page, I don't like that most of these are external links - even though they are great resources, I'd rather have users see a centralized source of the best tutorials on the PW site itself. I don't like the pages that put the title next to the PW logo in the header, especially given that not all pages do this - I know it depends on what level page you are on (although not entirely), but I still find it a little confusing. I also don't think that the "Community" top level link should go anywhere. On the variables page, you have: "page() accessing as a function can be very convenient, when available." - how or why wouldn't it be available? I know, but new users won't. This one: $pages->wire('page') is actually quite confusing - again, I get it, but certainly never thought to use it like this and I think it would be really weird to do something like: $pages->wire('fields') I would say this option should not be shown. I also am not sure about showing: $this->page when on the very next line you state that: $this->wire('page') is more efficient - why would anyone want to user the former? Sorry for all the negative, but you know how feedback often is ?

Here are my optimization ideas: The dropdown menu on the right side is cut off (see screenshot) The link "Community" directly opens the forums which has a different look and provides a different navigation. Users will be disturbed by this, because they are being redirected to another site, instead of staying on ProcessWires site. The navigation item "Directory" should be named "ProcessWire Developers" or "Developer Directory". The best title IMHO would be "Find a ProcessWire developer" but that is too long for a navigation item. And "weekly.pw" should have an explanation like "Weekly blog". I think one of the biggest problems with the actual and the new site in general is, that information is distributed across different places. We have announcements in the ProcessWire blog, on weekly.pw and in the forums. Why isn't weekly.pw integrated into the ProcessWire site? I know it's a site by @teppo. But what if he had access to write blog posts on processwire.com? This would make much more sense, and on weekly.pw there is also duplicated content, as it often says the same things as the latest blog post (mostly in a reduced form). The weekly.pw blog post could have a title like "Weekly highlights" Also I think the comment function on the blog post could be moved to the forums, because again we have two places to comment (directly on the site, and in the forums). Why don't you automatically create a new topic in the forums for every blog post, and people can comment there, so the conversation/discussion isn't distributed to several places? More to come ?

It looks like the Dev Map doesn't show. Safari, Firefox, Chrome on Mac.

Nice! A quick observation: I think there needs to be a max container width (1920 pixels? 1600 pixels?) and not fully fluid. Modern monitors can be very wide and fluid sites often don't account for this. My monitor is 3440 pixels across and so the layout can get overly spread out:

Maybe not in the right way and it might be related to this issue (fixed) about API method next() and prev(). https://github.com/processwire/processwire-issues/issues/716 https://github.com/processwire/processwire/commit/8e22bee1b561045fde4d2f7a11479ac5f24c18e2 I think that in order to get the things working back, you must install TracyDebugger, set `$config->debug` to true, load the culprit page and past here the full Exception Stack Trace. Edit: Look like your errors are here : The two method expect a SELECTOR string, not a PAGE Object. https://processwire.com/api/ref/page/next

Here's a working example for you: <?php namespace ProcessWire; $showForm = true; if ($input->post->upload) { $tempDir = wire()->files->tempDir('userUploads')->get(); $uploaded = (new WireUpload('uploadedFile')) // same as form field name ->setValidExtensions(['txt', 'png', 'jpg', 'pdf']) ->setMaxFiles(1) // remove this to allow multiple files ->setMaxFileSize(10 * pow(2, 20))// 10MB ->setDestinationPath($tempDir) ->execute(); // $page = $pages->get(1234); foreach ($uploaded as $file) { $filePath = $tempDir . $file; // $page->files->add($filePath); echo $filePath . "<br>"; } // $page->save('files'); if (count($uploaded)) { echo sprintf("Uploaded %d files", count($uploaded)); $showForm = false; } } ?> <?php if ($showForm): ?> <?php // Adding enctype is crucial!! ?> <form method="POST" action="./" enctype="multipart/form-data"> <label for="uploadedFile"> Upload: <?php // suffix name with [] and add multiple attribute if you allow multiple files ?> <input type="file" name="uploadedFile[]" id="uploadedFile" multiple> </label> <div> <button name="upload" value="1">Upload</button> </div> </form> <?php endif; ?>

We are using it on one ProcessWire install which is used heavily. We have around 20 Decimal fields with over 200k+ pages with all kinds of automated calculations (thanks @Martijn Geerts). Still working fine ... I haven't tried it on other installs, so I would really like to see @sforsman giving his blessing. You might want to test it out yourself. If it works for you I can cover the maintenance, no worries.