thetuningspoon

Maybe some talented programmer like Soma could build a "PagePro" field?

Not sure if this has been brought up before, but it would be great if the Page field could be configured to allow you to edit any page (in a popup window) that you have selected when using the asmselect. It would work just like the new PageTable field does, except allow you to select and edit existing pages instead of new ones. There are several use cases I've found myself in where this would have been a really handy feature.

@teppo - Couldn't have said it better

Sorry, I mean "template engine" in the generic sense of building the final view that users see and the process for generating that. I'm not talking about a language like smarty or anything like that. Sorry, I'm not really up on all the lingo and proper terminology for these things. I'm just wary of unnecessary complexity, that is all. What you do in your own ProcessWire install is none of my business After all, the beauty of PW is it's flexibility and the fact that it doesn't force you to do things a certain way. I just know that I would have been turned off if the workings of the PW templates weren't immediately clear to me when I first found it. This is from someone who came from building sites with pure html, pages, css, and a few php includes, so that is the world I'm from, take it or leave it

Yes, I am familiar with this since I'm using that exact technique in a process module I'm working on. I saw how Ryan was using it in parts of FormBuilder and was wondering how it worked, so I looked into it and saw how it uses php output buffering behind the scenes. Of course, this is how ProcessWire templates work in the first place. For most users, I think having to build an entire templating engine on top of ProcessWire's already existing templating engine is just too meta. Also, please bear in mind though that I'm not "copy pasting" from one template to another, but using includes. You can also have includes within includes, and conditional logic for displaying includes, so it can be quite flexible.

Hi Soma, thanks for your thoughts. I can see how there are plusses and minuses to each method in terms of flexibility and scalability under different scenarios. For me personally, I haven't encountered any of the issues you mention, but most of my projects don't use more than 5 or 6 templates with actual output. There are really so many different ways of structuring your site in ProcessWire that it's hard to make comparisons apples to apples. My main concern with the delayed output is that it introduces an extra step that obfuscates how ProcessWire works and might turn new users off for that reason. And, two, because it requires you to write most of your html like this: $mainOutput .= "<p>Some stuff</p>"; $mainOutput .= "<div>Some more stuff</div>"; Which--for a front end developer--is just yucky.

Hi BernhardB, thanks for the reply. You can still do this with the direct output method (and in fact I do quite often). Simply define your array/variables at the beginning of your template file, and then have your head.inc file process them. For example, I use Ryan's stylesheet and script arrays at the beginning of my template file for adding on scripts that are unique to a particular template, and then I have my head.inc loop through those and create the markup.

