Mike Rockett

Thanks Steve. Certainly a great idea and worth discussing. Having had a look, I'd suggest that the Github API be used instead. This way, the release notes link can use a modal window to display the changelog. In my case, the body tag from the JSON response could be inserted. Not sure if the APIs for Bitbucket and Gitlab are easily accessible like Github's, but it's worth a shot.

Have been using Tracy for a while now, and recently got to thinking: would it be possible to override the exception template with something more PW friendly? Not a fan of the design at all as the red is just too much, and the exception heading text is just too big... Thoughts?

Sure, though module developers would need to be aware, in the same context as a standardised format, that proper release notes should go in there. It's a good idea.

Thanks - I'm moving closer to a standardised approach. Deciding on whether to bump versions in a separate commit or not... Guess that really depends on what I'm doing, but most of the time the aim is to have one commit per release as there is no dev branch. (I might land up moving all my modules over to fetching from a release tag instead of master. I don't like the concept of multiple branches for dev/master, in the ProcessWire context. that is.) Indeed - this has been brought up before, and I do like the idea. However, we'd need a standardised changelog format to include in our repositories. It could also be managed in a JSON fashion: { "changelog": { "1.0.0": [ "Log 1", "Log 2", "Log 3", "etc.", ], "0.9.9": [array] } }

Surely this should be in the form-builder forum?

Bumped to 0.4.0 Beta

Bumped to 0.3.0 - now using the Composer package, as above. There don't appear to be any breaking changes, other that the fact that the Settings class is now a separate entity. Also note that I'm keeping this in alpha for the simple reason that things may change. I don't expect to break anything, but would like to re-work the configuration class a little, add a few more features, and then bump to stable 1.0.0.

$list = $db->pages->posts->where('title.length>5')->fetch(['title', 'name', 'body']); I do like this, interestingly enough. Looks very fluid, and there's a fetch command in there too, which does save memory, yes?

Okay, landed up using a custom style set, and realised that one needs to actually click on the "ul" tag in the status bar in order to correctly select the list and apply the style.

Is there no way one can add styles to the default list? I'm trying to add a style for unordered lists, and the Styles list just shows up with the defaults only... In /site/modules/InputfieldCKEditor/config-content.js (content field): CKEDITOR.stylesSet.add('default', [{ name: 'Ticked List', element: 'ul', attributes: { 'class': 'light-emphases', }, }]);

You're welcome! Hope it goes well.

I'd be inclined to use Menu Builder in that case, in terms of seperation of your menus, if that's what this is about. To me, I feel that setting page visibility just for the purposes of menus is a tad overkill (keep in mind that I've never had to hide a page from lists and searches before). That said, your structure could be very specific, and I may be missing something here...

Fair point, though Ii'm specifically speaking within the context of learning PHP in general. In most common cases, PHP 7.1 is no different to the others.

Have been using the nightlies for a little while now and, yes, it's a much better browser. Firefox is evolving really quickly. One of my only nitty-gritty's is the text-rendering engine. Seems too native, and I've come to love the way DirectWrite does things - much smoother. The new chrome (as in the Quantum window controls) is much better as well. Finally, e10s is built right in, and everything is much snappier.

I'd probably need to include a selector-toggle for that - perhaps a simple option in the module's configuration that allows for the inclusion of hidden pages. With that said, I do discourage it. If a page is meant to be hidden, then it shouldn't be shown, no? What exactly are you hiding your pages from?

As a general recommendation, its best to work with the newer versions, which are 7.0 and 7.1. You could also use 5.6, which still has security support until end-2018. PHP 5.2 is no longer supported by the maintainers of PHP (it's really old now).

After my few years here, I'd never actually seen that tutorial by Joss, but was going to bring up his name when I saw this thread. In ProcessWire, the front end of your site is completely up to you. One of the things that does make WordPress appear simple is the availability of themes. The concept of themes is fine from one angle, but the implementation makes it difficult for novice users and non-coders, especially when you need to do complex work. This is where PW comes in. By not providing a theme framework, it gives you an opportunity to start from scratch and learn the basic easily, because every single aspect of the front end is up to you, and you're also aided by modules where the need arises. And, as has been pointed out, it's super-simple to get started with a basic site. The API is as simple and easy to grasp as they come. With that in mind, ProcessWire sites can be whipped up much faster than a WordPress equivalent and that's just the beginning.

Menu Builder doesn't support that out of the box, and so you'll need to use getMenuItems(), which allows you to build your menu the way you want it. Here are some gists that could guide you for your menu.

I'm no expert either, but I feel the calls made to search for menu pages in MarkupMenuBuilder.module:142-144 are a bit much... On my side, changing it to the following fixes the issue, but I honestly don't know if it breaks anything else... $menuName = $this->wire('sanitizer')->pageName($menu); $menu = $this->wire('pages')->get("name=$menuName, template=menus, parent.name=menu-builder, check_access=0");

Works flawlessly by the way. I haven't perused the source yet, but would it be possible for you to make reference by name/title work, considering that it doesn't change on a per-language basis?

I'm busy with a multi-lingual site for a client, and this feature doesn't appear to work on my end - I'm getting the error "No menu items found" when switching to the only non-default language. My menu, called footerNavLeft, is set to use French, and the language tabs are being added to the menu builder (and inheriting default values as expected). When opening the site in English (default language), all is fine. The moment I switch to French, it goves the above-mentioned error. I'm rendering the menu to my view like this: $menus = wire('modules')->MarkupMenuBuilder; $view->menuFooterNavLeft = $menus->render('footerNavLeft', [ 'menu_css_class' => 'menu', ]); --- Edit: Apologies - missed the instructions (which aren't clear in the post quoted above). Using a Page ID works. Though, I hve to ask: why isn't it possible to use a menu name/title in a multi-lingual environment?

Just pushed RC2 - was not checking the PW version properly (it requires either 2.8.16 or 3.0.16 to run). Speaking of PW versioning: Not sure if this has been brought up before (please point me to it if it has), but how will the legacy version be bumped when we reach PW 3.1? Would be unwise to make it 2.9 because, when we reach 3.2, legacy would logically need to be 3.0. Perhaps there are plans to drop legacy?

Typographer will be getting an update soon. Functionally, everything should stay the same. PHP Typography is now available on Composer, and so I'd like to make use of it that way, considering its dependencies are also loaded in via Composer. Haven't actually reviewed for any breaking changes in PHP Typography, but I don't think there would be many, if any at all...Once done, I think it'll be safe for me to bump to stable.

Libs updated, bumped to 1.0.0 stable.

Bumped to 0.3.1 Beta - RC1: Corrects PW version check Ignore options when not set by template Fix instanceof Pageimage references This is a new release candidate. Please test. https://github.com/rockettpw/markup-sitemap/