Leaderboard

Exciting that the new processwire.com could arrive within the next week! Caught me by surprise too, as I thought it was early days yet for the design and that there would be more evaluation/discussion/iteration of it before it went out live to the world. But I can appreciate also that a "move fast and break things" approach is often the most productive. A couple of observations/opinions of previous screenshots (I didn't comment earlier because I thought it might have been too early for this sort of thing)... I'm not liking the typeface used in the new design. My main gripe is the curved strokes used on characters such as A, V, w, etc. This design detail looks ugly and amateurish to my eye. I know it's a small detail and such things can be a matter of taste but in support of my opinion I'll add that if you look at the work of the top-tier type foundries such as Hoefler or Klim you won't find any typefaces that curve the strokes on these characters. I also think the x-height is excessively large (the height of the lowercase relative to the uppercase). Again it's a subtle thing but I'd argue this sways the balance too far towards "friendly" versus "serious". My preference would be for something more neutral and serious as the main typeface. As an example, Molde is very affordable at the moment and a great workhorse due to the many included weights and widths. Another observation is that the pages that have the entire page background in blue are pretty intense. It's too strong IMO and not so comfortable or inviting for reading. And when it comes to the Showcase the focus should be on the site screenshots - the page design should aim to show them off as best as possible. A strongly saturated background distracts from and can clash with the content in the screenshots. I think the blue background works better in smaller blocks on the page, to highlight a section or provide differentiation between sections on the page. When it comes to large background areas I think white or greys would be better (this could include dark greys or black if we want some blocks to have reversed type). The other thing that I think it would be good to discuss is who the target user of ProcessWire is. I'd love to hear @ryan's view on this, as well as other community members' views. Of course many different types of user could find value in PW, but when it comes to designing and evaluating marketing materials such as processwire.com I think it can be helpful to form a clear picture of a specific target user. We can't have "everyone who wants to make a website" as a target - so who is the user that will find most value in PW, who is that user we want to draw in? I discovered this older topic recently that has some interesting discussion about promoting ProcessWire as an "enterprise CMS". I'm not saying that "enterprise" is what we want to focus on as a primary target market (I don't think it is), but I do think that we need to have more of these kinds of discussions with the aim of clarifying who ProcessWire is targeted to and how best to reach that audience. My view is that the PW's biggest asset is its powerful and well-documented API. And the user who is most able to benefit from that is a user who has a fair amount of development experience. It's probably a user who is a professional developer in one form or another. It's hard to get a sense of the breakdown of types of users currently working with PW - the forum is one of the few ways but it's not a good guide because there could be many experienced developers using PW who don't need help via the forums and are perhaps too busy to make other contributions there. But generally I get the sense that PW is not reaching experienced professional developers as well as it could. Part of reaching and capturing the target audience involves making sure processwire.com communicates to that audience that you've come to the right place. The cues for this can be subtle. I think the visual and written language of processwire.com should be serious, neutral (PW is "unopinionated"), and prepared with the professional developer in mind. The API should be emphasised and we should be careful to avoid any "dumbing down" that might obscure the fact that PW is a powerful and sophisticated tool. I'm not saying that the proposed design or the existing processwire.com are failing in this regard - just that I think these things should be key considerations.