Here's a script that I've been using on our sites and recently enhanced to also handle the conversion from TinyMCE to CKEditor in ProcessWire 2.5. It's a sort of "global config" for CKEditor, which allows you to change the settings for all CKEditor fields at once. Note: This one will automatically update all CKEditor fields unless they are explicitly excluded in the config ($excludedFields). If you want it to change TinyMCE fields into CKEditor fields, make sure $replaceTinyMCE is set to true in the config section of the code. <?php include('./index.php'); // Config $excludedFields = ""; // List of fields to exclude, separated by pipe (i.e. "body|sidebar") $replaceTinyMCE = false; // true|false If true, converts any fields using TinyMCE to use CKEditor instead // Change any fields using TinyMCE to use CKEditor instead if($replaceTinyMCE) { foreach(wire("fields") as $field) { if($field->type == 'FieldtypeTextarea' && $field->inputfieldClass == 'InputfieldTinyMCE') { $field->inputfieldClass = 'InputfieldCKEditor'; $field->save(); } } } // Get all fields using CKEditor $fields = new WireArray(); foreach(wire("fields") as $field) { if($field->type == 'FieldtypeTextarea' && $field->inputfieldClass == 'InputfieldCKEditor') { $fields->append($field); } } // Exclude any fields specified above $fields = $fields->find("name!=$excludedFields"); // Apply settings foreach($fields as $field) { $field->contentType = "1"; // 0="Unknown", 1="Markup/HTML" $field->rows = "15"; // The number of rows initially shown for this field. $field->toolbar = " Styles Undo, Redo Bold, Italic, -, RemoveFormat NumberedList, BulletedList, -, Blockquote PWLink, Unlink, Anchor PWImage, Table, HorizontalRule, SpecialChar PasteText, PasteFromWord Scayt, -, Sourcedialog "; $field->inlineMode = "0"; // 0="Regular Editor", 1="Inline Editor" $field->textformatters = array("TextformatterHannaCode","TextformatterVideoEmbed","TextformatterSmartypants"); // Accepts ordered array of module names $field->useACF = "1"; // 0="No", 1="Yes" $field->usePurifier = "1"; // 0="No", 1="Yes" $field->extraAllowedContent = ""; $field->formatTags = "p;h2;h3;h4;h5;h6"; $field->contentsCss = ""; // Path to your css file, i.e. "/site/templates/styles/contents.css" $field->stylesSet = ""; // Path to js file containing stylesSet, i.e. "mystyles:/site/modules/InputfieldCKEditor/mystyles.js" $field->customOptions = ""; // Custom Config Options $field->extraPlugins = "pwimage,pwlink,sourcedialog"; $field->plugin_sourcedialog = ""; // Sourcedialog settings $field->removePlugins = "image"; $field->save(); } ?> CKEditor is now updated. Updated fields: <? foreach($fields as $field) echo $field.', ' ?> To use the script, simply copy the above code into a file in the root directory of your ProcessWire installation, and name it something like "ckupdater.php". Edit the configuration settings under the "Apply settings" section how you'd like, (I've done my best to briefly document how these work--at least the more confusing ones). To run the updater, just go to www.yoursitegoeshere.com/ckupdater.php. It will confirm the update and tell you which fields were effected. Hope this helps someone out!

Just be aware if you are using TinyMCE that you will have to add the module to your /site/modules/ folder since 2.5 only comes with CKEditor.

Sorry, but I don't think the specific code would be helpful in this case. It's spread out, and the part that has to do the actual issue is what I've explained above. If it's not something apparent to anyone, I'll keep hacking away at it or settle for using $_SESSION.

Hi all, I'm setting a PW session variable in a module for an error message to output later in my template. The message is not appearing in my template, and I've narrowed it down to the fact that I am doing a $session->redirect("./") to reload the page after setting the value using $session->error = "my error message". If I use the php $_SESSION superglobal or if I remove the redirect, it works fine. But PW's $session should persist after a redirect, so I'm not sure what's going on here. EDIT: By the way, I'm using 2.5. Also, just realized that I'm getting this warning message: Warning: Invalid argument supplied for foreach() in /wire/core/Session.php on line 79

Hey, that's mine!

I don't understand how delayed output is more scaleable, and I definitely think it is more confusing for your stated target audience. I actually find the opposite to be true for me in terms of scaleability (or at least flexibility), because delayed output forces me to use the same overall structure (the variable "bins") for all of my pages. It also forces you to write all of your markup in a php-first way (unless you know how to use output buffering) instead of an html-first approach, which I think is more appropriate for template files and easier for front-end developers to work with. When I do find myself repeating myself in the template files, I can just use php includes for any section of code that is used in more than one template. Don't get me wrong, I love php. I just think that it should be as "loosely coupled" from the markup as possible. When it's time to write html, I want to think more about html and less about php.

Even just searching "processwire {searchterm}" in Google usually does the trick.

Hmm... If you did a category/tagging system or based it on the existing tagging system, you wouldn't be able to customize the order of the fields in different templates. That said, I agree that the fieldset/fieldsetTab system right now is a little bit unintuitive, even if it is quite functional. A fieldset doesn't really "feel" like it should be a type of field itself, and having to setup each fieldset can get a little tiring. I think it would be nice if the fieldsets could just be created and added right from within the template's edit screen. I've recently started using fieldsetTabs to split off content into "Sidebar" and "Media" tabs, and it really helps to clean up the editor. It's a great feature that I'm surprised I haven't really used before now. Another thing that I've started to realize could be helpful in PW is some way of grouping fields into portable components that could be added to templates as a single unit (like repeater fields, except without the repeating part), instead of having to add each field one-by-one. Technically, templates ARE linked to "fieldgroups" (if you have advanced mode on, you'll see the option to use a fieldgroup from one template in another), but I don't believe you can have more than one fieldgroup per template. Anyway, it could end up adding more complexity and confusion to the system, but it could also be a big time saver in some cases. EDIT: I think if it was setup as new fieldtype similar to repeaters it wouldn't be too confusing. Maybe it's time for me to build a module...

Agreed. Having the page tree always available as an option would really speed up my workflow tremendously. I think it would be great if the technical issues could be overcome and this could be made an option in the new Reno theme. I remember that was one thing I really liked about Silverstripe.

Yes, exactly how I thought it should be, too! How the heck did I miss this?!?! Way to go Ryan! EDIT: Just tried it out. Only thing I would add to this is the ability to use any other field (rather than just the title field) as the name, or to just use the page id as the name. I'm not using a title in some of my templates since it doesn't apply.

Sorry for dragging up an old thread. Has anything more come of this? I'm with deane.barker-- If the page you're creating has no global fields set/is set to ignore them and there's only one template option available, there should be a way to make it into a one-step process. When pages are being used just as data containers (i.e. for storing images), having to go through that extra screen can get old really fast. Some kind of method of custom auto-generating names would also be hugely valuable. For example, all children of the "gallery" page could auto generate a default name like img001, img002, img003 based on a pattern you give in the parent template's "Family" tab. If no pattern is specified there, you could just use the page ID. This is also where you could add the setting for "Create child pages in one step".

This may not be the right forum for this... but I noticed that $fieldgroups are missing from the API cheatsheet. This is kind of important for developers since you can't create templates using the API without knowing about fieldgroups and how to use them.

Yeah, in that instance it seems appropriate.

Thanks netcarver, I did some reading on dependency injection this morning. Would it be correct to say that avoiding $this->modules->get('myModule') from within my module code would be more efficient since I can bypass an unnecessary database query?

I've been starting to dip my toes into the oop world, and am hoping to start some module development for PW soon. Right now I understand many of the principals and concepts of oop, but once the rubber meets the road and I start trying to build/modify something, I have some trouble putting things into practice. Right now I'm trying to figure out how to architect modules with multiple classes (in separate .php files), similar to Ryan's formbuilder module. One of the things that's confusing me is how to work with an object (think of a Shopping Cart or Form) that needs to be used by multiple classes in the same module. Right now I am thinking of using the .module file itself as a "controller" and instantiating the shared object as a property of the module object (ok so far?). Since I need the ability to use $pages and other PW API variables, I am extending all my classes from Wire or WireData. This means I can reference my shared object from my external classes using $this->modules->get('myModule')->myObject. But is this a good practice? Shouldn't I instead be passing my object into the other objects as a parameter to reduce coupling? If so, should I be passing it in the constructor and making it a property of the new object, or as a parameter on each method call? Also, I will need to access the main module's settings from within my external classes. I could do this using $this->modules->get('myModule') or with a fuel variable like $myModule that I set, but both of those seem wrong to me. And from what I can make out of the formbuilder module, Ryan isn't doing this kind of thing (although I could have missed it). Which leads me to my question about PW's architecture... I'm having a tough time grasping how the Wire/WireData class is used. My n00b understanding of inheritance is that it's supposed to represent an "is-a" relationship. From my understanding, many of PW's classes extend the WireData class to have the functions available to access the API... but this doesn't seem like an "is-a" relationship. It seems to work well, though, and I'm not sure what the alternative would be... Maybe just instantiating a WireData object any time you need to use its functions? So, as you can see... OOP n00b needs halp!

Thanks-- I was just looking for this

No, I didn't really need the module in this case, so I didn't pursue it any further.

Works like a charm, thanks Adrian!