Leaderboard

Hi Ryan, With the addition of the new profile, in terms of file size nearly 60% of the core is now made up of site profiles. For new users these profiles are no doubt very handy, but I think for a lot of existing users the profiles (apart from "blank") are not needed. Speaking for myself I don't have a need for the bundled profiles and so delete them each time after downloading a new version from GitHub. Doing that isn't a big deal, but it would be nice to keep things as lean as possible for users who don't need the profiles. And I'm not sure but are the profiles downloaded and discarded each time PW is upgraded via admin? What do you think about starting to make use of the Releases feature of GitHub? Each time when a new version is ready there could be a new release created, containing two zips: "processwire" and "processwire-no-profiles", or whatever naming scheme you think best. Using releases would have some other benefits too. For dev branch users it would be easier to know exactly what version of PW you are running, as opposed to the current scenario where changes to the latest version get pushed out over the week so someone who installs 3.0.105 on Saturday may have different files to someone who installs 3.0.105 on Thursday. When someone raises a problem in the forum they could say exactly what version they are running (could be an older release) and people who want to help could more easily download that exact release to try and replicate the problem. Another benefit to using releases is that you can collect metadata about downloads. That would be a great way to track the growing interest in PW over time. https://help.github.com/articles/getting-the-download-count-for-your-releases/

I think the Connect Page Fields module will be suitable for this. You would create two new Page Reference fields for your Skyscraper template: interior_photos and exterior_photos. The visibility of these fields could be set to hidden if you don't want to see them in Page Edit. Then you would connect those fields to the corresponding fields on the Photo template. In terms of matching skyscrapers with or without interior or exterior photos you would then match against the count of the Page Reference field rather than a boolean.

Wow, that works incredibly well for this usage! You are very creative, I never would have thought to use a similar plugin for such usage. It even works flawlessly with a multi chosen page reference field. You can have multiple pages of exterior photos and the each page will successfully pop into the field. It even solves the problem of what happens when photos are removed - they are automatically removed from this select field, so if all photos of a skyscraper are removed, it successfully has a photo count of zero. Bravo.

Fieldtype Page IDs is a third party Fieldtype that, simply put, stores Page references as integers (Page IDs). This fieldtype was built as a quick and dirty workaround for Page Reference fields' inability handle self-references due to circular reference issues. A project I've been working on for a while now includes a combination of RepeaterMatrix content blocks and tagging/categorization system that would've resulted in a lot of duplicate pages (and plenty of unnecessary manual work for content editors) had I used built-in Page Reference fields, and thus a new Fieldtype felt like the most sensible approach. Fieldtype Page IDs was designed to be loosely compatible with Page References in order to make conversions between the two feasible, but it is quite limited feature wise: largely due to the fact that stored values are actually just integers with no connection to Pages whatsoever some advanced selectors and related features are not supported, and page values can't be directly accessed configuration settings are limited to the bare essentials (selector string and Inputfield class) only a handful of Inputfields (AsmSelect, Checkboxes, Text) are (currently) supported Anyway, in case you need to store Page IDs (and Page IDs only) and are happy with the limitations mentioned above, feel free to give this Fieldtype a try. It has been working fine for me in one particular project, but hasn't been tested that much, so please tread carefully – and let me know if you run into any issues. GitHub repository: https://github.com/teppokoivula/FieldtypePageIDs Modules directory: https://modules.processwire.com/modules/fieldtype-page-ids/

What happens if you extend FieldtypeMulti instead of Fieldtype in FildtypeMapRoom?

This latest version on the dev branch adds a new site profile to the core, adds useful new functions to our $mail API variable, and makes significant enhancements to our $sanitizer API variable: https://processwire.com/blog/posts/processwire-3.0.105-core-updates/

That's a great idea, thanks for the reminder, I'll add soon.

I would put Tracy in Strict Mode (you can toggle this via the button in the Panel Selector). This way you'll get the Tracy "bluescreen" which will show you a full stack trace so you can figure out what line in your module is causing the problem, rather than the final WireDatabasePDO.php as reported in the warning. The warning is clear that you are providing an array instead of a string, but this will help you figure out where this is happening.

