Robin S

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.

OT, but saveReady is one of those methods where before and after hooks are equivalent: https://processwire.com/api/hooks/#before_or_after @Zeka, the solution @kongondo linked to will work, but if you think PW should not be giving warnings for deliberate name changes that aren't related to a sibling name clash then maybe you could add your voice the GitHub issue? The fix that Ryan applied does not seem ideal and a solution (I gave a possible one in the original issue comment) that focuses more on the specific scenario of a sibling name clash would be better I think.

There seems to be a small issue with the new Page Files panel when there are no files on the page. The panel overflows showing a scrollbar. Looks like the panel footer markup isn't nested correctly so maybe an unclosed div tag?

Even if that did work, I'm hoping for something foolproof for clients because they will just tend to paste the URL straight from the address bar.

This part is fine (the very slight rounding isn't enough to make much of a difference). The problem is that the lat/lng coordinates in the URL do not match those shown in the blue box, and it's the ones in the URL that matter for the textformatter.

Hi @teppo, Would you consider updating this module to allow it to parse out degrees/minutes/seconds coordinates as an alternative to latitude and longitude? This is for the "Use coordinates?" option. The reason being that the lat/lng coordinates in a typical Google Maps URL that a person might embed are less accurate than the degrees/minutes/seconds coordinates that are also present in the URL. I have no idea why this is and it seems strange as lat/lng is capable of achieving the same accuracy in principle, but I've tested several maps and there seems to be a real difference. Here's an example... I'll start with a Plus code so as not to involve either lat/lng or degrees/minutes/seconds to begin with: H85C+MG Otatara, Southland, New Zealand A search for this Plus code results in the following URL: https://www.google.com/maps/place/46°26'26.9"S+168°19'16.7"E/@-46.4408088,168.3191238,17z/data=!3m1!4b1!4m5!3m4!1s0x0:0x0!8m2!3d-46.4408125!4d168.3213125 The marker is at the end of the road, at the edge of the green reserve area: But when I embed the map via TextformatterGoogleMap with the "Use coordinates" option checked the marker position is out by a significant distance: This is not the module's fault - the lat/lng coordinates that Google puts in the URL are simply not accurate. If I search the coordinates -46.4408088,168.3191238 directly the pin is similarly misplaced: A search for the degrees/minutes/seconds coordinates 46°26'26.9"S 168°19'16.7"E from the URL results in a correct marker placement: So seeing as the degrees/minutes/seconds coordinates are more accurate could the module provide an option to use those?

If you have inserted any variations into CKEditor fields it would pay to check those because they won't be automatically recreated when the page is loaded. You'd need to call the image sizer again with needed dimensions, either using the CKEditor image modal or via the API.

Both FieldtypePageTable and ProcessPageClone belong to the core, so if the issue is consistently reproducible you could add it to the ProcessWire issues repo: https://github.com/processwire/processwire-issues/issues

Seems like we're talking about a couple of different things here: 1. Making certain "things" (don't think I can be more specific than that) reusable in multiple projects that you work on now and in the future. These are for in-house use by a single developer or team of developers and not shared publicly with the PW community (in the modules directory for instance). You could try and use modules for this purpose (I think this is what @bernhard is interested in) or any number of other approaches. This is stuff that's very much down to individual workflow preferences and I don't think the PW core can provide easy solutions that are going to suit everyone. 2. Modules that are shared publicly with the PW community. This is totally a matter of opinion, but personally I'm not enthusiastic about things like sliders and blogs being packaged and distributed as modules. In seems very WordPressy and not really the PW way (teach a man to fish, etc). A module could provide some building block that is useful for making a slider or a blog but it shouldn't do things like try and anticipate all the fields a user needs, output all the markup, bundle third-party JS libraries and suchlike. The beauty of PW is that it's so quick and easy to build solutions that are exactly tailored to the project at hand with nothing unnecessary left lying around. And while developing these solutions you're always learning how to be a better developer. A plug-and-play module that outputs whole pieces of the website works against that IMHO.

That's a special case because it's a module that is all about PW fields, templates and pages - indeed anything in the PW API. Generally speaking, if your publicly-shared module needs to collect and store some data then fields/templates/pages is not the way to go. It's messy, it's not self-contained, and it's liable to cause a headache for uninstalling and upgrading (what if a user adds or removes fields from your module templates?).

Sometimes a module does need to create fields, templates and pages but it would be the exception rather than the rule. Most Process modules, even complex ones with multiple (pseudo) sub-pages such as Admin Actions, do not create fields, templates or pages other than the single page used to execute the Process. Instead they use multiple execute() methods that work via URL segments. The forms on those pseudo sub-pages don't save data to PW fields but save all the module-related data to the module's config (stored as JSON in a single field in the database). The "nav" array in the module info takes care of creating the navigation to sub-pages. But perhaps you already know this if you've studied ProcessHello and other Process modules. Some off-the-top-of-my-head cases where you probably would need real fields/templates/pages for a module: You want to store files or images for use with the module. You want to use a Repeater and don't want the extra work to create to repeatable input type in the Process module. You want to store a larger amount of data than is allowed for in the TEXT column type used for module config data (although alternatively your module could create a dedicated table to store its data).

If all your variations (thumbnails and other variations) are corrupt you can delete them with the Pageimage Remove Variations module. The variations will be recreated next time they are requested.

There is no method call on the repeater matrix field value there - I think you meant to include ->find(): $items = $page->matrix_slider->find('start=1,limit=3'); That should work.

You can render the comments list and comment form for another page by calling render() and renderForm() on the value of the comments field of that other page. For example: // Get the page $p = $pages(1234); // Render comments list echo $p->comments->render(); // Render comment form echo $p->comments->renderForm(); If you have the "Redirect after comment post?" option checked then the user will be redirected to the page being commented on after the form is submitted. You probably don't want that so you could adjust the value of the hidden page_id field in the comment form. Unfortunately there's not much that's hookable in the FieldtypeComments module so you'd have to do this by editing CommentForm.php (first copy the FieldtypeComments module to /site/modules/) or use Javascript to change the field value. Alternatively you could disable the built-in redirect option and handle redirection after form submission via your own code.

Have a look at the Connect Page Fields module. This will let you simultaneously add conferences to speakers when you add speakers to conferences. You can also get pages that reference a page via the API with $page->references() since PW 3.0.107.

Good ol' ProcessWire - there's always a way! // Get the page to render $p = $pages(1234); // Set a page number $input->setPageNum(2); // Set a URL segment $input->setUrlSegment(1, 'my-segment'); // Set a GET variable $input->get->foo = 'bar'; // Render the page echo $p->render();

If I have a template "news_items" that has page numbers enabled and that lists child pages ("news_item") with a limit of 20 news items per page, is there a way I can use $page->render() to render the page with a page number other than 1? For example, what if I want to render page 2 showing news items 21-40? It seems like it ought to be possible to do this but I can't work out how. And similarly, is it possible to render a page with a particular URL segment or a particular GET variable?

Have you tried Fields > Manage Tags > [your tag] > Display as collapsed in fields list?