Leaderboard

Thanks to several of you for suggesting that Tracy should be part of the core and as much as I like the idea in theory, I am not so sure about it in practice. Here are several reasons why I don't think it should be part of the core: 1. I think all core code should be vetted by Ryan and Tracy is just too large for him to be able to do that. 2. There is always the chance that I, or the guys at Nette that develop the Tracy core, could introduce a security bug - obviously we do our best, but I don't think Ryan should have to worry about this affecting the reputation of PW. 3. I update and add features to Tracy very often and I wouldn't want to have to wait on Ryan to approve PRs for those changes. 4. Tracy does slow down ProcessWire a little when activated and the debug bar is showing, especially on pages with lots of complex fields (this can be reduced by turning off certain sections/panels). I think most of us are willing to live with this for the advantages it brings, but I think new users should probably experience PW with the best possible speed and then decide if they want Tracy. 5. Some users just might not like Tracy - they already have their own way of debugging and don't want something else getting in their way - I think they're crazy, but who am I to judge ? Anyway, hopefully those arguments make sense, but I really do appreciate how much you guys value Tracy as a tool in your own workflows - don't forget to like in modules directory and star on Github!

When creating the field, set is as not required. Then after adding it to your Events template, edit it to Required on the template. That will make it a required field for only that template.

ok, @adrian your points make sense. Then there's only one solution: Adrian has to become part of the core ?

My thoughts exactly. A video + a code console to play with the API, as mentioned before, would be much more effective.

Congratulations on the launch, Ryan! I do have issues with the iMac/screenshots images though, as others have said before me. Not because it is an iMac, but because of the impossible size of the content. My first reaction as a visitor is to squint my eyes and to move my head close to the monitor to see the actual PW screenshots inside it. And to be honest I think that is a problem, because: The very first impression, the first thing people look at, on any website will always be graphics/images, not text. You only get one shot at a first impression The first impression should be very clear and very convincing The iMac frame and code in the background take about 75% of the available real estate, making the actual screenshots tiny! A simple sliding carousel or slideshow would suffice, possibly showing steps like: The pagetree Editing a page Cropping an image Creating fields Creating template

Thanks @teppo for featuring our site in PW Weekly! ? Now I'm back at work and am not rushing to finish a website, I thought I'd add a little extra information about the setup of the Jobs site. For this particular site a great deal of the content already existed on our main site. It was decided that it was time the jobs had a dedicated site, so some design concepts were done by our multimedia and marketing team, and then we set about building the site in PW! A fair bit of the content is just made up of standard web pages with a body, some images and some document uploads - but the key thing that makes this site a bit different is that the Antarctic jobs listing is seasonal. We have a big recruitment campaign at the end of each year (as we are at the time of writing), ready for the next Antarctic expedition season. The jobs are visible on the site all year round, but only open for application during the recruitment campaign. On the surface this might seem like a simple 'on/off' scenario for all jobs, and therefore controllable with one checkbox and and if/else statement... but then there are exceptions. Not all jobs are necessarily open during the recruitment campaign (as you can see on the jobs listing currently, some say 'Apply now' and some say 'Not open': Jobs in Antarctica), and some display slightly different messages about the way you can register interest while they are closed (these exceptions are handled within functions). We implemented a 'recruitment settings' template/page. On here there is a checkbox for stating whether the overall recruitment campaign is open or closed. (This recruitment settings page is also a place where global job information is stored, such as the 'How to apply' section, and the General information for applications PDF that you can see on this page: job example. This means they only have to be edited in one place.) Then on each job there is a checkbox for whether or not the job is independent of the campaign. The default value is no, but if yes is selected the job can then be marked as open or closed individually. This means editors only have to worry about marking the exceptions. This job status functionality was in place on our old job pages on our main site, but in that CMS (Squiz Matrix) the setup was quite complex and it was something we really had to do on behalf of our recruitment staff. It has been nice to be able to give them a customised and more straightforward experience.

Hi, This is my another PW website - http://pkrosifoundation.org No Modules used