Thanks for all the quotes Horst, Margie and Jmartsch! I have added these into the site. Thank you for all of your feedback and excellent comments/questions. I'm glad you are interested in this, as I love to type about it. ?These are all very subjective things. I've tried to focus on making myself happy with it first. I don't expect everyone to like the same things, as we are all a product of our conditioning, especially as it relates to likes and dislikes of colors, fonts, etc. Even more-so with a global audience. Since I've done the build out this time around, the result is currently consistent with my own conditioned preferences, trying to put my best effort towards that. That's where I have to start. But it won't stay that way and I fully expect design elements (like those you've outlined) to evolve. But because it's all subjective, unless something immediately makes sense to my own understanding, I've got to focus on broad consensus more than individual opinions. That's in part why I want to go ahead and get it online, because it's going to be a lot easier to communicate and collaborate. You are picking things out of the few screenshots I've posted (which is all that can be done right now), but these are just basically thumbnails that lack context. So it's feedback about screenshots rather than an actual site, and I'd like to get to the actual site. The site and the screenshots really aren't the same thing, and the screenshots have a whole different feel than the actual site (for better or worse). For instance, once online, if you think you've found a more suitable typeface, you'll be able to use your browser tools to inspect and change it, take a screenshot and post it, and if it seems pretty unanimous then we'll change it. Other things might take more than just browser tools so I'm also hoping to get it into a site profile. There are other reasons I want to go ahead and get it online. First off, I love the current site, but I also think that for people new to ProcessWire, the current site is starting to look old. I'd become so used to it that I didn't notice until recently. For someone clicking around visiting the sites of the various different CMSs, they likely comparing it to the other CMS sites, all of which look quite a bit newer than ours (I've been visiting them all). We have a great site, but it's a 5-year old site, and I think new visitors see that. I'm guilty of this— I evaluate some product/project/tool or another and don't give a second look to the those that don't subjectively appeal to me with their site. I don't have to love the design aspects of it, but I do have to be convinced that there is quality and that someone cares today, not just yesterday. It has to look relatively new or I just assume the project isn't active, or isn't going to be worthwhile, despite any other factors. Regardless of actual design, that first filter is: "does this look up to date and like someone cares?", because if it doesn't then I'm probably not going to look closer at the product/project. This is of course not very smart, but I've just noticed that's the way my mind seems to work. I'm thinking it might also be the way a lot of us work. So when it comes to the ProcessWire site, my feeling is, the sooner we can get something online that is newer than what's there now (and still accomplishes everything content-wise), the better. I appreciate your perspective and these are good points. Though this is one area where I feel differently. I like what this particular typeface communicates and the way that it does it, though maybe there are others that can do the same. But let me explain. It's precisely those details that draw me to it, because it's just ever so slightly organic. While not apparent at regular body copy sizes, it is in headlines in a few of the letters. It steps outside the expected boundaries every once in awhile, which to me feels like breath of fresh air. Like I hope people perceive PW relative to the others. That little detail of slightly curved strokes on a few of the uppercase letters, when noticed, feels a little like warmth, like the friendliness of ProcessWire, and by that I mean that ProcessWire is more than software, it's community. Anyone can say they are friendly, but ProcessWire actually is. I think it also says something about ProcessWire's API in that it's quality and clear, but it's not just work, it's also something you will enjoy. It's professional first, but there's that slightly warm and organic craftsmanship aspect that goes beyond the hard edges of the cold machine. Lastly, purely side effect, but I do like that some of the strokes slightly curve in an almost wire-like fashion, giving a feel of flexibility over rigidity, which I think is also ProcessWire. But it's primarily the professional while warm aspect that appeals to me. There are all the things I like at least. Maybe there are other typefaces that can do it even better, but I've not found anything that does it quite as well so far. It'd be simpler to accomplish this all with a serif face, but I want the modernity of sans serif without the machine-like coldness, and feel like I found it. I look forward to seeing some other options too, I'm sure they are out there even if I haven't found them. I looked at Molde, and it's attractive but cold, kind of geometric and anonymous, and it's hard not to think of Helvetica, despite there likely being lots of subtle differences. It seems like its strength is in its variations. The condensed version feels like it's starting to relate to PW, except that... it's condensed. ? You might be right, but I think this is one where you'll have to see it in context first, rather than screenshots. I'm well aware that dark text on light background is considered the standard for legibility. So anything that involves paragraphs of text is always on a white background in this site. For pages where the primary emphasis is headlines, links, tiny snippets or copy or images, I'm going with the blue background (which is the same blue that is currently in use on this site). You mentioned intensity but I see calm (maybe it's screen related). Though the intention wasn't really either. It was instead just to have more depth where the content would allow, to show that ProcessWire is not a theme engine and there's a lot of inherent flexibility in how you output content. I wanted to get well beyond the 1-template appearance by having a strong contrast in presentation. To my eyes, it's just as legible as the pages with white backgrounds (and actually, I prefer it for reading, but my eyes have bad floaters so light backgrounds are difficult). But it might be one of those colors that looks great on one screen and not another, so we'll have to see if there's consensus and perhaps fine tune it further. This is an easy answer. The primary audience for the website is web developers (or web designer/developers). The secondary audience is the actual clients that hire web developers, whether that be owners, marketing people, designers, etc. So from a marketing aspect, the purpose of the site is first to get the web developers on board, and second to tell the clients that: not only are they going to love the system, but that it's an exceptionally secure, reliable, safe and really easy-to-use system that will put them a step ahead of their peers. I feel like our old/current homepage only speaks a little bit to these groups and that it's too general and abstract in wording. The new homepage is quite a bit more specific about these two groups. I just need to figure out that darn iMac screenshot, as ProcessWire isn't some tangible thing/object that you show. But I just need a screenshot to show that is compelling enough to capture your eye and make you want to start reading what's on the rest of the page. I have not yet figured out how to show this in a screenshot. ProcessWire is definitely an enterprise tool, but I'm not really interested in spending energy targeting this "enterprise" segment. Several CMS seem to target this, lose the interest of everyone else, and meanwhile the enterprise segment goes off and mostly uses WordPress. ? To a large extent, the enterprise segment listens to their web agencies or in house web designers and developers. I feel that if you are attracting the web design/development community, then you are also attracting the enterprise segment better than you can do directly. The types of users currently working with PW are almost exclusively web developers, and related web design/development agencies. This much is pretty clear. I completely agree that PW is not reaching this audience as well as it could. This really is a primary motivation for rebuilding the site. Also completely agree. And they have come to the right place, but few realize it. That's the challenge to solve. I feel like the new homepage gets quite a bit closer to communicating this, but also think really nailing it perfectly is going to take getting a professional designer involved before it's a home run. However, I think next week when it launches, it'll be a step closer to where it needs to be. Some good momentum to get things going to the next steps hopefully. I largely agree with everything here. I've spent a lot of time writing copy this last week and this sounds consistent with what I've been after. Though I don't think marketing can really be unopinionated per se, because the purpose is to get you to buy into something. For instance, I might say that ProcessWire has the best API, and I really believe it, but such a statement can only ever be an opinion.

Other quotes: "I am currently managing a PW site with 2 million+ pages. It's admirably fast, and much, much faster than any other CMS we tested." Nickie (ProcessWire Developer) Moving my blog to a @processwire installation was the best decision I could have made. So simple to update via mobile devices #processwire Barry Smith (@Lazysod) 4. Juli 2017 @processwire the PHP cms that just Keep on giving. Download it today and enjoy stressfree and fun web development. It realy has changed my life as a developer. It comes with many features and support for https included. #webdev #cms #processwire #php https://t.co/Af1y4QfjHP M. Bonnevier (@magnusbonnevier) 10. November 2017 Transformed my static Single page website https://jensmartsch.de into a dynamic one with #processwire in 5 hours. Adding sections is now soooo easy. Jens Martsch Yesterday sent client a short documentation for the #processwire website. Today all features already used with no questions. #cmsdoneright Marc Hinse (@MadeMyDay) 23. März 2017

Happy holidays everyone! Here's a little present for the new year ? The API Explorer, Console, and File Editor panels now have access to the PW API data via a cache, rather than generating on-the-fly so those panels are now all much quicker after the first load after a core or module version update/install. This also means that we can now provide a "New Since" section in the API Explorer panel, which I first suggested over here. This shows you all the additions to the API compared with the previous installed version. In the screenshot you can see what's new since 3.0.117. If you want to get details about the changes from earlier versions, use the Process Version panel to change back to an old version (to build the cache of the old version), and then change back to the newer one. The Console and File Editor panels only cache the variables sections, so the list would be incomplete if you only had those loaded. I just ran this on the old PW master (3.0.98) and then switched to the current master (3.0.123) and this is what was returned - quite the changelog! A lot of refactoring went into this so that I could cache the API data in a way that I could compare so please let me know if you notice any problems.

I hope that you all had a great Christmas holiday (or other holiday that was last week). And likewise hope that you have a Happy New Year this upcoming week. This week we'll take a quick look at last week's new master version launch and then discuss the status of the new ProcesssWire.com website currently in development: https://processwire.com/blog/posts/rebuilding-the-pw-site-5/

This is now available:

I started in PW a few years back. I love what I’ve been able to develop, although most have been simple marketing websites. I’m a brand developer by trade but I’ve been doing frontend and light database/ php since the late ‘90s. My perception of PW is that it’s a real tool. You can build stuff and not have so much abstraction that revisiting a project requires a ton of time figuring out what code does. I like that because building stuff with staying power serves my clients well. I think PW attracts the kind of person who loves well crafted things; like a good Italian shoe that can be resoaled versus throwing the shoes away because they’re made cheap. I think that PW could really find a wider base if there was a learning framework. There are key people in this community, including Ryan, that could build a curriculum starting from scratch. Courses we pay for that teach us good fundamentals because there are multiple ways to get stuff done but maybe a lot of us could improve our spaghetti code. Then we could delve into more complicated stuff like writing to pages from frontend pages. Some could even involve getting best use of Pro modules. This is an investment because unlike other systems, PW is so fundamentally sound and non-changing that the information would be sound for years. Thanks for listening.

this one from here: https://processwire.com/talk/topic/11355-large-b2b-website-goes-processwire/?tab=comments#comment-105946

I think you should outline the fact that we have a friendly, warm and helpful community, which often responds to questions asked in minutes or hours. And the tone of conversations is very nice. This is ONE thing that I love about ProcessWire. Target groups You are writing, that there is a second target group "actual clients that hire web developers". So I think we need a separate landing page for this target group. The solution could be to present a chooser "Are you a developer/designer?" or "Are you a business owner, CEO... etc/ Are you looking for help?" on the main page which scrolls down on the main page if the first option is selected (because thats the main target group), and leads to another page if the second option was selected. Devs For devs please outline the use as a CMF. I developed two business applications with PW as a CMF, while using the existing backend, and customized it, to my likings. CEOs On the page for business owners there should be sections for getting support and the main selling points of ProcessWire, maybe even advantages over WordPress. Linking to blog post like my own "Why ProcessWire is the best choice for your website (not always, but in most cases)" could be helpful. Looking for a web developer to aid you? We have a list of devs available. Is this and that possible with ProcessWire? Most time the answer is "YES", but if you are curious: Go ahead and ask in the forums. Here the warm and helpful community should also be outlined. Backend showcase I think that ONE screenshot can not resemble ProcessWires backend accurate enough. Multiple sections that describe the main aspects are needed. Also I think that we need different screenshots or maybe even screencasts of the admin/backend for different target groups, because different aspects of the admin are important for these groups. What is important for developers? Everything is a custom field and custom fields can be easily added Dependency fields (showIf) Repeaters Backend is customizable (custom template input masks) Can even be replaced with an own backend Powerfull debugging tool (Tracy debugger, even if its not part of the core, maybe think about integrating it?) What is important for CEOs, marketers? Easy and intuitive backend Fast Access level control Security Customizable Designs SEO friendly Extendable Performance Thats all for now, but maybe I extend this post later, or do another one.

That could work too, although once it's filled you cannot know for sure which format it uses (eg consider 12-12-2018 or 12/12/12), only if you clear the field.

I've created a new documentation page with docsify. I was about to ship standalone markdown files with the module so they could be versioned and read through GitHub (or somehow else). Then I looked at @adrian's docs for Tracy and I liked it, especially the search feature, so I decided to go that route. The next release will contain a major rewrite for filters and macros. They contribute largely to the module's robustness (imo) and I wanted these functions to be available separately too. So there's a new "PWHelpers" class (name is not final) that contains methods that filters and macros are using. This means you can include this class in your non-latte PW projects too and use them if you wish. Another motivation was to make these functions testable which was not possible without this change. I wrote tests for almost every filter and macro. I spent significant time to it (testing is fun :)) and have fixed many bugs. Of course this doesn't mean they are bug-free but they are much safer to use and when a new feature is added I can easily check if everything works as expected (using ProcessNetteTester btw). I was thinking about making this class a separate module but I kept it inside TemplateLatteReplace for now, but I can change this later if there's a need.

