Robin S

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.

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.