@ryan Congrats on the launch! One more thing I noticed, in the "ProcessWire Pro Shop" section on the homepage, the module tiles use some JavaScript magic to figure out if a tile was clicked and navigate to that page. That's a bit annoying, since I can't use CMD-click or middle-mouse-click to open the link in a new tab (I like to open multiple links in new tabs and then read through them in turn). This could easily be improved by just wrapping the entire card inside the anchor-tag, then the JavaScript isn't needed at all. This would also help accesibility.

Update: I've released a preview that everybody can use to play around with and hopefully contribute to this project: Here is the LESS theme that I used: This is basically the reno theme file of the original AdminThemeUikit, but I introduced the "tm-primary-color" variable. In the reno theme there are several variables with similar colors and it would be nice to have those colors dynamically calculated. Maybe some of the CSS and design experts can help here? @tpr @renobird Who else? My goal is to have a theme that we can use, where we would only have to change two or three main colors and the look&feel of the admin could fit our clients' CI. Maybe we would also have to define contrast colors for text (if the background is light, the font color needs to be dark). Maybe we could create two themes: One for light backgrounds, one for dark? Only thing that I'm not really happy with so far, is that the AdminTheme is not listed in the modules upgrades list, because it is not yet listed in the modules directory. I guess that would be easy to change. In the video I'm using a fork of Ryan's version, because I need one method to be hookable. Please support this PR on github: https://github.com/ryancramerdesign/AdminThemeUikit/pull/77 PS: I'm using https://processwire.com/talk/topic/17860-preview-processwire-kickstart/ if anybody wonders ? PPS: Here are the github repo links: https://github.com/BernhardBaumrock/RockLESS.git https://github.com/BernhardBaumrock/AdminThemeUikit.git

@ryan, could you please confirm: ProcessWire will no longer have a wordmark logo and will instead use only the graphic from the previous logo together with the word "ProcessWire" set in whatever brand font is decided on? If that's the case then the selection of brand font is even more important, and personally I don't think we should be considering any open-source/free/system font as candidates for the brand font. The problems being... 1. Free/system fonts are so ubiquitous that it's difficult to build up any association between the brand and the font when countless other brands and messages are associated with it. 2. Free/system fonts are widely used by ma-and-pa brands and amateur designers, and used for a multitude of non-designed purposes (e.g. quick paper signage like "toilet out of order", etc). This means they are often used carelessly in ugly settings, and the fonts become subconsciously tainted by association in the minds of the audience. I don't think we should risk that taint getting attached to the ProcessWire brand, even if only subconsciously. 3. In the case of a system font stack, an additional problem is that San Francisco, Segoe UI, Roboto and Helvetica Neue are all completely different designs with different "moods". Setting the brand logo in any one of a number of different fonts depending on device is tantamount to saying "we don't really care what typeface defines our logo and brand". It's true that problems 1 and 2 can apply to commercial fonts also, but in practice the barrier of having to pay for the font means that most users of the font are professionals (reducing the odds that the font is seen in ugly settings) and the font is less likely to be available to the creators of paper signs, etc.

The old logo is back due to popular demand. I've never liked the way it looks next to the newer mark, but reducing the brightness of the word "Process" seems to help a bit, so I think it works for now. The issue with the overlapping dropdown should be fixed now, please let me know if anyone else is still seeing it. You might have to double-test in Incognito mode if you do, just in case something is stuck in the cache. I agree with Adrian's points on Tracy, and also I wouldn't know how to maintain it if he ever decided to go meditate in a cave in India for a year. But I also agree about how useful and important Tracy is and that we should give her first class treatment around here and make it as easy as possible for people to make it a part of their installation. Perhaps the core modules install screen has an "Install Tracy" button, or special site profile, or maybe PW's default error messages could suggest Tracy as an option for additional developer help, etc. I think the example is fine because it just depends if output formatting is on or off. And if it's on, it'll give you an error about what you need to do. The purpose of those examples on the homepage is not to provide a full start-to-finish API workflow, but it's to show some interesting snippets to what's possible in 1 line of code. This is more about marketing than it is about serving as documentation, though of course they are good examples too. Regarding use of $pages vs pages(), I had thought we had it enabled in all the site profiles by now, but it turns out it was in the newest one but not the older ones. I'm updating the older ones so that it is enabled by default. I'm also updating the error handler so that if it detects you are trying to use the functions API but the $config->useFunctionsAPI is false, it replaces the "undefined function" error message with a "you need to enable the functions API and here's how..." message. Tracy actually got me thinking of this because I mistyped something and its error said something along the lines of "did you mean [alternative-function]" (not sure of exact wording) and I found that incredibly helpful. It's showing up for me. It's just there's a lot of stuff with the word "find" in it, so you just have to click on the view-all link. This is actually how we make it possible for that footer to be always up-to-date with the forums, Twitter, etc., even if the rest of the page is on a 1-day (or 1-week) cache via ProCache. It uses Uikit's scrollspy to automatically load the footer via ajax from a separate page that is on a 60-second cache, but only if you actually scroll to it. In this manner, we're getting full cached delivery, and a fully up-to-date News/footer section when/if you scroll down to it.

