ryan

I just posted version 5 of Hanna Code. The primary additions here are: Predefined (default) attribute values There is a new Attributes field present in the Hanna Code editor. From here you can define what attributes your PHP or Javascript Hanna Code expects. This can also be used to set default values for attributes. Use of this is optional. However, I think it's a good idea to use it as it helps communicate what the options are for a given Hanna Code. It also saves you some code as you can assume your attributes will be defined as variables, ready to access. The main listing page now shows Hanna Codes with their attributes so that they can be copied/pasted into your body text with all attribute options known and ready to fill in. Support for Export and Import of Hanna Codes Now you can export any Hanna code and import it somewhere else using copy/paste. You'll see the Export option when editing a Hanna Code. You'll see the Import option on the main listing page. Below is a predefined Hanna Code you can import if you'd like: Jumplinks Hanna Code (example for import) This Hanna code is meant to be used in your body copy. It collects all the headline tags in the text and turns them into anchor jump links while outputting a linked table of contents. It will put the table of contents wherever you type the Hanna code. See the anchor jump links on this page for an example of what this Hanna Code does. Import Data: !HannaCode:jumplinks:eyJuYW1lIjoianVtcGxpbmtzIiwidHlwZSI6IjIiLCJjb2RlIjoiXC8qaGNfYXR0clxuZm9yPVwiaDIgaDNcIlxuaGNfYXR0cipcL1xuJGZvciA9IHN0cl9yZXBsYWNlKCcsJywgJyAnLCAkZm9yKTtcclxuJGZvciA9IGV4cGxvZGUoJyAnLCAkZm9yKTtcclxuZm9yZWFjaCgkZm9yIGFzICRrID0+ICR2KSAkZm9yWyRrXSA9IHRyaW0oJHYpO1xyXG5cclxuJGZvciA9IGltcGxvZGUoJ3wnLCAkZm9yKTtcclxuJGFuY2hvcnMgPSBhcnJheSgpOyBcclxuJHZhbHVlID0gJGhhbm5hLT52YWx1ZTsgXHJcblxyXG5pZihwcmVnX21hdGNoX2FsbCgnezwoJyAuICRmb3IgLiAnKVtePl0qPiguKz8pPFwvXFwxPn1pJywgJHZhbHVlLCAkbWF0Y2hlcykpIHtcclxuICBmb3JlYWNoKCRtYXRjaGVzWzFdIGFzICRrZXkgPT4gJHRhZykge1xyXG4gICAgJHRleHQgPSAkbWF0Y2hlc1syXVska2V5XTtcclxuICAgICRhbmNob3IgPSAkc2FuaXRpemVyLT5wYWdlTmFtZSgkdGV4dCwgdHJ1ZSk7XHJcbiAgICAkYW5jaG9yc1skYW5jaG9yXSA9ICR0ZXh0OyBcclxuICAgICRmdWxsID0gJG1hdGNoZXNbMF1bJGtleV07IFxyXG4gICAgJHZhbHVlID0gc3RyX3JlcGxhY2UoJGZ1bGwsIFwiPGEgbmFtZT0nJGFuY2hvcicgaHJlZj0nIyc+PFwvYT4kZnVsbFwiLCAkdmFsdWUpOyBcclxuICB9ICBcclxuICAkaGFubmEtPnZhbHVlID0gJHZhbHVlOyBcclxufVxyXG5cclxuaWYoY291bnQoJGFuY2hvcnMpKSB7XHJcbiAgZWNobyBcIjx1bCBjbGFzcz0nanVtcGxpbmtzJz5cIjtcclxuICBmb3JlYWNoKCRhbmNob3JzIGFzICRhbmNob3IgPT4gJHRleHQpIHtcclxuICAgIGVjaG8gXCI8bGk+PGEgaHJlZj0nJHBhZ2UtPnVybCMkYW5jaG9yJz4kdGV4dDxcL2E+PFwvbGk+XCI7XHJcbiAgfVxyXG4gIGVjaG8gXCI8XC91bD5cIjtcclxufSBlbHNlIHtcclxuICBlY2hvICcnO1xyXG59In0=/!HannaCode Usage Examples: [[jumplinks]] Locates all h2 and h3 headlines, turns them into anchors, and generates a table of contents. This is the default behavior with no attributes. [[jumplinks for=h2]] Here we specify a 'for' attribute. It produces the same behavior as above except only anchors h2 headlines. [[jumplinks for=h2 h4]] Same as above except only anchors h2 and h4 headlines.

It's now hookable in the dev branch.

