ryan

Where you can do some nice integration with Shopify is via their post order hooks. You can very easily set Shopify to ping a URL on your ProcessWire site with some JSON data about an order, immediately after it takes place. From there you can easily automate creation of member accounts, for example.

I'm guessing that's client side, coming from your browser?

Thanks for pointing out the discrepancy–now I understand what you are saying, it makes sense. Technically, when you throw your own 404 in a template file, then the system has already determined the page and language, and the URL actually did resolve to something. But the template file decided it wasn't valid for one reason or another. I could have our 404 handler just set the language back to default. But the problem there is that this screws up the folks that are using subdomains to set the language (where a language-specific 404 could be legitimate). So I'm a little hesitant to change anything here. I think it might be best for the developer to decide what behavior they want from their 404 template file. But will have to think on this a little more to see if we can facilitiate anything better.

Nice job Kongondo! Some very cool things going on in that video too.

I'm not seeing that here. What browser/version are you using? Just wondering if we have some browser issue that is causing them to all be checked when you try to edit? Has anyone else run into this issue?

I don't think this would work as I'm not aware of any situation in PHP 5+ where PHP will return a TRUE value for empty() on an object. Assuming I understand correctly, PHP will never return anything but FALSE on an object. Though I think that in PHP 4 it would return TRUE for an object with nothing in it, but not so in PHP 5.

I just pushed ProcessWire v2.3.1 to the dev branch. This is a fairly major change in that it switches the DB driver from mysqli to PDO. It meant changes to a large percentage of core files. ProcessWire still supports mysqli, but doesn't attempt to use it unless a module or a template asks for it via the $db API variable. The new API variable (for the PDO driver) is $database. More about PDO at php.net If you are using the dev branch, be careful and test thoroughly with this latest commit to it. Before upgrading, you may want to double check that your PHP supports PDO by looking at your phpinfo (CMD-F or CTRL-F for "PDO"), especially if you are running PHP 5.2.x (where PDO wasn't compiled in by default). Though if you are running PHP 5.2 (vs 5.3.8+) then you may want to just stick with ProcessWire 2.3.0 and upgrade your PHP version when possible. If you are using any modules that use the procedural version of mysqli functions (vs. the $this->db object oriented versions), or type-hint mysqli in methods, then those modules will no longer work. If you come across any modules that don't work with 2.3.1, please let me know here so that I can assist the author in updating them. Note that FormBuilder is one of the modules that does not work with 2.3.1, but I have posted an update in the FormBuilder board that corrects it–so be sure to download that version if you are tracking the dev branch of ProcessWire and using FormBuilder. What this new version adds: 1. New API variable $database that refers to the PDO database. The old $db API variable is still there and refers to mysqli for any modules that continue to use it. 2. New API variable $log that lets you easily log messages or errors to the system logs. Usage: $log->message("This saves this line to messages.txt"); $log->error("This saves this line to to errors.txt"); $log->save("my-log", "This saves this line to my-log.txt"); // Get an array of the last few entries saved to the messages log $entries = $log->get('messages'); // Get an array of the last 50 entries saved to my-log $entries = $log->get('my-log', 50); Note that as always, log files are located in /site/assets/logs/. 3. Conditional autoload modules. In PHP 5.3+, modules may now specify an anonymous function OR a selector string, rather than a boolean for the 'autoload' property returned by getModuleInfo(). PW runs the anonymous function after determining the current $page, so your module can make autoload decisions based on the $page (or any other factor you'd like), if desired. Lets say that we have a module that we only want to autoload when the template is 'admin': public static function getModuleInfo() { return array( 'title' => 'Module Title', 'summary' => 'Summary text...', 'version' => 1, 'autoload' => function() { if(wire('page')->template == 'admin') return true; else return false; }); } And the same example but using a selector for autoload: public static function getModuleInfo() { return array( 'title' => 'Module Title', 'summary' => 'Summary text...', 'version' => 1, 'autoload' => 'template=admin' ); } 4. Addition of $pages->add() method. Actually $pages->add($template, $parent, [string $name], [array $values]); This function adds a new page to the database and returns it. This is for syntax convenience, but using the old method is still perfectly fine too. Here's a few examples of usage: // add a new page using template basic-page under /about/ $newpage = $pages->add('basic-page', '/about/'); // same as above, but named 'contact' $newpage = $pages->add('basic-page', '/about/', 'contact'); // same, but populate the title field too $newpage = $pages->add('basic-page', '/about/', 'contact', array('title' => 'Contact Us')); // you can also do this, specifying the values array as 3rd argument: $newpage = $pages->add('basic-page', '/about/', array('title' => 'Contact Us')); $template and $parent are required, but may be objects, IDs, or string identifiers (like name for template, or path for page). When you add a new page and don't specify a 'name', then PW will make one up, guaranteed to be unique. 5. Module files that end in '.module.php' are now supported. So rather than ClassName.module, you may use ClassName.module.php if you prefer it. The purpose here is to support text editors that determine their syntax highlighting based on the file extension. More updates being made almost daily. Please report any issues you experience. Thanks, Ryan