There is of course Soma's old Modules Manager, but I haven't used it in years now. Maybe a new Modules Installer panel for Tracy ?

Congrats on the launch! The whole site looks much more modern and to the point now! Respect for putting in this much effort in such a short amount of time! I second the suggestion of showing a video or a slideshow of images without the imac frame on the starting page. The frame indeed distracts the user from the valuable content imho and steals important space for displaying the actual features of PW. Also a display of a console where the output of API calls is displayed could be a game changer in terms of a pro PW decision for developers. I think Tracy Debugger should be part of the core. In my eyes this is one of the most valuable developing tools if working with Processwire.

I have to agree here. While I'm ok with any font (either system or non-system) for text, I think we are losing the brand with system fonts for the logo. I think that we should keep the original logo with icon and text together. I also don't like iMac picture. For me, it doesn't make me think that this CMS is for developers, but rather "O, this software only works on Apple device, I'll pass that one". As I understand, this is just temporary?

So I don't know how many have noticed yet, but Youtube has depreciated "rel=0" at the end of the embedded url in September 2018. For some reason, I just noticed today on a site I was working on. If you do not use the rel, you will get related videos across youtube, but if you use it, you will only get related videos from the same channel. Just wanted to share in case people did not know and they needed to make a change on whatever they were working on.

It still confuses me sometimes... to be honest.

Sounds good!! I think it is especially confusing that you have: $page, but then pages() - that suggests to me that there is no $pages option. I still think all examples on the site should use one approach with a dedicated page that explains what can be used where and why. I provided more detailed thoughts about this here: https://processwire.com/talk/topic/20596-new-post-new-pw-website-ready/?do=findComment&comment=178332 I think all the $this->wire('pages'), $wire->pages, $this->pages, $pages, pages() options are confusing to newbies to PW and OOP in general. But I won't mention it again if you think it's OK ?

@bramwolf, you can adapt the approach suggested here, which avoids having to duplicate anything other than the template files: So you would: set domain 2 to point to the server that hosts the website at domain 1 allow domain 2 as an alias in the hosting configuration (see the alias options in cPanel, Plesk, etc) in /site/config.php check which domain is being accessed and set the templates path/url accordingly

Aren't we already ???

I'm pretty sure it's about 80% done by now ?

@adrian Thank you for your concern. All five points are valid arguments, I support them all. And thank you even more for your steady effort to improve this valuable tool!

@manlio Have you deleted repeater fields with same names?

That's not a bad idea, I love writing tutorial and that thought has always been there, maybe it is something I can look at except that payment issues is one that discourages me from sure since my country has so many restrictions, but it is something that is due. A book someone can follow from scratch to finish. Good idea

I've just updated the PW search function in the PW Info panel to use the new website's search functionality for all sections, except the forum (where I still use Google) and of course the Github repo. Hopefully you'll find this is nice shortcut to the new PW site search which is really great!

Wouldn't just adding style="fill:#fff" or fill="#fff" to the <path element suffice? Or even: <style> .pw_logo_color {fill: #fff} .pw_logo_color:hover {fill: #D82C82} </style> <path class="pw_logo_color" ...

