Robin S

@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?

@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.

Just want to check: did you click the link in the forum email notification or the link that is in the (current) post? I did update the link shortly after I submitted my post. As far as I can see the link that @adrian suggested is the same as the link that is in my post, which should be working. Please let me know if not, thanks.

It's not fully clear to me what you're asking, but you can use find() to get individual Selector objects from a Selectors object by both field and value.

I never noticed before that field access restrictions depend on output formatting. I guess that would be a good way to turn off the access restrictions on a per page or even per field basis. You're right that output formatting is mentioned in the "Access toggles" field notes but it's a bit subtle and not really emphasised that field access restrictions don't work when output formatting is off. Definitely something to watch out for as it's not intuitive that these things would be connected and I can imagine situations where people could be caught out by this, accidentally revealing data that they thought was restricted.

Are you sure that revoking the permissions for other templates has an effect? I can't reproduce that at my end - it's all or nothing for the Export CSV action. In other words, if I revoke the permission from the basic_page template for a role and then list some basic_page pages in Lister then a user with that role can still export the CSV of those pages. So that makes me think Lister actions are an all templates or no templates affair. Ryan could probably clarify this in the Lister Pro subforum but I no longer have access to that (expired subscription).

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&css=https%3A%2F%2Fsitemod.robin.nz%2Fnew-pw%2Fmod-1.css

Yes, there are many browser extensions that will let you do this, but we want something that can be shared and viewed easily by others via a link. Sounds perfect, will check it out. Update: I made my own tool...

Hey, does anyone know a web service that will load a website in an iframe or similar wrapper with custom CSS applied? So that the community can try out some alternative styling ideas for the new website design and share them here in a way that others can see directly in their browser rather than as static screenshots. I'm sure there used to be some tools that did this but after looking I can't find any working ones. The two I did find are only for font changes, and both seem to be broken for me: Typewonder - very basic (cannot target different fonts for headings or using custom selector), share function seems to be broken. http://typewonder.com/home Webfonter - only for FontShop fonts, also seems to be broken (font thumbnails fail to load and fonts do not update). http://webfonter.fontshop.com/ Anyone know of something better, ideally that will add any kind of custom CSS and not just font-face changes?

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:

There is this option on the Access tab of the restricted fields: The Dumps Recorder panel can be useful in such cases: https://adrianbj.github.io/TracyDebugger/#/debug-bar?id=dumps-recorder

Not totally sure about this, but I think for Lister actions you can't selectively enable them for some templates and not others (or rather you can but it doesn't have any restricting effect). That's because the actions apply to all the pages shown in the Lister which could use any template. So you would either enable it for all templates or no templates by editing the role: And did you do the step of allowing the action for the Lister instance? You'd need to also save the role: $role->save(); But maybe you already did that?

I'm not sure about the cause of the problem but I know a good way to get closer to the solution: install Tracy Debugger and barDump the problem variables. bd($os->paymentAmount, '$os->paymentAmount'); My golden rule is: any time something isn't working the way you expect it to, or you don't understand how something is working, or you're just plain curious, then start dumping variables/properties/objects left, right and centre. Best way to advance your knowledge IMHO.

I'm not totally clear about what you're asking, but when it comes to accessing an image URL in a browser then this happens directly without PW getting involved. So if you use (or send someone) a URL to an image stored in a PW field... http://yourwebsite.com/site/assets/files/1234/some-image.jpg ...or an image not uploaded to a PW field... http://yourwebsite.com/site/templates/images/some-image.jpg ...or even outside the PW folder structure... http://yourwebsite.com/some-folder/some-image.jpg ...then PHP and PW are not involved in serving that image. Well, strictly speaking the rules in the PW .htaccess can be involved but no need to worry about that at this point. For images uploaded to a PW field you can get their URL via the API ($some_pageimage->url) or you can deduce the URL via the admin: But when it comes to things like logo images for use in an email signature I would tend not to store those in a PW field because you want them to be available at the URL for years to come and there's less chance of accidentally deleting the image or affecting its URL if you store it outside of a PW field.

I understand that you are exaggerating for effect, but your analogy is wrong in several ways. 1. Apart from in kidnapping scenarios, nobody is ever "put" into a helicopter. Rather a person chooses to get into a helicopter. And if an person chooses to get into the pilot's seat and start pushing buttons and pulling levers then it's their own responsibility to handle the consequences. 2. A company that manufactures helicopters usually does not teach people how to fly helicopters. Likewise a company that manufactures hammers usually does not include a brochure explaining how to build a house. It's not really the responsibility of the manufacturer to deliver comprehensive instruction to every person who might come in contact with their tool. Rather (as per point 1) the responsibility rests with the individual choosing to use the tool to pursue their own learning from any sources that might be available. 3. Despite there being no obligation on the manufacturer to produce it, the helicopter we're talking about does in fact come with loads of detailed mechanical documentation, written and video tutorials, demo helicopters that you can take apart to learn from, and a helpful community of pilots and engineers ready to answer questions. So it's not really true that there's only a small brochure that leaves most things undocumented - quite the contrary. It seems that your complaint is that you've found some small behind-the-scenes component (maybe a heated pilot seat that is more of an optional thing than a critical feature necessary for every flight) that is not explained in a way you can understand. 4. Now let's bring into the picture the fact that we're talking about a helicopter that is made available for free. The "company" that has produced this helicopter is actually just a small number of generous people who, after having finished their day jobs, put in unpaid hours to offer helicopters to the world at no cost simply because they want to share the miracle of flight. If after their day jobs and the unpaid time in the helicopter factory there aren't enough hours left in the day for those generous people to also open up a helicopter pilot training academy then I don't think we have much reason to complain about that. 5. The company that produces this helicopter operates on the collaborative open-source model. That means there's an open invitation for anyone who sees potential in the product to participate in adding further value to it. So if you, as an aspiring helicopter pilot, can see that it would be useful for other pilots to have some documentation on the heated pilot seat then you would be very welcome to write up a document and submit it to the CEO. I'm sure he'd be delighted to receive it.