I think that this is for folks that prefer to copy/paste stuff. But for people that fully read and understand the docs, they can make their own examples, tips and tricks. They are the ones here having the most fun and responding to all the questions. Many assume the system to be much more complex than it actually is simply because they are giving more weight to tutorials and copy/paste snippets of code from the forum rather than the bigger picture that is emphasized by the docs. Though I know everyone learns differently. For me personally, I don't learn well from tutorials or snippets… even I get lost in most of the ProcessWire tutorials I've tried to follow. I need to know the big picture. And ProcessWire's big picture is really, really simple. Other systems are far more complex… I think an issue is that people aren't used to understanding the big picture because they assume a level of complexity that isn't there with ProcessWire. They want to know how to do this or that little thing, without considering that they really can know how to do everything. The closest path to knowing how to best develop in ProcessWire is to read the docs. The pre-requisites are knowing front-end development (HTML & CSS), and optionally a little PHP. Though even people that don't know any PHP can do more than they could with a template engine. But for people that do know a little PHP, anything is possible. If I recall, Diogo mentioned that he printed out all the pages in the /api/ section of the site, took them to a park, and read them in an hour or so. Despite not starting out as a coder, he came back here knowing how to do anything. He can literally answer any question because he knows the big picture. This is a good way to put it. My opinion is that even someone with no understanding of PHP will still be able to create more on their own with ProcessWire than they could in another system. But for those that really want to "drive fast" and see how far they can push it, they'll have a much stronger engine at their disposal than they might in another system. For those people, php.net becomes a valuable documentation resource too.

I recommend adjusting your MySQL fulltext minimum indexed word length. Search this forum for "ft_min_word_len". Phrases should work with %= but the phrase you are searching for would have to be identical to the words it matches. Meaning if you searched for "white tea", it would only match pages containing the phrase "white tea", and not pages that have the words "white" and "tea" separated. Another thing to mention is that your full query above included "path", which is not query-able since it is generated at runtime (not in the DB). You can make it query-able by installing the PagesPaths module included with the core, but I don't think it can be part of an OR "|" set of fields. I recommend removing "path" from your query logic, as chances are the path is based on the title anyway. It sounds to me like what you really want is the "~=" operator, which will match all the words regardless of where they appear in the copy. Given that, tweaking your MySQL fulltext minimum index size (ft_min_word_len) would be worthwhile. See more details about how the different operators work here: http://processwire.com/api/selectors/#operators

No problem Horst. Actually I hadn't started trying to work on this yet, but was going to yesterday afternoon. Then I got your message that it sounded like the issue was resolved, so I didn't look further. But just wanted to double check that the issue is resolved and you don't still need me to look at anything there?

What version of ProcessWire are you using? 2.3 and newer (at least) should supporting sorting by multiple fields in WireArray / PageArray.

I originally missed the issue with language switchers not working on the 404 page because all the instances where I'm using language switchers, I was only have it show the language switcher if the page was not the 404 page. The reasoning there is just that in my case, there wasn't much point in being able to show different language versions of a 404 page. If your situation is similar, I recommend simply not showing the language switcher when on a 404 page. Though if you want the switcher to redirect back to the homepage, that seems like another decent approach. But here's what I did: if($page->id != $config->http404PageID){ // render the language switcher }

ProcessPageAdd::getAllowedTemplates() now hookable on the dev branch.

If you are telling it to render using a specific template file, and that file doesn't exist, than an exception would be the right behavior. If there's a possibility the template might not be there, you should check yourself before asking it to render. Example: $file = 'markup/layouts/package.php'; if(is_file(wire('config')->paths->templates . $file)) { echo $package->render($file, array('layout' => 'package')); }