You're talking about wall-time. To be really save for future dates you need to store not only the datetime (UTC) + timezone, but also the wall time. There are changes in timezones multiple times per year and some are even countries changing how their timezones work. If you have both UTC and wall-time you can detect such changes and react accordingly. The UTC time you need as soon as you need to compare / act on times, which are in multiple timezones, you need to interact with some APIs or export .ics calendar files. So for your examples it might be fine to disregard the timezone and only use wall-time. Here's some more information on why timezones are hard: https://zachholman.com/talk/utc-is-enough-for-everyone-right I've also found this to be a good blog with a bit more actionable advice: http://www.creativedeletion.com/

Hi all, I have posted this in the VIP support forum of Padloper as well. Some of you do not have access to that board so posting here as well. Hopefully it doesn't count as spamming?! In June 2018, Antti announced that he was looking for a new product owner for Padloper. Sometime after, I had a fruitful discussion with him about my vision for the project if I was to take over. We agreed that commitment, motivation and a concrete plan were all important ingredients for the continued success of Padloper. I would like to officially announce that I am now the product owner and lead developer of Padloper. For those who may not know, I am the author and maintainer of several ProcessWire modules, both free and commercial. I am also a moderator in the ProcessWire forums. I would like to share with you a number of things regarding what’s going to happen next. This will be a long read. First, I would like to thank Antti for developing a great product. A lot of man-hours, dedication, passion and love has gone into making Padloper what it is today. Secondly, I would like to thank all users of Padloper. A great product is nothing without active users utilising it, putting it to the test, reporting bugs (even offering possible solutions) and proposing new features. So, thank you for helping make Padloper great! Support Thousands of hours have gone into developing Padloper. Although the code is well-written and easy to follow, Padloper is a big application with many moving parts. As such, it will take some time before I can fully grasp its inner workings. To make this transition as smooth as possible, Antti will help me with support for Padloper for some time. Currently, Padloper has a dedicated support forum. This is an arrangement between Ryan and Antti. The support forum works great as it allows the opening of multiple support threads to cover different issues. I have yet to speak to Ryan whether this arrangement can continue. However, given that I have other pro modules that I support in the open forums, it is unlikely that I will be requesting Ryan to let Padloper’s dedicated forum carry forth. A dedicated forum for one of my pro modules and open forums for my other pro modules will lead to confusion and questions from users of those other modules. Hence, Padloper support in the forums will move to the open forums. The disadvantage here is obviously the fact that support will be offered in one single (and maybe massive) support thread. To get around a ‘single thread support forum’, I am thinking of developing a simple online support queue system for all my modules. Meanwhile, support will continue in a new single thread and via email. Roadmap This list is neither exhaustive nor cast in stone. Its aim is to give an overview of my plans for Padloper. · Padloper 2 – a new major release · New backend for Padloper · Optional pro frontend module for Padloper · Documentation · New payment modules Let’s talk a bit about this list. Padloper 2 Release Padloper 2 will be a major release that incorporates a new, central backend shop for Padloper. This will be a new process module that pulls from the existing parts of Padloper (data models, etc) into one interface (more on this below). This version will also be extensible in the frontend, allowing for the plugging in of a new, optional, commercial frontend shop (full featured shop profile). Padloper 2 will not support the current ‘any page can be a product’ paradigm. Technically, products will still be pages. However, all products will utilise the same Padloper template. These will be invisible to the shop users themselves (e.g., hidden in admin tree). Only superusers will have full control of the Padloper system stuff. Support The current Padloper will continue to be supported until the new Padloper 2 is released. New features will be included in Padloper 2 only. Once Padloper 2 is released, legacy Padloper will only receive security fixes. All other support will cease. Upgrade There will be no upgrade path from the current Padloper to Padloper 2. Although their underlying architecture is the same, making sure that everything works in different setups and environments will be time consuming. However, for those who really need to migrate, if time allows and for an agreed fee, I could develop a custom script for the migration. Backend A new backend interface will be the major visual difference between the existing Padloper and Padloper 2. It goes beyond visual differences though. The new backend will be the single gateway for managing all shop-related features, both current and new ones. The backend will unify and include: · Easily add shop products. · Ability to add as little or as many custom fields to products as required (title, SKU, price, discount field, image/photo, description, categories, tags, etc). · Discounts manager (including auto start/expire discount codes). · Customers manager. · Invoices manager. · Taxes management. · Payment gateways manager. · Improved digital products management. · Stock management. · Manual order creation. · Graphical sales report. · Customer support. · Access-controlled shop editors/staff. · Dashboard for shop metrics. · Shop settings. · Product variations. · Import/export products as CSV or JSON. · Products search/filter. · Etc. Users will be able to turn off backend features that they do not need. This will enable a more streamlined experience for users. I plan to release Padloper 2 within 4 - 6 months, hopefully sooner. This is a major undertaking, hence the timescale. Please note that the first release of Padloper 2 will not include all of the above planned features. The idea is to build incrementally, adding new features in minor updates, focusing on stability, usability and security. Frontend Past requests have included the development of a full featured frontend shop. This is planned for Padloper 2. However, this will be an optional pro module priced separately from Padloper itself. The ability to build own frontend shops using Padloper API will still continue. For those who want a plug-n-play solution, this frontend shop will come in handy. The frontend shop profile will feature an ajax-powered shopping cart and a customisable ready-to-go theme. Pricing Model There are no plans to change the current prices of the 3 Padloper licences (Single, Developer and Agency). However, in order to continue to provide Padloper as a stable product with great features, it is also important that it remains a competitive and financially sustainable project. In order for this to happen and to also bring Padloper in line with my existing pro modules, the pricing model itself has to change. Starting from Padloper 2, the pricing model will shift to an ‘annual subscription’ model rather than the current ‘lifetime licence model’. I am fully aware that there are different opinions for and against annual subscriptions. However, I believe that this model is the most equitable approach that suits both the developer and the clients. The annual subscription will allow users (licence holders) to get 12 months of free VIP support for Padloper as well as future updates available within that time period. After the 12 months, users will be able to renew (online) their subscription at a discounted cost (worked as a fraction of the full purchase price) for a further 12 months (perpetually). Users will be able to continue to use Padloper for life even if they don’t renew their subscriptions. Upgrading current licences to Padloper 2 will be a paid upgrade. Current users of Padloper will get an attractive discount. This will be a time-limited offer (maybe a couple of months) that will start with the release of Padloper 2. New customers will pay the full price for Padloper 2. I hope the planned features are reason enough for you to consider upgrading to Padloper 2. Payment Modules I will be taking over as the maintainer and lead developer of the existing payment gateways (Payment base class, PayPal and Stripe). New payment modules are also planned. Payment modules will continue to be free. However, only ProcessWire 3+ support will be provided going forward. Padloper Domain and Future Downloads I have also taken charge of the Padloper domain. Within the next 12 months, purchase and download of Padloper will shift to processwireshop.pw. Please note that this is not the official shop for ProcessWire! It just bears a name that reflects its product offerings ?. Eventually, traffic to padloper.pw will redirect to processwireshop.pw. Feedback I would love to hear your thoughts about the upcoming changes and any feature requests you might have for Padloper 2. Whilst I cannot guarantee that any request will be implemented, I can promise that I will thoughtfully consider all feedback. Thanks for reading and thank you for supporting Padloper! kongondo