It's working for me at least, though I did change some things about the regex's in 0.0.4, so I might need to get more info about the context. What's an example of a tag that isn't working for you? What is the markup that surrounds it in your text? Also can you double check that "Hanna Code" is set as the textformatter for your body field (or whatever field you are using it in) in Setup > Fields > body > details? It should be fine to set your open/close tags to be whatever you want. Though [this] is a fairly common text construct, where as [[this]] is not. So if your [this] ever conflicts with the name of a Hanna Code, that could cause some confusion. As a result, I think it may be preferable to use open/close tags that don't duplicate things you would usually see in written copy.

I've never been able to reproduce this, so am wondering if there was some issue in a previous version of PW that was leaving orphaned repeaters (actually, I seem to recall there was for a short period, but my memory isn't great). What version of PW did you start with, and what version are you running now?

It sounds like it can't find the $page->editable(); function, which is a function added by an autoload module called PagePermissions.module. This is an unusual error message and not one posted before. It makes me think there may be something up with the PHP version, MySQL version or PHP opcode cache. Can you post what versions you are running of ProcessWire, PHP, MySQL and anything else about the server environment? (maybe a phpinfo() link if you want to PM to me)

Why not in the modules directory?

It looks like you have some unnecessary comparison in there (including a == full object comparison), I recommend this instead: if('en' == $user->language->name) setlocale(LC_ALL, 'en_GB'); Generally when comparing one page to another in ProcessWire, you want to compare the IDs: $page1->id == $page2->id; or if you want to compare the objects then use 3 equals so that it's comparing the instance rather than all the properties (per the way PHP works): $page1 === $page2; But in the case above, it wasn't even necessary to compare any objects since all you needed to compare was the name to the string 'en'.

The "missing required value" string is translatable in the file /wire/core/InputfieldWrapper.php. For your language pack, you would add this file as a translation target.

Thanks for the screencast Antti. Your cat sounds exactly like mine. This definitely helps clarify for me what the issue is. On the other hand, I'm still at a loss to know what is causing it. It's interesting to see the responses all appear successful and no indication of errors. I hope to experiment more with this soon. Correct me if I'm wrong, but doesn't it seem like the bit of code starting here is where it's getting stuck?

Just posted version 0.0.2 that addresses the items above. It also adds an option that lets you specify whether the immediate surrounding HTML tag should be replaced with your Hanna Code output or not. For instance, if your [[hello-world]] Hanna Code output is "Hello World" and is applied to the body copy containing "<p>[[hello-world]]</p>" then you probably don't want it to replace the surrounding <p> tags. Whereas if your Hanna Code outputs block level elements like "<ul><li>Hello World</li></ul>" then you probably do want it to replace the surrounding <p> tags, otherwise you'd end up with some invalid markup like: <p><ul><li>Hello World</li></ul></p>.

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.