There is no FieldtypeName, and FieldtypeText is only going to use InputfieldText (it's not configurable for this particular fieldtype). So what I'd recommend doing us using the 'pattern' property of the field (which is supported by FieldtypeText) to require a name format: $field_templates->pattern = '^[-_.a-z0-9]+$'; If you want it to accept spaces too, then add a space immediately after the 0-9.

I'm using the default theme, so not positive what method it's using to show you 'latest updates'. But assuming it's showing pages with the most recent 'modified' date, chances are that some module hook somewhere updated that page. Either that, or it's limiting them to a specific time and you fell in that time one time and not another. This may be a question for that theme's thread.

That's essentially what I posted above, though in a different context (module config rather than ProcessPageEdit). If you wanted one in ProcessPageEdit, you'd probably want to create a new Fieldtype for it. Actually, just checked and it looks like Hani already has.

labelFieldName is specific to InputfieldPage. It identifies the field that you want to use as the selectable label. Typically this would be 'title', but for something that doesn't have a title 'path' would be a good choice.

The biggest issue that I can see here is that you don't have page numbers enabled for your template. ProcessWire putting in the "page=2" is a signal of that. So before you do anything else, go and enable page numbers by editing your 'search' template–you'll see the option to enable page numbers on the URLs tab. When it comes to dealing with your 'vendor' field, I recommend whitelisting it to a string in whatever format you want to extract it. For instance, maybe you want to use commas as a separator rather than pipes. You can whitelist it like this: $input->whitelist('vendor', implode(',', $vendors)); // if vendors is an array $input->whitelist('vendor', str_replace('|', ',', $vendors)); // if vendors is a PageArray Though you could certainly stick with "|" pipes if you preferred. But what I don't want to see you do is bundle that right from $input->get->vendor into a selector without validating it first. So switching to another separator makes that intention a little more clear. For instance, your form processor might capture and sanitize the vendor variable like this: if($input->get->vendor) { if(is_array($input->get->vendor)) { // array from form submission $dirty = $input->get->vendor; } else { // convert from your CSV string to array $dirty = explode(',', $input->get->vendor); } $vendor = array(); foreach($dirty as $id) $vendor[] = (int) $id; // sanitize to INTs $vendor = implode('|', $vendor); // convert to 123|456|789 string, ready for selector } else { $vendor = ''; }

The way you do it is to first add a new integer field to your 'brand' template. Call it something like 'num_products'. You might choose to make it hidden, so that it doesn't appear in the editor (if you prefer that). Next edit your /site/templates/admin.php and add this above the include() line that's already there: $pages->addHook('saveReady', null, 'updateBrandQuantities'); function updateBrandQuantities($event) { $page = $event->arguments(0); if($page->template == 'brand') { // a 'brand' page is being saved $page->num_products = wire('pages')->count("template=product, brands=$page"); } else if($page->template == 'product' && $page->isChanged('brands')) { // a 'product' page is being saved and 'brands' changed foreach($page->brands as $brand) $brand->save(); } } The trick is that if you already have a populated site, then you have to establish the quantities for the first time by saving all the 'brand' pages. You could temporarily add this code to one of your site's template files and view the page to populate them. After that, remove the code as it would no longer be needed. foreach($pages->find("template=brand") as $brand) { $brand->save(); }

If there's a need for any method to be hookable, I can make it hookable. I didn't try to cover every possibility, instead preferring to make it easy to make hookable methods and them implementing them each time a need comes up. So if you want User::hasPermission to be hookable (for instance), just let me know and I'll make it hookable on the dev branch.

The strtotime call isn't technically necessary. You could also just do this: foreach($programs->find("program_start_date<04/01/$year") as $program) {

I'm not sure that I follow everything here. But if you are getting 1 fewer pages in the role_editable_pages than you expect, that seems to imply that something has removed a page from it at runtime. Looking at the above code, the only place that I see where a page is removed is here: $p = $parents->pop(); You might try commenting out that line to see if that's the culprit. Or if commenting it out will result in some kind of infinite loop, you could just echo the contents of it like $this->message("pop: $p"); ...I'd be curious if it's popping the /about/ page.

It sounds to me like no error is actually being generated by anything. You mentioned that you got this "Error retrieving Twitter status: 0". That indicates that oAuth didn't report any errors, since it's now reporting the status of the JSON decode. A status of 0 means json_decode() reported no errors. Unless you literally don't have any tweets on the timeline you are checking, chances are that we are getting tricked by the cache. Try disabling the cache by setting the # seconds to 0: $t->cacheSeconds = 0; Any change in the errors? -- edit: Ah, no tweets. Glad you found it.

The module actually only logs the errors in PW 2.3.1+ (current dev branch), as it's using the new $log API variable. So in 2.3.0. it's not going to be quite as clear. But try adding this line after your $t->render(): foreach(wire('notices') as $n) echo "<p>$n->text</p>"; See if it gives any more detail on the error? I've really tried to avoid throwing exceptions in this module (which would produce more obvious errors) so that some problem at Twitter doesn't interrupt your own site beyond the rendered markup from this module. And since I didn't know all the potential errors that tmhOAuth or Twitter might report, I didn't want to have it echoing any error messages that might potentially contain authentication related stuff.

It shouldn't matter if your site is multi-lingual or not. Though just out of curiosity, which method(s) of multi-language are you using? If you are right about "endless redirect" (as in a 301 or 302), most likely the issue is occurring somewhere before PW since there are no redirects in this template. Double check that your template is set to not have a trailing slash. Then, check your .htaccess file to make sure you don't have some directive in there that is enforcing trailing slashes.

Actually on the original update it said it was compatible with 2.2.9, as I thought it was at first. I realized later that day it wasn't and updated. So it's my mistake, not yours. You might need to enable debug mode. Also check here to make sure that your server is compatible with the requirements/dependencies listed: https://github.com/themattharris/tmhOAuth

That error translates to "Unexpected use of double colon". It's not something that should matter between PHP 5.2 and PHP 5.3, and that particular block of code hasn't changed. (though there have been other changes in Modules.php, and maybe this is a side effect?). That error can occur when there is a module file that is named differently from the class within it. This is why PW requires that a module class HelloWorld be contained in a file called HelloWorld.module. It's unusual for sure, I'm not sure what the issue could be. Do you know of any other differences in the server setup? Opcode cache or some other PHP stuff going on? It might be good for us to look at the phpinfo() output. Also, what 3rd party modules do you have installed? If you could PM me any relevant info to login via FTP, and to your PW admin, I should be able to debug this.

What version of PW? I was getting the same error recently, and not positive if the source is the same… but try out the latest dev branch, which has a fix for it.

I don't think anyone can answer that question except the person that put it there. But if there's something that says not to use it on a production site, and it's not necessary for the operation of the software, I would remove it. Though "don't use on a production site" is often just a kind way of saying "don't yell at me if something breaks."