Never depend on one traffic source! Play the Google-game as it brings you traffic but still play the same game with others.

Thanks for your thoughts @wbmnfktr - I agree that examples must work as they are - they shouldn't result in a message explaining why they don't work. Ok, I'm done now, I promise :)

Marketing sight: Absolutely true! User sight: G*d d*mn f*ck sh*t! It doesn't work. I was on the search for a new CMS (back in 2014) that could maintain hundreds and hundreds of custom fields. Some things I tried back then ended in an error but I stayed because I had someone that said "ProcessWire works!" Without that second voice I would have moved to something else. Working examples are more an argument PRO ProcessWire than examples you have to understand with basic knowledge of the system. I was able to type the characters shown in the tutorials but didn't know what was happening. That came with time and the more I worked with ProcessWire the more I started to love and believe in ProcessWire as my CMS of choice. But that's just my experience and sight on this.

Ah, got that. It wasn't obvious that the field requirement change on the template would only affect the field on that template and not on another. Phew, all those hidden treasures in PW, I could fill a BFD calendar with discovering just those....

I'm trying out the front end features in earnest for the first time. I'm trying to edit my title field inline. It works, but for some reason it's allowing me to enter new lines for a single line text input. If I enter new lines and hit save, they are converted to <br /> tags (via the html entities output formatter). But if I double click to edit again, the tags are processed as live html in edit mode (potential security flaw?). And if I try to remove all of the new lines, I still end up with at least one stray <br /> tag at the end of the line.

