ryan

Pete this is incredibly well done and beautifully put together–nice job!

Sorry about that, I went back and forth on the name a couple times and ultimately entered the wrong class name in the modules directory. It should have been TextformatterHannaCode, not ProcessHannaCode. I have corrected that. I was throwing an exception when I shouldn't have. I'm pushing a correction for this. Technically they are part of the same program "Hanna Code", even if that program has two modules. But I know what you mean. I'm adding "(Process)" to the Process one, just so that the two next to each other can be differentiated. Also, one more section I just added to the README: Using Hanna Code from the API If you want to populate Hanna Code from the API, you can do so using the render() method, like this: $hanna = $modules->get('TextformatterHannaCode'); $page->body = $hanna->render($page->body);

Easily insert any complex HTML, Javascript or PHP output in your ProcessWire content by creating your own Hanna code tags. This module is based loosely on the WordPress Hana Code Insert plugin. A Hanna code tag looks like [[hello_world]]. A Hanna code tag with attributes looks like [[hello_world foo=bar" bar="foo]] using HTML style attributes or [[hello_world foo=bar, bar=foo]] using ProcessWire selector style attributes. After installing the module, you define your Hanna codes in Setup > Hanna Code. These Hanna codes that you define can then be entered within your body copy (or other text where you allow) and they will be replaced with the values defined or generated by your Hanna code. A common use case is to embed scripts or other bits of HTML or codes that would usually be stripped out by an editor like TinyMCE. However, Hanna codes can be more than just static snippets--they can be dynamic PHP or Javascript that outputs different things according to the request. PHP-based Hanna codes have access to the entire ProcessWire API. Hanna code accepts named attributes in the tag that can be passed as variables to PHP and Javascript Hanna codes. These attributes can be specified either in HTML attribute format or ProcessWire selector format. In either case, quotes should be used around the attribute value when the value contains whitespace or a comma. How to install Place the module files in /site/modules/TextformatterHannaCode/ In your admin, click Modules > Check for new modules Click install for TextformatterHannaCode Now to go Setup > Fields and locate the Textarea field(s) that you want to use Hanna codes with ("body" for instance). When editing the field, click the details tab, and select "Hanna Code" as the Textformatter. Save. Now go to Setup > Hanna Code and start defining your Hanna Codes! You may want to use one of the examples from this document to get started. Tag format Below is a Hanna code tag named hello_world with no attributes. If you pasted this into your body copy, you would get whatever the replacement value is that you defined. [[hello_world]] Below is a Hanna code tag named hello_world being passed attributes of foo, bar and foobar. If this were a PHP-based Hanna code, it would receive the variables $foo, $bar and $foobar: [[hello_world foo="bar" bar="foo" foobar="foo bar"]] Below is the same Hanna code tag as above, but with attributes more like ProcessWire selectors. You can use whatever format you prefer. Just note that unlike regular ProcessWire selectors, quotes (single or double) are required around any value that has whitespace. [[hello_world, foo=bar, bar=foo, foobar="foo bar"]] How to use Please make sure that you have completed the How to install section first. Then in your admin, go to Setup > Hanna Codes. Each Hanna code that you add has a type of either: Text/HTML, Javascript or PHP. The Text/HTML type is literally self explanatory in that your [[custom-tag]] is replaced with exactly the text you paste in. Anywhere that you type your [[custom-tag]] in your body copy will be replaced with exactly the static text you defined. More power opens up with the Javascript and/or PHP types of codes. These codes execute at runtime and thus can contain specific logic to produce different results. In fact, PHP Hanna codes have access to the entire ProcessWire API and are executed in the same manner as template files. Your PHP-based Hanna code should simply "echo" or "print" the replacement value. PHP example Create a new Hanna code with the name "children". Select "PHP" as the type. Paste in the following for the code: foreach($page->children as $child) { echo "<p><a href='$child->url'>$child->title</a>"; } Now go and edit a page that has children. In the body copy, enter [[children]] in the place where you want the output to appear. View the page, and you should see the rendered list of links to children. PHP example, part 2 Now lets take the above example further... Go back and edit your "children" Hanna code, as we are going to modify it to respond to a "parent" attribute. Change the code to this: if(isset($parent)) { // If $parent is an ID or path, lets convert it to a Page $parent = $pages->get($parent); } else { // otherwise lets assume the current page is the parent $parent = $page; } foreach($parent->children as $child) { echo "<p><a href='$child->url'>$child->title</a>"; } Go back and edit the page where you previously inserted the [[children]] tag, and change it to: [[children, parent=1]] (specifying the homepage) or [[children, parent=/path/to/some/parent/]] if you want to try something else. View the page and you should now see it showing the children of the homepage (or of another parent you specified). Please see the Javascript and PHP usage notes on the Hanna code entry screen. Security There are major security implications with a tool that will let you enter unfiltered text and code from your web browser. As a result, Hanna codes are meant for definition only by superusers and we recommend keeping it that way. Download Download the Hanna Code module from the ProcessWire modules page or from GitHub.

The reason that next (and prev) can't be optimized in that way is that it assumes that the sort field is "sort". Typically when you've got a large quantity of pages, they have some other sort, like date or title or who knows what. So that "sort" field certainly could be directly queried, but it wouldn't mean anything unless the page was set for manually sorted children. Manually sorted children is the only situation under which PW can keep that "sort" field up-to-date. If you've got thousands of children, chances are you aren't manually sorting them. You can get around the scalability consideration just by determining the 'prev' or 'next' using criteria specific to your situation. For instance, lets say your pages were sorted by a field named 'date': $date = $page->getUnformatted('date'); $next = $page->parent->child("date>$date, sort=date"); $prev = $page->parent->child("date<$date, sort=-date");

Just wanted to mention you should change this: $child = $root->child(); if ($child) { To this: $child = $root->child(); if ($child->id) {

Sorry, I'm not fully understanding the question. Might need a screenshot to understand what you mean?

I think that page-publish is the only extra one recognized by the core that doesn't already existing the basic profile.

I'll look into this. But something you can always do as a workaround is just perform your own setLocale call from your template file.

I'm not sure why localUrl isn't showing up there and haven't been able to duplicate. But I have several updates to commit to the dev branch soon so interested to see if the issue resolves from there. Also interested to know if anyone else has seen this particular error?

Sorry about that! I don't even remember this one or when it was fixed, but it at least appears correct in all current versions.

Batcher has saved me major time on a few occasions too. Definitely a must-have module.

I think I understand now. This should work so long as "custom_template_file" is the name of a Page reference field, and "select_value" is the name of the field that contains the exact text "article_page.html" among your page references. None of the pages returned in your results should be "hidden" unless you specify an "include=hidden" or "include=all". Now if the page pointed to by "custom_template_file" is hidden, that doesn't matter, because that's a page you are using to match, not one of the pages being returned by find(). However, if you want that behavior, you may be able to do it like this: "custom_template_file.select_value=article_page.html, custom_template_file.status<" . Page::statusHidden; You can also check if an individual page is hidden by calling it's $page->isHidden() method, or $page->is(Page::statusHidden); -- both do the same thing.

Antti and I implemented the CKEditor module for ProcessWire, but I don't consider myself an expert with CKEditor at all, yet. As far as I know, the allowed attributes are a function of the plugins being used in CKEditor. Antti may know better? But ProcessWire essentially uses an unmodified copy of CKEditor, so if you can track down how to do it on the CKEditor site, then that would apply to PW's module as well. If you find supporting a common need requires additional configuration options for the module, I'll be glad to add them.

I'm not sure about this one or exactly how to reproduce from here. But if you want to give me a login to this site and tell me what/where to click to reproduce it, I'd be happy to take a closer look. Also let me know what version of PW you are using and whether dev branch or not.

If you can do it with PHP, you can do it with ProcessWire in much less time. In this particular context, think of ProcessWire like jQuery for PHP, but with a fast scalable content management framework at your disposal. While we don't have a lot of pre-built user registration/management features on the admin/interactive side, users are themselves pages in ProcessWire, and so the entire pages API is available for you to work with them. Given that, you may find ProcessWire to be a lot more full featured with regards to the user system from the API side than other systems, even if we haven't explored it in full on the admin CP side.

You may want to set $select->required = true; so that there isn't an unselected option. Rather than removing all the options and adding them back, you should just be able to set the 'value' attribute to whatever you want the selected option to be: $select->attr('value', $selected_page_id); Note that "kg" is your label rather than the value, so you are going to know the ID of the page with name/title "kg" in order to make it selected.

Btw, this might be a good place to mention that PW 2.3 dev adds a new Page::getUnknown hook (soon to be committed). That function gets called whenever a field is accessed that didn't resolve to anything. So you could [n the near future] do this (below) and you could call $page->some_radio_button_group on any page (specifically those that didn't already have the field) and have it resolve to what you want to. wire()->addHookAfter('Page::getUnknown', function($event) { $page = $event->object; $name = $event->arguments(0); if($name == 'some_radio_button_group') $event->return = new NullPage(); });

The some_radio_button_group field is a field of type Page I'm guessing. Since fields are bound to templates, and templates are bound to template files, you shouldn't have to check that the page has a some_radio_button_group field. That is, unless the code is independent of the template (like for shared functions across different templates). But if we can assume your template file knows what template it's dealing with, then you would want to set your Page field settings "details" tab to be dereferenced in the API as "Single page (Page) or empty page (NullPage) when none selected". That way your $page->some_radio_button_group->value; would result in a null (blank) even when the field has no value.

I'm not sure that a 404 page should be localized since it's responding to a URL that doesn't exist and thus has no language. Though you could potentially detect the language from your 404 page template by having your code look at the $_SERVER['REQUEST_URI'] for something that clarifies the language. Even better may be to have your code look at the $_SERVER['HTTP_REQUEST_LANGUAGE'] and set the $user->language consistent with that before rendering.

I'm not sure I totally understand the issue and might need a little screengrab/video to see exactly what you are talking about. But any javascript errors occurring in your JS console? It sounds like there would be two modals on top of each other here, and wondering if the targets are getting mixed up.

Curly quotes are working for me here at least. Though I do have to type them in as “usual” – option-[ and option-shift-[, or paste them in. Anyone else able to reproduce? Are you sure it's not just a typeface style (or lack of it?). For example, the quotes I entered around the work “usual” above are curly quotes in the editor here, but apparently the font the forum uses to render them uses the same glyph for both open and close quotes, making it appear they aren't curly quotes.

We're happy to host any *.processwire.* stuff on the main server here.

I have no idea why $_GET['q'] would be missing from the request when you specified it, but the only thing I can think of is if your request possibly resulted in a 301 first that went by unnoticed? This could happen if you specified the URL without a trailing slash in your <form action> attribute. In modern versions of MySQL it seems there isn't much difference even when you get into thousands of records. I suspect the real difference starts showing up in the hundreds of thousands to millions of DB records to search.

I don't have enough experience with this module to answer the question, but wanted to bump this question back up. I think Adam may be the best one to answer since he wrote the module. You may want to send him a PM too, just in case he's busy he might not see this thread.

I'm not enough of a Javascript expert to say for sure here. But I do know that jQuery provides some pretty reliable functions for this use: $(window).width(); // returns width of browser viewport $(document).width(); // returns width of HTML document No need to worry about session IDs with ajax requests. The server and browser are all handling this behind the scenes in the same way they do with a regular request.