Leaderboard

Some time ago there was a question if it's possible to change the "name" field on the users to "Username". Here's how I answered with a module example. May it be helpful to someone. <?php class UserNameLabel extends WireData implements Module{ public static function getModuleInfo() { return array( 'title' => __('UserNameLabel', __FILE__), // Module Title 'version' => 100, 'summary' => __('Overwrite User Name Label', __FILE__), // Module Summary 'autoload' => true ); } public function init() { // only add hook if on user pages if(strpos($_SERVER['REQUEST_URI'],'/users/') !== FALSE ) $this->addHookAfter("Inputfield::render", $this, "changeLabel"); } public function changeLabel($event){ $inputfield = $event->object; // only if the right inputfield if(!$inputfield instanceof InputfieldName ) return; // overwrite the label return $event->object = $inputfield->label = __("Username"); } } UserNameLabel.module.zip

I am floored by the response here. I get the concept now but it is going to take me sometime to process everything and weigh the options . I will post back the results once I have tried them and also if I have any doubts. Marking the thread as solved. Seriously, you guys are great..

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.

Hello, I found ProcessWire today when exploring ModX little bit. It's absolutely amazing. I have few questions and I must state that I don't have php skills, but PW seems simple enough to implement without these skills. 1. What is the best way to "split" code for better templating? I mean writing head section only once, footer only once etc. I realize that it may be done in many "good" ways, but how would you prefer it being done? Can they be seperate templates so that I could create reusable building blocks? 2. Can I have "global variables" that I would use in templates but don't want to create separate template or page for? 3. How do you differentiate pages when you have 2 menus on website (how to create page added to second menu only)? How 2 menus play with the tree? I will ask more noob questions soon

PW populates your config variables to the module in the time between __construct() and init(). So when init() is called, your config variables have already been populated to the module. As a result, the __construct() is a good place to populate defaults. In your case, you could do this in your __construct(): foreach(self::$defaults as $key => $value) $this->set($key, $value); I don't think that a Pageimage (singular) is applicable here since all image fields are multi-image fields behind the scenes. The existence of a single image field is just a type of output formatting used on the front end of your site. I believe output formatting is turned off in the case of your module, so you should be able to assume that all image fields are multi image fields (Pageimages). As a result, I would perform the check like this: if($v instanceof Pageimages && count($v)) { // ... }

@Nikola, thank you for putting this up on Github. @all, I've updated the futura-delta repository on Github (download as zip) to include many of the features that Nikola has worked into his lovely theme. The main difference between the two is that futura-delta has a much lighter approach to styling the search box.

Long story short. You're most likely looking for wire(). You can use also in function scope. wire("pages")->find(...) wire("sanitizer")-> etc...

Hi, jukooz and welcome. 1) For simple websites you could use usual includes to reuse your building blocks. See the home.php and basic-page.php for the example in site/templates/ folder. Also see this really cool thread about different approaches to templating. 2) You could create a page using a special template with all the necessary fields to store your global variables. Then you could access it everywhere in your template them as easy as: $globalVars = $pages->get("/path/to/your/page/"); // you can also use page id instead of url $globalVars->fieldname; You could include it in your header.inc so that you don't have to call it every time. 3) You could use a "show (hide) in secondary menu" checkbox for your pages and then check against its value in your code to show only items you need. Have you seen this already?

Another option here is to place all the fieldtypes into one template and use FieldsetTab pairs so that input fields get distributed onto different tabs in the page editor and it stays nice & tidy. For better undestanding see the picture in the first post. Then you could have all the fields accessible in your template like this: $page->fieldname. I think this method is pretty neat provided you cache the page. The drawback here is that your site becomes less modular and you can't unpublish or substitute one page (section) with another as simple as with regular approach. But sometimes all you need is simplicity. Edit: And if repeated elements of your page are uniform and their number is not supposed to be large, you could use repeater fieldtype for better user experience. Cheers.

Yep, works great! In case anyone is following along, my original example is updated and working correctly. Thanks Ryan!

Good question. I'm not sure there's a simple answer though. What you mentioned about migrating changes directly from the database of WordPress doesn't sound like a safe thing to do with any database-driven CMS. The nature of a relational database is that there will be records in different tables referencing each other, so when you've got two versions of the same database, they would be challenging to merge. As a result, it's a problem if you have two databases going off on different paths of changes if they need to come back together at some point. I use my staging servers for staging things like new template files, modules, new PW versions, etc. I don't usually stage actual content from one server to another. Or if I do, I'm copying and pasting it (in PW admin) from one to the other. But the way I usually stage major content changes is to make them on the live server, but in a staging part of the site (unpublished, hidden or otherwise inaccessible pages). When ready to migrate, I publish or drag the relevant pages to their live home. Note that this is for content, and not for anything that could interfere with the operation of the live site. Anything that could interfere with the live site (templates already in use, modules, versions, etc.) ideally should be staged on a different server. I don't know of a better way than that. It's not perfect, but it's always worked well for me. Longer term, I want ProcessWire to support a workflow that lets a staging server talk to a live server and publish from one to the other (using web services). I already use this workflow on a lot of sites with custom modules, but they are specific enough to the individual sites that they aren't suitable as a broader solution. However, I do think we'll have a broader solution like this in the next 6 months to a year.

I've got this all working now. It took a little more work than I initially thought, so just need to test for a couple days on this end to make sure I haven't introduced any new bugs.