Here's another example from the VersionControlTests package: https://github.com/teppokoivula/VersionControlTests/blob/master/tests/VersionControlTest.php#L170:L179. It's in a PHPUnit test class so the syntax is a bit strange, but at least the last time I ran the tests this worked (though that was against PW 2.x.)

Hey @bernhard - not sure but this is how I do it in the Migrator module: https://github.com/adrianbj/ProcessMigrator/blob/eaf8255aded36033bcd468c59b235b9a0eb6b785/ProcessMigrator.module#L990 Not sure if "get" vs "install" works a little differently or not - been a while since I worked with this.

Sort of but not really. "Yesterday" we had options. I've never been a Windows nor Office user, for example. If Google takes over the web, then we will have no choice but to follow Google's rules.

I've not actually used Tracy yet... *everyone gasps* ...but I have often dreamed of a module installer that lets you browse via category from your PW installation itself. This way you get around the less intuitive copy-and-paste-the-module-name-to-install functionality as it exists today (it's not hard but other systems make it simpler) and it's also the ideal place to get "must-have" modules in front of people's eyes. For example, show a list of the categories on one side of the page, and on the other side have a list of the top-10 modules most people use, or maybe suggestions for different types of website even ("Top modules for starting your blog/news/magazine site", "top modules for starting your company website" etc etc and clicking on each shows you the list. I'd also suggest some of the Pro modules would make the list as well as several of them are must-haves for me. Edit: forgot to say that this is the way around it - making things like Tracy one click away after installing ProcessWire, and also getting the obligatory "use third-party modules at your own risk" warning in there whilst also not adding much more to the core.

The question is if the content is really the same. If it is, and the changes are just in the PHP templates, you could use PW's built-in multi-site support and (untested): Copy the PW installation to the second site's webroot Delete the "site/modules" directory and link it to the original site's modules directory Do the same for site/assets/files Do the same for the wire directory Delete the contents of the site/assets/cache and site/assets/sessions directories Edit site/config.php, set $config->sessionName to something unique from the first site (the default is "wire", so perhaps something like "wiresite2") and adapt $config->httpHosts to match your new site's hostname(s) All done. This assumes that both sites are hosted on the same server with the web server running as the same user. If that isn't the case, you will have to either adapt file system permissions, group memberships and umasks (same server, different users) or keep your own copies of wire, modules and files directories around and sync these from the first site (in that case, you best disallow admin access in the copy through .htaccess) If you want the copy to have some unique content, the task gets a bit harder, and you might have to use some kind of export/import mechanism or a feed like you wrote. But you could cover some unique content with individual templates that only have a matching PHP template on one of the sites, and there are ways to hook into Page::viewable and decide in PHP code (site/ready.php) whether certain pages can be viewed in the current site (e.g. if a page has an ancestor that hast the current hostname or a wildcard in a certain field).

Thanks, but as you say - it ought not to be necessary. Anyway, today it is working ?

@ryan - at the bottom of https://processwire.com/sites/submit/ you have link for "Powered by ProcessWire FormBuilder", but it links to a broken URL at: https://store.di.net/collections/software/products/processwire-form-builder

A couple of months ago we launched our very first PW site, which was just a very small site concerning a conference taking place in 2020. Last week we launched our second site, and it was a much bigger project - https://jobs.antarctica.gov.au/. Our jobs (both in Antarctica and within Australia) were previously a part of our main site at http://www.antarctica.gov.au (which is yet to be redesigned and moved into PW), so we were tasked with creating a brand new site in time for the recruitment season opening in early December. While the timeframe was tight (we only had about a month to build it), it was great to be able to work within PW, and then to introduce our editors to it. They love it in comparison to our old CMS (as do we!).

Just a note about fonts. Maybe we should consider fonts with the Cyrillic glyphs support? In the longer term, there probably maybe some messages on the forum or even parts of documentation translation in Ukrainian or Russian languages. Without Cyrillic glyphs, this parts will fallback to another font and it will look not consistent with other parts.

$this->addHookAfter('ProcessTemplate::buildEditForm', function ($event) { $form = $event->return; $template = $event->arguments[0]; $icon_field = $form->find('name=pageLabelIcon')->first(); $icon_field->collapsed = Inputfield::collapsedHidden; $field = $this->modules->get('InputfieldText'); $field->attr('id+name', 'template_emoji'); $field->icon = 'list-ol'; $field->attr('value', $template->template_emoji); $field->columnWidth = 100; $form->insertAfter($field, $icon_field); $event->return = $form; }); $this->addHookBefore('ProcessTemplate::executeSave', function ($event) { $template = $this->templates->get($this->input->post->id); $template->set('template_emoji', $this->input->post->template_emoji); }); $this->addHookAfter('ProcessPageListRender::getPageLabel', function ($event) { $page = $event->arguments('page'); $template = $page->template; if($template->template_emoji) { $event->return = $template->template_emoji . ' ' . $event->return; } });

Hi @Jonathan Lahijani, Thanks for work on this! I know your previous work and you make some great videos. I'd like to venture a few opinions if I may? For this sort of video, I think what would work best is an explainer video. Basically, a 'selling points' or 'attention grabber' sort of video. The segment should be between 40 seconds to 1 minute, tops! This is the sort of video you would make using Powtoon, Biteable or Spark. In other words, why should I use ProcessWire or what's unique about ProcessWire? This, IMHO, should be about the top-level /overarching selling points and not about the details. I think we should stick to 3, maximum 4 top selling points about ProcessWire. These can include: Easy-to-use and powerful API OR maybe consistent and powerful API? Security/Secure Custom fields Modularity Free and open source(?) > this maybe can be added as a one liner, even at the end of the video (and it's not really a unique selling point per se) An explainer video does not need to show off the full range of the power of ProcessWire. It just needs to grab the attention of the curious developer, to get a foot in the door, so to speak. Hence, the specific details, e.g. Matrix Fieldtype, procache, formbuilder, Github, etc, are for other (more) videos and are not ideal for 'an intro to ProcessWire' sort of video. In addition, ‘the going through the backend’, IMHO, should not be the focus of this video. These are for a ‘tour of the backend’ sort of video, which an explainer video, due to its length, cannot adequately cover since it will feel rushed and crammed. Ideally, the explainer video should be geared towards our target audience (which seems to be web developers), but this may be difficult to pull off. It’s best to try to fit text into one liners, rather than wrap-around texts, if possible. If the final website is going to change, and this video will show the website, you might want to hold off until then? Finally, I am not saying that it should be an animated video. I think the most important thing is that it should be simple, concise and clear but most of all, really 'sell me' to the idea of ProcessWire. Thanks.

I like it, just a few observations: the pw-intro-screenshots are in JPEG, (optimized) PNGs would look better imo (no artifacts) the home page feels a bit crowded for me, especially the 4x2 blocks like the "Web developers love PW" and the "Clients love PW" sections. Some whitespace could help. slide-in, fade-in, etc animations: perhaps a bit too much, I would at least turn them off after the first appearance (if there's a way). Eg. scrolling up and down causes these animations to re-run, making reading text blocks harder (because you need to wait them to fully load).

Don't want to be kind of a grinch but what about... cookie/privacy info banner cookie and privacy pages local embed of Google fonts no external CDNs GDPR statement (even as a feature) I know that pages and page-owners from the US aren't that much affected by laws like people from EU countries but setting up those trust(-worthy) pages like cookie policy and privacy pages could be a very good sign. Even something like an imprint page.

I second that

Overall looking great. Just a couple of quick things - I'll try to dig in deeper later. I think The API examples using a mix of $pages and pages() is confusing. I would stick to one approach The demo site should be running the latest stable which is currently isn't I'd like to see a Github link on the homepage or preferably the footer for all pages. I think it gives an open source project legitimacy and advertising this upfront can be an important thing for swaying someone to look around further. On the site directory, is there a reason for the category order? I think it's especially weird that "Newest Additions" is second. Speaking of the sites directory - are you running a regular check on all these site (using @teppo's isit.pw) to make sure they are still powered by PW - I think it looks really bad for PW if a listed site has been moved to another platform. The "What you'll love" page is so long. I saw the TOC links at the top and didn't initially realize that they scroll down on the current page. It seemed link too much to look at - where do I start? This page (http://processwire.com/newsite/about/requirements/) lists PHP 5.4, but this one (http://processwire.com/newsite/docs/start/install/new/) says 5.3.8 still. At the bottom of http://processwire.com/newsite/docs/start/install/new/ you state: "See our download page for additional download and installation options.", so I think it should link to http://processwire.com/newsite/download/core/, rather than http://processwire.com/newsite/download/ I think the master and dev download buttons on http://processwire.com/newsite/download/core/ should show the version numbers Afraid I don't really like the blog page - I feel like the blocks are too confusing - I'd rather a more normal vertical approach and an image (when available) to go with each summary. I was surprised that Page Reference fields are not listed here (http://processwire.com/newsite/docs/fields/). BTW - I think that all docs needs to use "Page Reference" rather than just "Page" because in PW "Page" is already used so much. BTW - thanks for the link to Tracy from http://processwire.com/newsite/docs/more/

If you're looking to do an elaborate a page builder with ProcessWire and don't want to pull your hair out, I highly recommended viewing this video: A couple notes: with the css grid specification, you can assign multiple blocks to the same grid-area but they will overlap each other. I've "overcome" this by combining multiple blocks into a parent div and assigning that instead. pretty easy to do. i didn't demonstrate it, if your blocks have a grid structure within them (like built with flexbox), you can still assign that block to a grid-area. so if your blocks themselves have a grid structure, that's ok. for example, if your css grid layout is 6 columns, but you have a block that has a grid inside of it (built with like uikit's grid that's 5 columns), you can assign that block to the grid-area. with the css grid specification, the flow of the blocks does not have to match the flow of the grid-areas. this is insanely powerful. Enjoy.

This is a shorthand function. So its easier to populate tags. /** * Perform a language translation replacing string tags. * * Used as an alternative to sprintf in language string that requires variables. * uses wirePopulateStringTags function for replacing tags. * * The $vars may also be an object, in which case values will be pulled as properties of the object. * * By default, tags are specified in the format: {first_name} where first_name is the name of the * variable to pull from $vars, '{' is the opening tag character, and '}' is the closing tag char. * * The tag parser can also handle subfields and OR tags, if $vars is an object that supports that. * For instance {products.title} is a subfield, and {first_name|title|name} is an OR tag. * * @param string $text Text for translation. * @param WireData|object|array $vars Object or associative array to pull replacement values from. * @param string $context Name of context * @param string $textdomain Textdomain for the text, may be class name, filename, or something made up by you. If omitted, a debug backtrace will attempt to determine automatically. * @param array $options Array of optional changes to default behavior, including: * - tagOpen: The required opening tag character(s), default is '{' * - tagClose: The optional closing tag character(s), default is '}' * - recursive: If replacement value contains tags, populate those too? Default=false. * - removeNullTags: If a tag resolves to a NULL, remove it? If false, tag will remain. Default=true. * - entityEncode: Entity encode the values pulled from $vars? Default=false. * - entityDecode: Entity decode the values pulled from $vars? Default=false. * @return string Translated text or original text if translation not available. * */ function _st($text, $vars, $context = null, $textdomain = null, array $options = array()) { return wirePopulateStringTags(__($text, $textdomain, $context), $vars, $options); } echo _st('There are {count} {items} in the {place}', ['count' => 5, 'items' => 'oranges', 'place' => 'tree']);

Place the below in your /site/config.php // Honour goes to Raymond Geerts for the idea ! $config->templates = array( 'dev.foobar.com' => 'devtemplate', // domain => templates folder name ); if (isset($_SERVER['HTTP_HOST']) && isset($config->templates[$_SERVER['HTTP_HOST']], $config->templates)) { foreach ($config->templates as $host => $folder) { if ($_SERVER['HTTP_HOST'] === $host) { // set new paths $config->urls->templates = "/site/" . $folder . "/"; $config->paths->templates = dirname(__DIR__) . $config->urls->templates; break; } } }