This is really cool @adrian! It got me thinking... could something be built upon what you've done here to make it easy for @ryan to update the core PHPDoc comments (and therefore the core documentation) with @since tags? I was imagining something like: Ryan downloads all the PW3 versions from 3.0.0 to current (or maybe he already has them archived somewhere), and then some script runs across all these versions to identify the PW version numbers where new class methods were added. The information is then written back as @since tags to the latest PW version and Ryan pushes this to GitHub to update the documentation. Not sure if this is something that could be built into Tracy as a hidden feature (mainly just for Ryan's use) or if it would be better separated off into a standalone script. Do you think it would it be difficult to code?

ProcessWire is like a breath of fresh air. So powerful yet simple to build with and customise, and web editors love it too. Margaret Chatwin, Web Developer ?

(taken from https://processwire.com/talk/topic/7494-case-study-the-triumph-of-national-geographic-traveller-india-in-processwire/) More can be seen here: https://www.fixmy.pw/blog/why-we-love-processwire-cms-so-much-especially-after-working-with-crappy-joomla-wordpress-and-drupal-cmss/, starting at "For Developers, it's a welcome dream." ?

That's likely not going to be trivial. Adding check_access=0 in a selector to display the link is quite another thing as serving the secure file to a guest user. When you have pageFileSecure enabled, the following happens: PW prefixes the file directory site/assets/files/[PAGEID] with $config->pagefileSecurePathPrefix ("-" by default so it will be site/assets/files/-[PAGEID]) When the browsers tries to show the image (i.e. open the URL /path/to/pw/site/assets/files/1258/image.jpg in a separate request), the file isn't found by .htaccess .htaccess hands off the request to index.php index.php calls PageRender::execute with the request URL PageRender::execute checks if the request is to a file, then checks if the page it belongs to is published and viewable by the current user Since $user->hasPermission('page-view', $page) returns false (the guest user doesn't have view permissions) that fails (otherwise, PW would prefix the path now and output the file) PW outputs the 404 page Since the method where the check is are done is not hookable (and some necessary properties and methods are protected, i.e. not reachable from a hook) you'd probably have to hook before ProcessPageView::execute and duplicate a lot of code from ProcessPageView or hook after User::hasPagePermission and at least duplicate ProcessPageView::checkRequestFile in both cases, match the file URL to $page->image to prevent handing out a access to other file/image fields on the page Another approach (if the images aren't too big and the protected pages aren't too many) would be to include the real image data as data URIs: <?php foreach($protected_pages as $protected_page) { echo $protected_page->title . "<br>"; $fn = $protected_page->image->filename; $imgdata = "data:" . mime_content_type($fn) . ";base64," . base64_encode(file_get_contents($fn)); echo "<img src='$imgdata' alt='{$protected_page->image->description}' />"; } If the images are small enough but you have many pages, using PW's pagination might be an option too.

I've been working with ProcessWire for a while now, and I've noticed that using Composer to manage dependencies and autoload external libraries isn't as prevalent in ProcessWire development as in other areas of PHP programming. I started out by using the default setup recommend in this blogpost. However, one major problem I have with this approach is that all external dependencies live in the webroot (the directory the server points to), which is unfavourable from a security standpoint and, in my opinion, just feels a bit messy. In this tutorial, I want to go through a quick setup of Composer and ProcessWire that keeps the dependencies, all custom-written code and other source material outside of the webroot, and makes full usage of the Composer autoloader. This setup is pretty basic, so this tutorial is probably more useful to beginners (this is why I'll also include some general information on Composer), but hopefully everyone can take something away from this for their personal workflow. Site structure after setup This is what the directory structure can look like after the setup: . ├── composer.json ├── composer.lock ├── node_modules │ └── ... ├── public │ ├── index.php │ ├── site │ ├── wire │ └── ... ├── packacke-lock.json ├── package.json ├── sass │ ├── main.scss │ ├── _variables.scss │ └── ... ├── src │ ├── ContentBag.php │ └── ... └── vendor ├── autoload.php ├── composer ├── league ├── symfony └── ... As mentioned, the main point of this setup is to keep all external libraries, all other custom source code and resources out of the webroot. That includes Composer's vendor folder, your node_modules and JavaScript source folder if you are compiling JavaScript with webpack or something similar and including external scripts via NPM, or your CSS preprocessor files if you are using SASS or LESS. In this setup, the public directory acts as the webroot (the directory that is used as the entry point by the server, DocumentRoot in the Apache configuration). So all other files and directories in the mysite folder aren't accessible over the web, even if something goes wrong. One caveat of this setup is that it's not possible to install ProcessWire modules through Composer using the PW Module Installer (see Blogpost above), but that's just a minor inconvenience in my experience. Installation You'll need to have composer installed on your system for this. Installation guides can be found on getcomposer.org. First, open up your shell and navigate to the mysite folder. $ cd /path/to/mysite/ Now, we'll initialize a new Composer project: $ composer init The CLI will ask some questions about your projects. Some hints if you are unsure how to answer the prompts: Package names are in the format <vendor>/<project>, where vendor is your developer handle. I use my Github account, so I'll put moritzlost/mysite (all lowercase). Project type is project if you are creating a website. Author should be in the format Name <email>. Minimum Stability: I prefer stable, this way you only get stable versions of dependencies. License will be proprietary unless you plan on sharing your code under a FOSS license. Answer no to the interactive dependencies prompts. This creates the composer.json file, which will be used to keep track of your dependencies. For now, you only need to run the composer install command to initialize the vendor directory and the autoloader: $ composer install Now it's time to download and install ProcessWire into the public directory: $ git clone https://github.com/processwire/processwire public If you don't use git, you can also download ProcessWire manually. I like to clean up the directory after that: $ cd public $ rm -r .git .gitattributes .gitignore CONTRIBUTING.md LICENSE.TXT README.md Now, setup your development server to point to the /path/to/mysite/public/ directory (mind the public/ at the end!) and install ProcessWire normally. Including & using the autoloader With ProcessWire installed, we need to include the composer autoloader. If you check ProcessWire's index.php file, you'll see that it tries to include the autoloader if present. However, this assumes the vendor folder is inside the webroot, so it won't work in our case. One good place to include the autoloader is using a site hook file. We need the autoloader as early as possible, so we'll use init.php: EDIT: As @horst pointed out, it's much better to put this code inside the config.php file instead, as the autoloader will be included much earlier: // public/site/config.php <?php namespace Processwire; require '../../vendor/autoload.php'; The following also doesn't apply when including the autoloader in the config-file. This has one caveat: Since this file is executed by ProcessWire after all modules had their init methods called, the autoloader will not be available in those. I haven't come across a case where I needed it this early so far; however, if you really need to include the autoloader earlier than that, you could just edit the lines in the index.php file linked above to include the correct autoloader path. In this case, make sure not to overwrite this when you update the core! Now we can finally include external libraries and use them in our code without hassle! I'll give you an example. For one project, I needed to parse URLs and check some properties of the path, host et c. I could use parse_url, however that has a couple of downsides (specifically, it doesn't throw exceptions, but just fails silently). Since I didn't want to write a huge error-prone regex myself, I looked for a package that would help me out. I decided to use this URI parser, since it's included in the PHP League directory, which generally stands for high quality. First, install the dependency (from the project root, the folder your composer.json file lives in): $ composer require league/uri-parser This will download the package into your vendor directory and refresh the autoloader. Now you can just use the package in your own code, and composer will autoload the required class files: // public/site/templates/basic-page.php <?php namespace Processwire; use \League\Uri\Parser; // ... if ($url = $page->get('url')) { $parser = new Parser(); $parsed_url = $parser->parse($url); // do stuff with $parsed_url ... } Wiring up custom classes and code Another topic that I find really useful but often gets overlooked in Composer tutorials is the ability to wire up your own namespace to a folder. So if you want to write some object-oriented code outside of your template files, this gives you an easy way to autoload those using Composer as well. If you look at the tree above, you'll see there's a src/ directory inside the project root, and a ContentBag.php file inside. I want to connect classes in this directory with a custom namespace to be able to have them autoloaded when I use them in my templates. To do this, you need to edit your composer.json file: { "name": "moritzlost/mysite", "type": "project", "license": "proprietary", "authors": [ { "name": "Moritz L'Hoest", "email": "info@herebedragons.world" } ], "minimum-stability": "stable", "require": {}, "autoload": { "psr-4": { "MoritzLost\\MySite\\": "src/" } } } Most of this stuff was added during initialization, for now take note of the autoload information. The syntax is a bit tricky, since you have to escape the namespace seperator (backslash) with another backslash (see the documentation for more information). Also note the PSR-4 key, since that's the standard I use to namespace my classes. The line "MoritzLost\\MySite\\": "src/" tells Composer to look for classes under the namespace \MoritzLost\MySite\ in the src/ directory in my project root. After adding the autoload information, you have to tell composer to refresh the autoloader information: $ composer dump-autoload Now I'm ready to use my classes in my templates. So, if I have this file: // src/ContentBag.php <?php namespace MoritzLost\MySite; class ContentBag { // class stuff } I can now use the ContentBag class freely in my templates without having to include those files manually: // public/site/templates/home.php <?php namespace Processwire; use MoritzLost\MySite\ContentBag; $contentbag = new ContentBag(); // do stuff with contentbag ... Awesome! By the way, in PSR-4, sub-namespaces correspond to folders, so I can put the class MoritzLost\MySite\Stuff\SomeStuff in src/Stuff/SomeStuff.php and it will get autoloaded as well. If you have a lot of classes, you can group them this way. Conclusion With this setup, you are following secure practices and have much flexibility over what you want to include in your project. For example, you can just as well initialize a JavaScript project by typing npm init in the project root. You can also start tracking the source code of your project inside your src/ directory independently of the ProcessWire installation. All in all, you have good seperation of concerns between ProcessWire, external dependencies, your templates and your OOP-code, as well as another level of security should your Server or CGI-handler ever go AWOL. You can also build upon this approach. For example, it's good practice to keep credentials for your database outside the webroot. So you could modify the public/site/config.php file to include a config or .env file in your project root and read the database credentials from there. Anyway, that's the setup I came up with. I'm sure it's not perfect yet; also this tutorial is probably missing some information or isn't detailed enough in some areas depending on your level of experience. Feel free to ask for clarification, and to point out the things I got wrong. I like to learn as well ? Thanks for making it all the way to the bottom. Cheers!

I just encountered a weird problem with an installation. I have some sort of a poor man's mediapool, which consists of a template with fields of type files(and a second with images) to upload PDFs and images which will be linked to from other pages. This worked well for the last months. This morning an editor called me and sent me this screenshot: All files were gone in the backend but still accessable in the frontend and present in /assets/files/ True, there were no columns in the database table named filedata for the fields mediendateien and medienbilder: I created them manually and the files were back again and the error messages gone. But what happened? What is filedata used for? It is of type mediumtext.(I checked other image and file fields) All the other image fields didn't show the missing column. Only those two... I did an update from PW 3.0.62 to 3.0.98 last week. Edit: Just discovered that filedata is used for focus information: {"focus":{"top":33,"left":37.5,"zoom":0}} I kinda fixed it for now, but it makes me nervous... Anyone an idea?

Not sure where I originally saw it while lurking around the forums, but someone, somewhere at some time was asking about styling Uikit checkboxes as toggle-style switches, much like the ones at the bottom of this post asking me if I want to be notified of replies. So here is my humble offering, rough and ready, which can be thrown in at the bottom of your Uikit css as a starting point. Everything is based on ems and rems, so you can increase size as you desire by altering the single instance of font-size. It only targets single instances of labels within a specific field to a) try to limit unintended consequences and b) because in those cases it often seems more user-friendly to have an on/off binary switch rather than a checkbox. It's still totally a checkbox, just styled differently. .uk-form-controls-text label:only-of-type input.uk-checkbox { font-size:.8rem; margin-top:0; position:relative; -webkit-appearance:none; outline:none; width:4em; height:2.4em; border:2px solid #D6D6D6; border-radius: 3em; box-shadow:inset 5em 0 0 0 #DDD; flex-shrink: 0; } .uk-form-controls-text label:only-of-type input.uk-checkbox:after { content:""; position:absolute; top:.25em; left:.25em; background:#FFF; width:1.6em; height:1.6em; border-radius:50%; transition:all 250ms ease 20ms; box-shadow:.05em .25em .5em rgba(0,0,0,0.2); } .uk-form-controls-text label:only-of-type input.uk-checkbox:checked { background-color: transparent; box-shadow:inset 5em 0 0 0 #4ed164; border-color:#67bba5; } .uk-form-controls-text label:only-of-type input.uk-checkbox:checked:after { left:1.85em; box-shadow:0 0 1em rgba(0,0,0,0.2); } label:only-of-type input.uk-checkbox:checked + span { color:#008a00; transition:all 250ms ease 20ms; } .InputfieldCheckbox .InputfieldContent label:only-of-type {display:flex;} label:only-of-type input.uk-checkbox + span { color:#c3c3c3; display:flex; align-items:center; line-height:1.1; } /* Below is only necessary if you want the optional "tick" after items when selected */ label:only-of-type input.uk-checkbox + span:after { flex-shrink:0; margin-left:.5em;width:2em; opacity:0; content:url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 250 250'%3E%3Ccircle cx='125' cy='125' r='125' fill='%23231F20' opacity='.1'/%3E%3Cpath fill='%230B8B44' d='M95.823 139.432l-32.492-32.56-31.872 31.883-.008-.008 63.72 63.732L218.549 79.116 187.494 47.52z'/%3E%3C/svg%3E"); } label:only-of-type input.uk-checkbox:checked + span:after { opacity:1; transition: opacity 250ms ease 150ms; }

