Mike Rockett

Thanks, but that would mean multiple scripts where there are multiple fields that use Typographer. I'd like to keep it clean, where the scripts are appended at the end of the rendered page. Now that you mentioned it though, using formatValue would actually add the hook more than once anyway (when a page contains multiple fields in use). So perhaps I'd need a hook that runs on page render and checks the page for fields that use Typographer. Also might be best to have a separate module for that to avoid autoloading the textformatter.

Awesome - will have a look-see now. I'm sure I can whip something up.

With Typographer, I need to be able to inject a script into a page but only if that page has a field that has the Typographer formatter applied to it. The module needs to apply the hook if two conditions are met. The issue is that the hook is indeed added, but it is never called. The only thing I can think of is that it might be too late to add the hook. Here's how I'm doing it: /** * Textformatter formatValue (Typographer handler) * @param Page $page * @param Field $field * @param string &$value * @return void */ public function formatValue(Page $page, Field $field, &$value) { // ... vendor stuff // Run Typographer and return the converted input. $value = $this->typographer($value); // If configured, add the clipboard-cleaning script if ($this->cleanClipboard && !empty($this->hyphenationLanguage)) { $page->addHookAfter('render', new CleanClipboardHook()); // $this->dd($page->getHooks()); // ^^ this dumps the hooks so we can see that our new hook is there (see below) } } And here's the hook data from the dd call above (collapsed for post-brevity): I've tried using a both a normal class-method (..., $this, 'hook') and a closure instead of the self-invoking hook class, but it's the same result. Have also toyed around with priority, but to no avail. Is there perhaps a better way to handle this? Or I am missing something incredibly small and simple here?

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?