Leaderboard

ProcessWire2.+ Admin Hot Keys 0.0.7 This modules adds hot keys functionality to PW backend. The keys can be configured in the module settings in the admin. I created a repo here for download and if anyone interested in picking it up. https://github.com/s...ic/AdminHotKeys Currently it supports Save : ctrl+s Add New : ctrl+n View Page : ctrl+v Open Pages search : alt+q (search field can be configured) Open Templates search : ctrl+shift+t Open Fields search : ctrl+shift+f Goto Pages : ctrl+shift+p Goto Setup : ctrl+shift+s Goto Modules : ctrl+shift+m Goto Access : ctrl+shift+a Note: If you're inside a text input it will ignore the hot keys, as to avoid problems with already defined key. Tip: If you open up templates or fields autocomplete search `ctrl+shift+f|t` press `shift+tab` to focus on the link in the label previous to the search input box. Now hit enter to get right to the template or field screen. (If using FF make sure to enable tab focus for all elements in MacOSX: http://support.mozil...enus or buttons)

Hi, This is another oldie I spent a few hours converting away from EE. http://soksabairesort.com/ Regards Marty

@Ryan: running the script now should give you a pretty clear overview of things that need to be corrected to comply with PSR-0: correcting filenames and breaking classes/interfaces into separate files. I think these can be implemented on the current branch, without breaking backwards compatibility? (with some simplification of the autoloader.)

What does autojoin do? Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. What sites should use autojoin? Autojoin is most applicable with larger sites. On smaller sites, there may be no benefit to using it or not using it. But it's good to know what it's for regardless. Where do you control autojoin? Autojoin is controlled per-field. You can turn it on by editing each field under Setup > Fields > [your field], and you'll see it under the 'Advanced' heading. When should you use autojoin? Autojoin causes the field's data to be loaded automatically with the page, whether you use it or not. This is an optimization for fields that you know will be used most of the time. Fields having their data loaded with the page can increase performance because ProcessWire grabs that data in the same query that it grabs the Page. Autojoin is a benefit for fields that are always used with the Page. This is best explained by an example. Lets say that you have a template for individual news stories called news_story. The news_story template has these fields: title date summary body sidebar We'll assume that when you view a page using the news_story template, all of the fields above are displayed. Fields that should have autojoin ON: Now consider a separate news_index template that displays ALL of the news stories together and links to them. But it only displays these fields from each news story: title* date summary In this case, the 3 fields above would be good to autojoin since they are used on both the news_index and news_story templates. If your title, date and summary fields didn't have autojoin turned on, then ProcessWire wouldn't go retrieve the value from the database until you asked for it it (via $page->summary, for example). Because the news_index template displays all the stories at once, and always uses the title, date and summary fields, it will perform better with title, date and summary having autojoin ON than with it OFF. In this case, it reduces the query load of the news_index template by 3 for each news story. To take that further, if it were displaying 20 news stories, that would mean 60 fewer queries, which could be significant. Fields that should have autojoin OFF: Now lets consider the body and sidebar fields, which are only used on the news_story template: body sidebar It would be desirable to leave autojoin OFF on those fields because there is no reason for the body and sidebar to be taking up space in memory when they are never used on the news_index template. While it might mean 2 fewer queries to view a news story, that is not significant and certainly not a worthwhile tradeoff for the increased memory footprint on the news_index template. Keeping autojoin OFF reduces a page's memory footprint. Conclusion Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. But if your situation doesn't involve lots of pages or data, then you don't need to consider autojoin at all (and can generally just leave it off). Additional Notes Not all fields have autojoin capability. You won't see the option listed on fields that don't have the capability. *The title field has autojoin on by default, so you don't need to consider that one. It was included in the examples above because I thought it's omission might cause more confusion than it's inclusion. Be careful with multi-value fields that offer autojoin capability (page references and images, for example). Because MySQL limits the combined length of multiple values returned from a group in 1 query, autojoin will fail on multi-value fields that contain lots of values (combined length exceeding 1024 characters). If you experience strange behavior from a multi-value field that has autojoin ON, turn it OFF. If you want to play it safe, then don't use autojoin on multi-value fields like page references and images.