Do not use the "find selector", but instead the "string selector" and insert the following code: template=group, created_users_id=[user]

Glad you like it ? While I like your thinking here, I think it might actually be a better fit inside Ryan's API Explorer Pro module. My understanding is that he uses that to build the documentation on the website as well as being a module that users can install on their systems. I think because of the way I have written this for Tracy, working off an array of classes/methods/properties cached from the last version, I don't think I have much of a leg up towards what you are suggesting. I definitely think it's a good idea though and maybe worth a suggestion to Ryan here: https://github.com/processwire/processwire-issues/issues/759 Perhaps someone out there with Ryan's module might like to tackle adding this functionality?

Something that I found useful recently... Users can type a date/time directly into a Datetime field, which can often be faster than using the separate controls in the datetime picker. But the problem is that there's nothing built into the Datetime inputfield to let users know what the expected input format is for the date/time. You could enter the input format in the description or notes for the field, but you'd have to do this separately for every Datetime field and remember to update it if the input format changes for any reason. Instead, you can use a hook to automatically show the current input format in the notes for all Datetime fields: $wire->addHookBefore('InputfieldDatetime::render', function(HookEvent $event) { /* @var InputfieldDatetime $inputfield */ $inputfield = $event->object; $datetime_input_format = $inputfield->dateInputFormat; if($inputfield->timeInputFormat) $datetime_input_format .= ' ' . $inputfield->timeInputFormat; $ts = strtotime('2016-04-08 5:10:02 PM'); $inputfield->notes = 'Input format: ' . date($datetime_input_format, $ts); }); Or as the title tooltip if you prefer (you have to add the title to wrapper because a title on the input itself gets wiped out by the JS datepicker): $wire->addHookBefore('InputfieldDatetime::render', function(HookEvent $event) { /* @var InputfieldDatetime $inputfield */ $inputfield = $event->object; $datetime_input_format = $inputfield->dateInputFormat; if($inputfield->timeInputFormat) $datetime_input_format .= ' ' . $inputfield->timeInputFormat; $ts = strtotime('2016-04-08 5:10:02 PM'); $inputfield->wrapAttr('title', 'Input format: ' . date($datetime_input_format, $ts)); });

Hi @rareyush This forum's Rich Text Editor has a "Spoiler" feature which can be used by clicking on the "eye" icon in the toolbar. Could you please move your two config file code snippets into "spoilers" to make this thread more readable. Thanks in advance.

RestApi.info.json in the github repo still says 0.0.3. Did you forget to sync your local changes to github?

I just updated a local copy of the site from 3.0.62 to 3.0.98 and the field mediendateien(files) and medienbilder(images) are missing the column filedata afterwards. Other image or file fields are fine. During update I hit F5 a few times, refreshed modules and saw that the fields file and image updated. Then I hit "Check field data" of the fields with missing column filedata and I got an "All okay" But the column filedata is missing! To sum up, there are 5 image fields: image1 = updated (has data) image2 = updated (has data) image3 = not updated (but has no data in DB) medienbilder = not updated (has data) pageimages = updated (has data) 2 file fields dateien = updated mediendateien = not updated There has to be raeson why some fields won't update...

There are no guarantees that Gitlab or any other providers won't do that either. If people are afraid of snooping, they shouldn't check-in code to a 3rd party provider in the first place.

Finally got around to watching this recent documentary about Microsoft's abuse of monopoly and its lobbying practices in the EU: MS lobbyists using government email addresses and other fun stuff revealed!