It adds the following two options to the settings of Page Reference fields:

The best way to allow for editors to add options is to use a Page Reference field instead of a Select Options field. Page Reference fields are much more flexible than Select Options fields and are the better choice in all but the most simple scenarios. I like to create the option pages for my Page Reference fields under a parent called "Selects" at the top level of the tree. If you configure the allowed parent and child template settings for the parent and option templates (e.g. colours and colour in the screenshot above) then it's really easy for your editors to add new option pages. Some useful modules to check out: Page Field Select Creator - handy to quickly set up a Page Reference field and its options Page Field Edit Links - allows editors to create new option pages directly from the field (or you can use the similar but more basic core feature for some Page Reference inputfield types)

A few more CMS marketing pages that I thought were effective... https://www.silverstripe.org/ - I see SilverStripe as being quite similar to PW in terms of target market (or what I think the PW target market should be). If I wasn't in love with PW I'd probably be using SilverStripe, partly because of the New Zealand connection. https://dotcms.com/ - good use of a video https://prismic.io/ - simple with plenty of whitespace https://ghost.org/features/ - their Home page is weak but I like this Features page https://craftcms.com/ - the focus on custom design and development ("design and build exactly what you need") is similar to what we should do with processwire.com

Welcome @gregg, Flydev is right that upgrading your PHP will solve the issue, but what you've raised does count as a bug because the minimum PHP version required for ProcessWire is 5.3.8: http://processwire.com/about/requirements/ I opened a GitHub issue here: https://github.com/processwire/processwire-issues/issues/777

Thanks for the detailed reply Ryan. That's a good point. We'll have a much clearer impression of the new site when we can see it rendered in our browsers. This is a very broad audience. When the market for a product is large (e.g. the car market), usually some market segmentation goes on so that you don't have every provider trying to reach the entirety of the audience. So instead of targeting all car buyers in the broadest way ("It has four wheels!", "It can transport you from A to B!") manufacturers tailor the product and its marketing towards the interests of a narrower group within the audience ("Lowest particulate emissions of any mid-size van!", "Traverse any terrain with huge 283mm ground clearance!"). But having said that and having now looked at the marketing of many CMS products it seems that few providers in the CMS space aim for a narrower market segment. This surprises me because there are many... Different kinds of web-delivered content (single landing page, small brochure site, huge corporate documents database, Ajax-driven SPA, the list is endless) Different levels of custom development (from off-the-shelf WP themes to fully custom design and coding) Different divisions of responsibility between client and professional (client cannot design anything and strictly manages content only versus client virtually designs the site themselves via the backend) Different preferences for templating (via templating language such as Twig versus pure PHP) Different levels of coding competency (experienced developer proficient in many programming languages versus newbie, or person who thinks website equals Squarespace - which is not a rare thing given the saturation marketing of that provider) Different relationships with the finished website (this is my own website and I enjoy tinkering with it, versus I am a professional and I need to get the job done because time is money, etc) I could go on... Maybe we don't want to narrow down our audience much, but I think we should at least be mindful of people who PW is not going to suit: People who want an off-the-shelf theme already integrated with a CMS product (we have few available themes/profiles I can't see PW seriously competing in this space). People who have little to no PHP experience. So I think there should be strong emphasis on the suitability of PW for custom design and development. And there should be some code shown on the PW home page ? (if that scares away anyone then PW was never going to be a good fit for them). The best CMS home page I came across in my search is for Wagtail: https://wagtail.io/ Not saying its styling is perfect (for one thing I'd say go for a fixed max-width rather than a fully fluid layout) but I like several aspects of it: Many short, punchy value statements It's a fairly long home page that highlights many aspects of the CMS but is not excessively wordy I really like the tabbed interface showing off the top four features It doesn't shy away from showing some code front-and-centre It speaks to different audience segments in the "You'll all love it" section

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?

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 @matjazp, fixed in v0.1.9.

Hi @tarkvsg, welcome to the PW forums. It works because the comparison uses the == "equal to" and not the === "identical to" operator. The PHP manual explains that == means "TRUE if $a is equal to $b after type juggling". In the case of the comparison... $event->object->hasField == 'FIELDNAME' ...'FIELDNAME' is a string so a comparison is made to the string value of $event->object->hasField. And the string value of a Field object is the field's name. See the __toString() method of the Field class here: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/Field.php#L1097-L1103

Wow, it's awesome when you see all the new features in a list like that. It really brings it home how active the development of PW is. What if we had a dedicated page on the new processwire.com for recording the history of added features? Not a changelog - which would be nice but I expect would be time-consuming to maintain and duplicate information that is already available in the GitHub commit history. But something more high-profile and permanent than a blog post, so people who are just discovering the PW website for the first time can be made aware of the speed at which PW is developed. I know from experience with some other content management systems that PW blows many competitors out of the water when it comes to the frequency that new features are rolled out, and it would be great to highlight that.