Just made a little test and changed code to add setOutputFormatting to false. This is required to get it to work.

It took a while, but I found the sulution: foreach($u->execute() as $key => $filename) { $page->images->add($filename); $page->images->eq($key)->description = 'what you want to say about the image'; }

Martijn: There is a link to some high resolution logos linked at the bottom of this post. They aren't print resolution, but still quite large. We could probably use some powered-by logos, so if anyone feels like sharing what they come up with, definitely post it.

Wow, this is a nice little helper. Great work! One suggestion. Is it possible to go to the templates / field main page if I just press enter in the empty modal? This way we dont't need a additonal shortcut for these pages.

Just to make Ryan's code complete: $u->setValidExtensions(array('jpg', 'jpeg', 'gif', 'png')); tnx Ryan & Sylvio

Work fantastic ... ctrl+shift+v --> view page ?

I've decided to use repeaters and it turned out great (it's better for print template that I have). Here is the code: if($input->urlSegment1 == '') { echo $page->body; foreach($page->additional as $additional) { $slug = cleanURL($additional->title); echo "<a class='button' href='{$slug}'>{$additional->title}</a>"; } } else { foreach($page->additional as $additional) { $slug = cleanURL($additional->title); if($input->urlSegment1 == $slug) { echo "<h2>{$additional->title}</h2>"; echo $additional->body; echo "<a class='button' href='{$page->siblings->prev}'>Back</a>"; } } foreach($page->additional as $additional) { $slug = cleanURL($additional->title); if($input->urlSegment1 != $slug) { $additional->remove($input->urlSegment1); echo "<a class='button' href='{$slug}'>{$additional->title}</a>"; } } } I've enclosed slug function that I use in attachment (include it in article template). I hope someone will find it useful for their projects. Maybe it could be improved, but it's working fine. How it works: You add repeater field to an article and add title and body field to it. You must turn on URL segments in article template. When you add extra content through repeater field it shows extra content titles as links below content. When you click on some extra content's title it shows that content as URL segment and appands clean url to parent url of the article. Below extra content, links are shown to other extra content's defined through repeater field excluding the one currently showing. slug.php

Your welcome. Thanks. Little update after playing around a little. changed to use save hot key for all edit screens to save not only page. added "Add new" hot key support for Template, Fields, Users, anything that has a "Add new" button. Have fun.

I just started and created a simple module to add hot keys, currently only starting with Page Save. https://github.com/somatonic/AdminHotKeys

I just added it to a german site. Maybe you want to incorporate a german translation. ProcessWire im Fuß anzeigen? Wenn deaktiviert, wird der kleine "Powered by ProcessWire"-Slogan nicht in der Fußzeile erscheinen. ProcessWire ist Open Source und freie Software. Dieses Kontrollkästchen aktiviert zu lassen, ist eine Möglichkeit, Ihre Wertschätzung und Unterstützung zu zeigen. Das ProcessWire-Entwicklungs-Team bittet darum, soweit möglich, im Austausch für die Verwendung der Software. Allerdings ist es Ihre Entscheidung und kein Muss. BTW: I also learned something: How to set an option only once for the home page is valid for the whole site.

Actually I gonna be busy with a little "site" where "players" can upload their multiple photo's, and "voters" on the other hand can vote on 1 uploaded photo out of the list. How to set-up this thing is still a little bit vague to me. Maybe I need an other "folder" for storing each vote ( template with image_name, players_id ) or something. ) ps. I'll post the whole thing over here: Configure Postfix for Gmail SMTP Edit file /etc/postfix/main.cf in this example it's done with nano in the terminal sudo nano /etc/postfix/main.cf and add in the following below the commented out relayhosts: relayhost = [smtp.gmail.com]:587 smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = noanonymous smtp_use_tls = yes Generate sasl_password if not already exists sudo nano /etc/postfix/sasl_passwd and enter in the following (replace username & password with your's ) [smtp.gmail.com]:587 username@gmail.com:password Then run the following commands: sudo chmod 600 /etc/postfix/sasl_passwd sudo postmap /etc/postfix/sasl_passwd sudo launchctl stop org.postfix.master sudo launchctl start org.postfix.master And you are done…. btw: Thank you Anuj Gakhar (www.anujgakhar.com)

