Leaderboard

I'm working on a module where I use MarkupCache within the module. Normally you would use MarkupCache in a template, but I fancied putting it in the module as it needs to use some 3rd party classes and it's just a lot of code to dump into a template. What the module does is my own version of pulling and caching X tweets from Twitter. The problem I had was clearing the cache when I'd changed the number of tweets to store in the module's config and saved the config. With help from netcarver it became apparent that you can hook into saveModuleConfigData, but it then took me a while to work out how to hook it. The answer was in InputFieldPageName.module on lines 134-7: static public function getModuleConfigInputfields(array $data) { $modules = wire('modules'); $modules->addHookBefore('saveModuleConfigData', null, 'InputfieldPageName_saveModuleConfigData'); So not in the init() where I'd been trying to put it, but in the getModuleConfigInputfields function instead. Because it's here though, you have to put the function that's called outsite of the class' scope, but that's not an issue really. In that same module you can scroll to the bottom and after the last closing curly-brace is this: function InputfieldPageName_saveModuleConfigData(HookEvent $event) { $arguments = $event->arguments; if($arguments[0] != 'InputfieldPageName') return; $data = $arguments[1]; $name = 'replacements'; if(!is_array($data[$name])) $data[$name] = InputfieldPageName::replacementStringToArray($data[$name]); $arguments[1] = $data; $event->arguments = $arguments; } You can still use the wire class from in there as well, so you can still pretty much do what you like. In my case it was this simple two-liner (setting the cache to 0 seconds effectively wipes it): $cache = wire('modules')->get("MarkupCache"); $cache->get("latest_tweets", 0); Just thought that might be useful to someone else in future So thanks again to netcarver, and also to ryan for having had the need to do this before and making saveModuleConfigData hookable!

You will have an idea of how powerfull PW's approach is when you start building your templates. I can give you some simple examples based on that tree: // you're on the homepage and want to display all the wines: $wines = $pages->find("template=wine"); // could also be $wines = $pages->get("/wines/")->children; echo "<div class='wines'>"; foreach($wines as $wine){ echo "<div class='wine'>"; echo "<h2>" . $wine->title . "</h2>"; echo $wine->bodycopy; echo "</div>"; } echo "</div>"; // you're on a wine page and want to display all the reviews: $reviews = $page->children; echo "<div class='reviews'>"; foreach($reviews as $review){ echo "<div class='review'>" echo "<h2>" . $review->writer . "</h2>"; echo $review->bodycopy; echo "</div>"; } echo "</div>"; // display a random testimonial on the homepage: $testimonial = $pages->get("/testimonials/")->getRandom; echo "<blockquote>" . $testimonial->quote . "</blockquote>"; echo "<cite>" . $testimonial->author . "</cite>"; // a list of events that take place in the garden of the winery, by descending date: $events = $pages->find("template=events, place=garden, sort=-date"); //and so on... edit: made the code a bit more clear, and corrected one variable

Hello there update v1.0.3 I just went through all and release an new fix update for latest changes in PW 2.2.+ 1. Some issues fixed with new inputfields css and form builder mainly. Also added a overwrite of the TinyMCE skin used by default in PW. 2. This is now also in the default.php's header to set the "default" skin to all TinyMCE inputfields: ... <script> // overwrite TinyMCE skin setting globally // as defined in /wire/modules/Inputfields/InputfieldTinyMCE/InputfieldTinyMCE.js // and loaded before if('undefined' != typeof InputfieldTinyMCEConfigDefaults) InputfieldTinyMCEConfigDefaults.skin = "default"; </script> </head> Hope this update doesn't introduce any new issues, but I've looked at all and √. Download as always from github. https://github.com/somatonic/teflon-admin-theme-pw2

Well you never can read enough and try So the correct version would be following. Here's what I implemented in my Teflon theme now. ... <script> // overwrite TinyMCE skin setting globally // as defined in /wire/modules/Inputfields/InputfieldTinyMCE/InputfieldTinyMCE.js // and loaded before if('undefined' != typeof InputfieldTinyMCEConfigDefaults) InputfieldTinyMCEConfigDefaults.skin = "default"; </script> </head>

When you enable url segments on the home template it will also render, ehm...non-existing pages from the docs: So we only allow urlSegment with the value "contact" and throw 404 when we try to go to any other non-existent page e.g. www.mysite.com/hahanothinghere/

Hi Guys, ran into this topic doing a Google search. I've been working on the blog for the past few months. Basically, it's to help out the community and have a database of quick scripts, ProcessWire developers, my friends and I can use. I appreciate you guys taking a look at the blog. Also, I'm open to contributors for new posts. If you're interested, please let me know.

I'm excited to announce that the ProcessWire Form Builder is now available from the DesignIntelligence bookstore: http://store.di.net/...re-form-builder I'm initially giving a 20% discount on the prices there (coupon code PWFB-BETA) because I'm still adding new things to it at a rapid pace, and feel it should still be called "beta test" (and not full price) until it's been out in the wild for a bit. However, a few of us here have been using the Form Builder on production sites for awhile already, and it's working great. But if you don't mind using a pre-release version and giving me feedback or suggestions where appropriate, then there's a nice discount for now (which will expire when we reach version 1.0). If you are wondering what the DesignIntelligence bookstore is, they are one of my long time clients and have agreed to let me provide the Form Builder through there. I actually setup and manage this online store already for them (and have for years), so feel very comfortable putting the Form Builder here. But when we grow big enough, we'll setup our own. When you get Form Builder, you'll also get access to the new Form Builder Support board (in this forum). This is where regular software updates are posted (ZIP files), among other things. So PM me when you do so that I can add you to it. Thanks for your support of ProcessWire and Form Builder!

I may be overcomplicating things in my head, but I'm trying to understand a few things about information architecture in PW. Perhaps the best way to get my question answered is by a hypothetical site. Say I'm building a website for a winery. It has a number of different types of information to display: Standard page data (headline, subhead, images, body copy, etc.) A list of wines that have their own attributes (varietal, vintage, price, description, image) Each wine has reviews associated with them, which have their own attributes (publication, author, score, link). Testimonials (testimonial text, author) that need to be randomly displayed on certain pages. A pagable list of events at the winery (sortable by date, etc.) How would I go about setting this information architecture up in ProcessWire?

Awesome! I know it probably sounds like I'm being all wary and stuff but I'm excited about working with this system/framework (and likely contributing modules to it). I like the UI a lot and its unobtrusiveness with regards to the front-end markup. Great work!

Yes, I get it, that makes sense. I think I like it. In my CMS I was dealing with similar issues; I had Nodes, which represented the main structure of the site, and then nodes were assigned node-types. The node-types were called 'Things' which were essentially Models - these were initially represented by an a collections of fields in an associative array, but eventually were stored in the database. Each Thing was basically an abstraction of whatever thing we were dealing with, whether it was a site page, a testimonial, a wine, or a staff member or what-have-you. And the type of thing determined the kind of behavior the node had. Some had many children of the same type, for example a node with the type of 'wines' would be able to create new wines, list the wines it had created, sort wines, etc. And some nodes had a one-to-one relationship; e.g. a node that had been given the node-type of 'site content' was able to edit the content for that page, and create new sub-nodes/pages. Anyway, I digress. One of the things I can't decide if I like about Processwire is that, since everything is a Page, your client can put *any* type of page as a child of any other page. It's simple, and probably most of the time it's a benefit, and it more simply solves some of the issues I was having regarding disparate content types along the tree structure. I really like the simplicity that that gives, especially dealing with URLs - in my CMS I had big challenges trying to figure out how to write fully semantic URLs. Overall I like it. It's weird seeing the different ways this system is dealing with the same problems I was having; I'm sure I'll have plenty more questions but it's really good to grasp the deep concepts first.

ProcessWire doesn't translate real well into the MVC pattern but at some points : Model. Represented in PW by a Template. Here you define your datamodel by adding Fields to the template. You can have as many models/templates you like. In PW 'pages' are modelled by the template that you choose when creating a page. View and Contoller. This is where a Template File come in. ProcessWire doesn't enforce a strict separation of output presentation (the view part) and controller logic. It gives you freedom to set things up to your liking and project needs. We've had discussions before about the slightly misleading nature of the term 'Page', and what it represents in other popular cms tools. Just think of Pages as data objects or Entities. An entity has one or more named properties (fields available via the page template), each of which can have one or more values. The value(s) a property can have depends on the field type (integer, date, text, page etc.) + what Ryan said

To the outside world (those accessing your website) everything is a page, accessed by a URL. ProcessWire is just trying to maintain consistency between the outside and the inside. All pages have a consistent set of properties and methods, but a Page derives its actual "type" from its template. So a Wine, a Review and an Event are all different types, while still sharing the common heritage of being a Page. A Page is basically a URL addressable container for data that has a parent and optionally children. But beyond that, everything about the Page's type comes from the template. Pages in ProcessWire are very similar in concept to nodes in Drupal (from what I understand). But nodes in Drupal are abstracted away from URLs whereas pages in ProcessWire are always connected to a URL. Even if that URL is tied to something you never intend to use as a renderable page on your site (and might not even have a template file), the URL is still a consistent, known way for you to refer to a page from the API, or wherever. A Page's URL is always reflective of its parents, meaning you know where a page physically lives in the tree based on it's URL. ProcessWire embraces the addressing system of the web, both on the front-end and back-end.

I was missing a few of the reserved words in the field creation process, honeypot being one of them. But hopefully got them all covered now. If you use a reserved word, it'll still let you, but it'll just append an underscore to the end of it so that there's no confusion.

WillyC's example just modifies the output of the $page->path() function (which is also used by $page->url). His intention there is to change what URL gets sent out when you call $page->url. It's really no different than making your own function and using it instead, except by using a hook like this, you can continue to use ProcessWire's API and get the result out of it that you want. Ultimately it's just a syntax convenience. While his hook example handles the URLs that get output in your markup, you still have to have something to look for and capture those URLs. Perhaps you could use mod rewrite, but typically you would use the "URL segments" feature that you see on the "URLs" tab when editing any template in PW admin. Lets use a simple example of your homepage template (home) with filename home.php. And lets say you want to make it so that when someone access domain.com/contact/ (a URL that doesn't currently exist) you want it to display the page that lives at domain.com/about/contact/. So you are setting up your site to respond to the shorter URL of /contact/ (rather than /about/contact/, where the page actually lives). Go to Setup > Templates > home > URLs. Click the checkbox to "allow URL segments", and save. Now edit your /site/templates/home.php file, and do something like this at the top: if($input->urlSegment1 == 'contact') { // render the /about/contact/ page echo $pages->get('/about/contact/')->render(); return; } else if($input->urlSegment1) { // throw a 404 throw new Wire404Exception(); } // otherwise continue normally and display your homepage.

If the page name were different, it would technically be a different page. We will find a way to do some kind of aliasing down the road, but it would involve some changes to the way that ProcessWire addresses and differentiates between pages. But it's doable. I'm just waiting for the simple solution to pop into my head and it hasn't yet.

Maybe it has been answerred before but when I'd try to explain what PW is I always say that pages are basicly collections of 1 type of stuff... And all those collections can be used from templates... Users is a collection of users and those users can be in a group which is part of the collection groups... But in PW it is called Pages. So basicly in your example you would have the following pages (collections) -Wines -Reviews -Testomonials So you make a few templates, a template for Wine, Reviews and testominials. You add some fields to each template -Wine --Title --Verietal(text) --price(float) etc etc and you make children in this pages(collection) 1 for each wine! and u add some review pages(a few pages into the collection) to each wine with a review template and u get something simulair to the tree diogo mentioned Not sure if i was completely right but this is how I have things ordered in my head... kind of

Definitely, documentation should carry through to other files, same as for Page. As for Fuel, maybe you should deprecate it? Getting rid of existing usages in the PW codebase is probably a simple search-and-replace? ... use @deprecated on the old member, and @see to link to the new member - having two supported API points for exactly the same thing isn't good for comprehension. To the original subject, I've tinkering with a module that writes out stub PHP classes like this one: <?php namespace templates; /** * @property mixed $title Title (FieldtypePageTitle) * @property mixed $link Link URL (FieldtypeURL) * @property mixed $published Date Published (FieldtypeDatetime) * @property mixed $icon Icon (FieldtypeImage) * @property mixed $body Body (FieldtypeTextarea) */ class Post extends Page {} The module will write one of these to a designated folder whenever you save a template - in your template files, you can then use @var annotations to fake out your IDE, which will then be able to auto-complete for fields. I know this isn't very useful or interesting to someone who doesn't use an IDE, but working with others on a team, this will save time - since you'll be able to open up a template-file and know about all it's fields without digging through an admin-screen This is very experimental and too incomplete to post yet, but the stub above was generated with this module...

..and maybe clear your cache and cookies once in a while.

You're right - ultimately, everything in PW is a page. Think of a page as a combination of a template (which controls the way said page is emitted in the frontend) and fields (which control which data said page has access to, although there are ways to access data of fields other pages use as well). (This, of course, is a pretty simplified version of what a page can be in PW.) For your client to add a new wine, he'd have to create a new page using i.e. the template ”wine” which could (this might be just one of the many ways of implementing this in PW) hold all the fields to store properties of the different kinds of wine. But there are many different types of fields available in PW to make this process maybe much easier than you'd first think. For instance, the varietals could simply be a select box which offers a limited selection of varietals to be selected in the backend.

The tree for this site could be something like this: -home --wines ---wineA ----reviewA1 ----reviewA2 ---wineB ----reviewB1 ----reviewB2 --testimonials ---testimonialA ---testimonialB --events ---eventA ---eventB Hope you can take some sense out of it. Take some time to study the API (have also a loot at the Cheatsheet), go through this small project walkthrough, and have a good look at the default install site. Ask any question here in the forum, I'm sure people will gladly help

Wow, tried this and it worked <script> InputfieldTinyMCEConfigDefaults.skin = "default"; </script> put it on the default.php of your theme after all the other scripts or before </body>

This looks like it should work to me. Just make sure you are executing all of this before you are starting output. If you find it's still not working, examine what values are getting thrown around in there. For instance, if($session->language) { echo "<p>Language is: $session->language</p>"; } Likewise, make sure that the names like 'it' are consistent with the actual page name of the language.

I don't think I will be contributing for the PW core in the near future. But would be nice to have some documentation on coding standards for those who will. Something like this: http://dev-docs.fuelphp.com/general/coding_standards.html

Well, thanks, but I intentionally build for PHP 5.3 ... my attitude is very simple: I build software for the future, not for the past. If I wasn't using newer PHP features, I wouldn't be using PHP at all - PHP has been playing catch-up the last couple of years, and has improved, but it's not exactly state of the art anymore. I don't think we further the use of PHP by showing the world what PHP code used to look like... You don't have to agree, but that's my philosophy Yes, the module definitely needs configuration options, I thought about the default icon setting too. As for the icon selection, I just did the quickest thing I could do - I might extend it later on, but for now, it gets the job done. PS: forking on Github is always good!

I was happy to see this has already been mentioned and is under way! Icons for templates would definitely make it faster for a content manager to browse the sitemap. However, I'll just briefly mention one small reservation/concern I have about this... I really like what this theme does - as far as using icons to indicate the state of an item, rather than the type of an item. For one, the state of an item is sort of unclear at the moment - I know the color-coding of items is supposed to indicate this, but most people I've showed PW to so far don't see to pick that up without some explanation. Another factor, is the fact that you're most likely going to have a high number of templates, and a low number of states - I personally find that icons are most useful when there's a low number of different icons. When you have a high number of different graphical symbols, reading pictograms starts to take more effort, and it gets to a point where there are so many types of icons, you simply start to ignore them. Just something to consider: perhaps it would be wiser to use an icon to indicate the state of the items. And rather than using icons to indicate the type of item, perhaps it would make more sense to use color-coded badges to actually display the template-name - something along the lines of the labels you see on e-mail items in gmail. The color-coding and varying width of the badges helps you recognize same-type items intuitively - as opposed to a large number of same-size (and probably same color-scheme) icons, which quickly turns into "icon soup". Just something to consider.

It's not possible at present to give other roles access to the trash. That is an area where access inheritance doesn't exist (since it's an anything-goes bucket 'o trash). It becomes a can of worms when considered in light of access control. Do you really want someone digging in your trash? A couple of alternatives: 1. Consider that /trash/ is just a page with children (albeit a smelly one). But you can just as easily make your own trash page. Rather than deleting pages, ask them to change the parent to your trash page (or drag their page into it). So long as they have access, they should be able to drag stuff in and out of it. If they pages they are dragging into it use templates that inherit access, and you make your trash page not viewable to guest, then any pages dragged into it are essentially removed from the site. 2. It sounds like you might be using trash as an unpublished area. If that's the case, I recommend just using PW's Unpublished status rather than the trash. 3. If you still want to use PW's system trash, you can create a template or module that lets them undelete stuff they've deleted. This isn't complete, but gives the basic idea: $deletedPages = $pages->get('/trash/')->find("modified_users_id=$user, include=all"); if(count($input->post->restore)) { $parent = $pages->get('/some/parent/'); foreach($deletedPages as $p) { if(in_array($p->id, $input->post->restore)) { $p->parent = $parent; $p->save(); echo "<li>Restored: {$p->url}</li>"; } } } // display list of their deleted pages and give them a 'restore' checkbox foreach($deletedPages as $p) { echo "<li><label><input type='checkbox' name='restore[]' value='{$p->id}' /> {$p->title}</label></li>"; }