Speaking of deleting pages, what do you think about the idea I raised a while back... Sometimes when testing you want to permanently delete a page after you have created or edited it, so it would be handy to be able to do that from the Delete tab rather than going back to the tree. Instead of another checkbox inside the "Move to Trash" inputfield like I showed in my earlier suggestion (I don't think it's even possible to do that with the forms API) it would be better to have a separate "Delete permanently" inputfield added to the Delete tab.

Hello @adrian is it possible to disable the input field length fe style="width:60px;" by entering something into the settings field? If not, it would be great if you add the possibility to enter fe a "-" to disable the rendering of the style attribute. This could be useful if you are using the UIKit template because there are various input length classes ('uk-form-width-medium'....) and you dont need the input field length. Best regards Jürgen

I'm old school in this regard, but I install all the bits I need via homebrew. Here is a pretty nice guide to getting things up and running: https://getgrav.org/blog/macos-sierra-apache-mysql-vhost-apc

Checkout https://github.com/cytopia/devilbox

I always do this: What grinds my gears is when hamburger menus are the only option on desktop sites (just for the sake of looking fancy), so I gotta click on it just to show the available options before I can choose something.

It cannot hurt for sure (that is why I also put it there whenever I can) but on small mobile viewports it might be problematic to also use the word "menu", however if the hamburger menu is prominent then people will find and use it as they have gotten used to it by now. Sure, there are alternatives but I do not think the hamburger icon is that bad and the alternatives are not better either. It just depends on the design context what works best. It is funny that in the "5 smart alternatives to the hamburger menu" article the hamburger icons are still used.

The last time someone said "The hamburger menu doesn’t work" we tested onpage CTR and... almost no difference at all. It's by far not the best solution but people know it for a long time now. They see it regularly and can handle it. The article was first written in 2015 (according to the WP image path) and therefore things have changed since then. Remember all the "people don't read online!" or "people don't scoll!" statements.

I don't really agree with the article. Perhaps that was true back then but nowadays people are used to it (or perhaps I'm too much of a designer :)). According to that logic the eg. the search icon (magnifying glass) could be on a ban list.

The ProcessDashboards module which is the latest iteration of this is back to being a simple helper module, close to the original Dashboard module by @Pete, but with some additional features, and that the module no longer changes anything in the admin, meaning that it doesn't auto-change the admin page to use the process; instead you create one or more dashboards, and input the path to a php file to render the dashboard; if you want to use one of them as the admin home screen, then you just change that admin page's process to use this module (ProcessDashboards). Since making dashboards is fundamentally creating markup, it is better to keep all of the files for the dashboard in the templates folder. Also, if there were to be any dashboard module that output markup, it could become difficult to support multiple admin themes. Users of UIKit theme could build a simple dashboard using all native UIKit markup and not have to include a css framework (as i have done for the examples, which run inside the reno theme). Since this type of setup is not really suitable for a standalone module, or a site profile, i see it more as a construction kit. You need the base module; if you want to use the shortcuts and widgets functionality, there is another module that installs all of the fields & templates for that setup; You need the files that generate the dashboard(s) and the widgets that go in the templates folder, including css/js, libraries, widget partials, and functions. Hopefully this can all be on GitHub soon, once i sort out some issues with my current dev computer (old os no longer being able to connect to github)...

I think the problem is that you need to foreach all the instruments, not just the ones in the user's instrument field. Probably something like this: foreach ($pages->get("/instruments/")->children() as $instr){ $person = $users->find('instrument='.$instr);

Hi, try this. $person = $users->find('instrument=' . $instr); or $person = $users->find("instrument=$instr"); // or $person = $users->find("instrument={$instr}"); Variables inside single quote is just text / string. With double quotes php parses variables.

$person = $users->find("instrument=$instr"); or: $person = $users->find('instrument='.$instr); Variables won't be parsed inside single quotes!

Do you allow one or multiple references? If multiple, then do this: $page->ref_page->first()->title; or then foreach then. If only one is allowed, then set it single page object from field settings and earlier example should work.