I don't think it matters much here. The object===object is probably about the same thing as an id==id integer comparison, when it gets down into the low level code that it's written in. That's because object===object is comparing that two objects are the same instance, which translates to: do they occupy the same place in memory? (1234567==1234567) But there is a good reason to use the id==id over object===object in ProcessWire: $about1 = $pages->get('/about/'); $about2 = $pages->get('/about/'); echo $about1 === $about2 ? "Same Instance " : "Different Instance "; This should output "Same Instance". But then try this: $about1 = $pages->get('/about/'); $about1->set('title', 'About Test')->save(); // can be any page that is changed then saved $about2 = $pages->get('/about/'); echo $about1 === $about2 ? "Same Instance " : "Different Instance "; This should output "Difference Instance". Why? The entire memory cache is cleared when you save a page where one or more fields changed, or if you delete a page. It doesn't matter if it was $about1, or some other page, the memory cache is wiped. Since the code above kept it's own copy of the /about/ page before it was saved, there are now two copies of /about/ in memory: your copy and ProcessWire's copy. For this reason, you may prefer to compare the 'id' property if the code you are working with is manipulating any pages or interacting with modules that do. But for most front-end situations, it doesn't matter.

There's a couple spots that it could go, but right now I'm thinking you'd want it in CommentForm.php in the processInput() function, after this line: $this->page->save($pageFieldName); If you are working off the most recent version of the comments module, a findComments() function was added a couple weeks ago. This example assumes your field name is 'comments' and you want to get comment ID 1234: $comment = FieldtypeComments::findComments('comments', 'id=1234')->first();

To get things started in this forum, I'm going to post some of the Q&A from emails that people have sent me. That's a good question. For most cases, I would not try to create a different page structure for years/months because that's more work and it invites the possibility that the links will change over time as you move pages to archive them. After using different strategies over a few years, I think it's better to have a single container page under which all news items will be placed, permanently. Then set that container page's default sort to be by date, so that newer items always appear first. From there, the news page should focus on the newest items, and provide links to past news whether by pagination, month/year links, etc. In this respect, you can treat a page in PW2 in the same manner that you would treat a channel in EE2. There is no problem with scalability… PW2 will run just as well with 10k+ subpages as it would with 10. When following that suggestion, these are the only scalability considerations: 1. You may occasionally have to consider the namespace with the URL "name" (aka "tag" in PW1) field. For example, if you have two news stories with substantially similar headlines, you may have very similar URL name fields. But ProcessWire will enforce that namespace, so it's not going to let you create two pages with the same name under the same parent. What that means is it'll make you modify the page's URL name to be unique, if for some reason it's not. I'm talking strictly about URL names, not headlines or anything like that. 2. When dealing with news stories (or any place that may have a large scale of pages), you want to pay attention to how many pages you load in your template API code. If you are dealing with 10k news stories, and load them all, that will slow things down for sure. So the following applies: Avoid API calls like this: 1. $page->children 2. count($page->children) Instead, use API calls like this: 1. $page->children("limit=10"); 2. $page->numChildren $page->numChildren is something that ProcessWire generates for every page automatically, so there is no overhead in calling that, like there is in count($page->children). But if working at a smaller scale, it doesn't really matter what method you use. The most important thing to remember is just to use "limit" in your selector when potentially dealing with a lot of pages. That applies anywhere, especially when making things like search engines. So when you want to support unlimited scalability, these are the functions where you want to place limits: $page->children(...) $page->siblings(...) $page->find(...) $pages->find(...) The other reason someone might like archiving to year/month is because it makes it easier to link to since you could just link to /news/2010/04/ for instance. But it would be a fairly simple matter in PW2 to make your template look for "month" and "year" get vars, or a URL segment, and produce results based on those… See the other topic in this forum for one way that you might do that.

Hi Ryan, In your first snippet (using WireUpload class) I had to change somethings to make it work, first passing the extensions as an array and second this line foreach($u->execute() as $filename) $page->add($filename); I had to change it to: foreach($u->execute() as $filename) $page->files->add($filename); (added the field in the add method) Everything works correct, one question, how do I update the 'Description' of the file field after the file has been added?