Leaderboard

MarkupSocialShareButtons This module outputs a list of share links for the following services by default * E-Mail (kinda extra) * Facebook * Twitter * Google+ * LinkedIn * Thumblr * Reddit (off by default) * Pinterest (off by default) Usage examples echo $modules->MarkupSocialShareButtons->render(); This outputs a simple UL list with links <ul class='MarkupSocialShareButtons cf'> <li class='mssb-item mssb-facebook mssb-popup'><a href='url'><i>facebook</i></a></li> etc ... </ul> Config Screen See more details and examples on github or modules directory https://github.com/somatonic/MarkupSocialShareButtons http://mods.pw/8j

You shall not objectify people, but you could objectify Textfields!!! Github: https://github.com/owzim/pw-fieldtype-yaml Module page: http://modules.processwire.com/modules/fieldtype-yaml/ Summary Field that stores YAML data and formats it as an object, when requested. Setup After installation create a new field, let's say called "people" and assign it to a template, or just edit an existing text-based field and choose Yaml for the type, save! In the Details-Tab you have an additional option, the Texformatter option is removed, because it does not make sense in this case. Parse as Default is WireArray/WireData, the data can also be parsed as Object or Associative Array. Associative Array is the fastest and the default output by the used Spyc parser, WireArray/WireData might be the slowest, but it's also the most feature rich. You can access properties like you are used to with pages or fields, like $page->person->get('title|name') or $page->people->find('age>30'). Usage Now, in your just created field you can put in some YAML like this: - name: Jane Doe occupation: Product Manager age: 33 hobbies: - running - movies - name: John Doe occupation: Service Worker age: 28 hobbies: - cycling - fishing In your template, or wherever you are accessing the page, you would use it like any other ProcesssWire data (if you set the parse option to either WireData or Object): $out = ''; foreach ($page->people as $person) { $out .= "Name: {$person->name} <br>"; $out .= "Occupation: {$person->occupation} <br>"; $out .= "Age: {$person->age} <br>"; $out .= "Hobbies: <br>"; foreach ($person->hobbies as $hobby) { $out .= "- {$hobby} <br>"; } $out .= "--- <br>"; } echo $out; More info about YAML: Complete idiot's introduction to YAML Specification Wikipedia Acknowledgements I've used a namespaced version of the Autoloader class from Template Data Providers The YAML parser is a namespaced version of Spyc Edit: updated the repo link

I think the big difference between the points of you both is in the definition of docs. Lisandi sees them as documentation for the CMS as a whole. So there are docs about the UI, modules, for admins, for designer and so on. Because each of them has to somehow work with the cms, while each need to learn different stuff. I would consider most of this information as bloat for the actual cms. Designers and Developers do have enough resources here on the site and clients should have no hassle with the basic UI functionality of processwire after a bit of initial introduction. Joss on the other hand is talking about a documentation the developer/designer is setting up only for the user/client. This is very much sitespecific as even most modules can be used differently on each page, not talking about different sitetemplates. One could see them as site maintainance guidelines / helpers.

Thinking about things like opencart and so on, one thing I think could be very important with a PW cart is that it does not necessarily come with too many customisations via admin. So, in its basic form, you would customise the way it renders just as you would with any other processwire site, rather than have to create bits of layouts that then have to be chosen in the admin and so on. It is not that I think those are a bad thing in themselves, but that sort of customisation can make the file/template system a nightmare. One thing that I always like about the early paypal cart system was that you shoved one line of code where you wanted the button for each product in your static site. That made things pleasant! So, I think there could be two levels here: Apeisa's approach where the creation of the catalogue and how it works is down to you and the hard-core functionality is supplied by modules. A profile based on the above that has a prebuilt catalogue system and maybe more of the look and feel functionality of Opencart, Prestashop and so on. I think for a lot of people in here the first would be popular because we each have our own idea of how a catalogue should be structured

Because it is within a php echo statement already, this will work: <img src="{$config->urls->site}assets/images/IcoMoon/Icons/SVG/globe.svg" class="logo"> To expand on owzim's comments, I try to avoid escaping double quotes. Use a mix of single/double quotes to make it cleaner. So you could have: echo '<img src="'.$config->urls->site.'assets/images/IcoMoon/Icons/SVG/globe.svg" class="logo">'; or: echo "<img src='{$config->urls->site}assets/images/IcoMoon/Icons/SVG/globe.svg' class='logo'>";

That's why I use a different browser for dev than for web browsing

Sorry for wasting your time!!! Triple facepalm!!!! Agghhhhhhhhhhhh!!!! Bitten once again!!!! I am going to hide under a rock and will not come out soon. ABP - guilty again! Your module works a treat! See example below, working together with Blog Module. Will post example code later in Blog thread...Thanks!

Finally got that fixed. I had downloaded and installed "AdminRestrictPageTree" and assigned to "guest" and "manager". I assumed it would just hide the actual full tree leaving my listerpro lists of pages i want managers to be able to edit. No idea why guest is in there as they can not access that page anyway. Instead it rendered everyone unable to login due to a page redirect loop. I guess the issue was my own fault, I did not have a page to redirect them to, as I did not understand it was going to stop them getting to the admin page altogether. Guess that will teach me to be sure i know what i am doing with contributed modules. Have removed that module now after editing database to remove restricted roles and once again gaining access to the site admin. I guess the reason I could no longer get in was due to the guest role being added to restricted users.

Yep, they are all there. You need to press the advanced tab to show the system ones.

Hi! Look for Custom Editor JS Styles Set in the field configuration and enter a path for .js file. In this file you can define your custom styles like this: CKEDITOR.stylesSet.add('mystyles', [ // Block-level styles { name: 'Heading 1', element: 'h1'}, { name: 'Heading 2', element: 'h2'}, { name: 'Heading 3', element: 'h3'}, { name: 'Introduction', element: 'p', attributes: { 'class': 'introduction'} }, // Inline styles { name: 'Link button', element: 'a', attributes: { 'class': 'button' } }, { name: 'Highlight', element: 'span', attributes: { 'class': 'highlight' } }, // Object styles { name: 'Stretch', element: 'img', attributes: { 'class': 'stretch' } }, ]); Also make sure you have Styles toolbar item enabled.

"Ello, goodbye": https://aralbalkan.com/notes/ello-goodbye/ I despise Facebook and only use it every now and then when a friends groups discussion makes it necessary. I almost exclusively use Twitter, but not too much for networking but for news on politics, webdev, web/tech in general and to share links or the occasional rant.

Sorry for disappointing you.. I changed it to alpha. I tested it with some jpgs I uploaded on my local PW installation and there everything worked fine. I'll take care of the points you mentioned and update this post here afterwards.

Lately there have been lots of people that are not enjoying the default admin theme, so we've been working on making something new. Not trying to solve all issues or add every new feature we'd like, but just trying to come up with something to have as an interim replacement for the default admin theme until we can afford the time to do something broader in scope (like Phillip Reiner's great admin theme design for example). So this theme doesn't necessarily break a lot of new ground, but hopefully has some of the improvements that people are looking for. Visually, the goal here was to find a lighter, more modern look and reduce the boxes-in-boxes feel of the current admin theme. I've opted to commit it to the dev branch because it requires the latest version of ProcessWire on the dev branch, and likely will continue to with updates. Meaning, I can't distribute this one as a 3rd party theme very easily. This is because I'm making core updates related to the admin theme at the same time. So if you want to help test this new theme, you'll need to grab the dev branch of ProcessWire. The new admin theme is in /site-default/templates-admin/. That means you'll see it as the default theme if you are installing a new copy of PW. But if upgrading an existing copy, you'll continue to get the old theme. If you want the new theme, then just copy the /site-default/templates-admin/ directory to your /site/templates-admin/ directory on your existing PW install. This would be in addition to replacing your /wire/ directory with the latest one from dev, as usual for PW upgrades. The existing default admin theme also remains in place in /wire/templates-admin/. So if you want to stick with the existing/stable admin theme, then just make sure you don't have a /site/templates-admin/ dir in place (unless you are using a 3rd party admin theme). This admin theme is probably not production ready, as it's not been tested in many browsers yet. I personally haven't yet tested it in anything but Chrome and Firefox in OS X. Please let me know if you experience issues in other browsers. I fully expect things won't be pretty in IE... but they never are. To start, this comes with 3 color schemes (though we'll be adding more too): Warm: Modern (similar to processwire.com site colors): Classic (similar to existing admin theme colors): To switch to one color theme or the other, specify a GET variable of 'colors' in any URL you are accessing in the admin: /processwire/?colors=warm /processwire/?colors=modern /processwire/?colors=classic To specify a default, edit your /site/config.php and set to one of the following: $config->adminThemeColors = 'warm'; $config->adminThemeColors = 'modern'; $config->adminThemeColors = 'classic'; We'll probably make this switchable in the user profile at some point, but that comes later. This theme also comes with some new features (most of which have been copied/inspired from the work of others here, whether in other admin themes, modules or designs): It now uses Font-Awesome icons rather than jQuery UI icons. We now only use jQuery UI icons for actual jQuery UI widgets. Note that asmSelect and our file/image inputfields are built as jQuery UI widgets, but I don't think anything else is. Basically, the majority of icons in the system are now Font-Awesome icons. You can associate Font Awesome icons with templates. When associated with a template, the icons will appear in the page list, in front of the page title. To use this, edit any template and go to the Advanced tab. In the "List of fields to show in admin page list", you can type in any Font Awesome icon name (in addition to the field names you could before). For example, in the Page List screenshots above, I have my "search" template configured with the value: "icon-search title". You can associate Font Awesome icons with fields. When associated with a field, the icon will appear at the beginning of the input. For example, I associated a coffee icon with my "title" field in the screenshot below. To do this, edit the field, click on the Advanced tab, and enter the icon name in the new field provided for it. The top navigation now supports simple dropdowns. A new "user" dropdown has also been added that contains profile and logout links. The main Pages screen contains an "add new..." button, that is itself a dropdown to a list of templates that are configured adequately for us to know where they would be added. To use this, you have to configure your template "family" settings. The search box is now ajax powered, though this was introduced a couple weeks ago in the existing admin theme too. The theme is responsive too, of course. This is all kind of preliminary and open to changes. I'm trying to keep the scope of the project fairly small since I don't have much time to work on it. But just wanted something to quiet the haters a bit for a little while, so that we can take our time on the bigger admin theme project for longer term. We'd appreciate your feedback if anyone has time to help test.

FrontendUserLogin Module to handle frontend user login / logout. Also should work with Persistent login for users (mode: automatically) out of the box Version 0.3.1Requires PW 2.5.5 (fields defined by array) Download Processwire module page: http://modules.processwire.com/modules/frontend-user-login/ Bitbucket Repo: https://bitbucket.org/pwFoo/frontenduserlogin/ Usage Readme file Module isn't available anymore, but it's planed to replace FrontendUserLogin and FrontendUserRegister with the new FrontendUser module which is not released yet. A new support topic will be created after FrontendUser module is added to the PW module repo. FrontendUser module

So I suppose this is a somewhat pointless addition, seeing as drafts are about to come to the core, but I needed this right now and ProcessWire made it possible for me to implement over the last two days. An experience that convinced me once more that ProcessWire is absolutely amazing. GitHub link. So what does this do? This module allows you to create a draft version of (hopefully) any page, which can be edited while the public facing page remains in place and unchanged. Drafts are placed under a special Admin page, which also doubles as a rudimentary manager. It shows what pages have drafts assigned and lets you update the original page with its draft. I need all this mainly for front-end editing, so for me the focus is on the added API methods. I have added functionality to redirect every edit to a draft page for testing, and it can make sense to have that behavior of course, so it will probably become a config setting. How does it do that? Page cloning is very very handy for this purpose, so that’s mostly what I’m doing here. It’s elegant in that very little code is needed, but it is perhaps somewhat crude to delete pages, including their field data and files on the file system, so much. I needed some hacky-feeling tricks to convince PW to delete pages that have children and clone pages to my custom admin page even when their template prohibits that sort of parent. What doesn’t this do (well)? Since a draft is linked to its page by having the page ID for a name (!), which conviniently also guarantees uniqueness, modifying page names should be pretty much impossible. It would be best to create a table to store the references, but I kind of like that you can keep everything 100% PW API. The most complicated fieldtypes I have tested this module with are Images/Files and Multiplier. That covers my immediate need, but perhaps PageTables will cause problems. I don’t have any experience with those. There are probably a lot of other things to look out for, but I can’t remember any more right now. Be aware this is most definitely not production ready or anything. I would like to thank Teppo Koivula, whose Changelog module I used for inspiration downright based this on. Great work there, and a lot to learn from. If you find fragments of Changelog in this module, that’s no coincidence. Also hugely helpful are the great members of this forum and Ryan’s code, which I assume we all use as our main documentation <3 Please absolutely tear this apart, if you can spare the time to have a quick look. I like to think I did okay, but I’m eager to learn and I’m sure this is full of questionable practices, bugs and inefficiencies. So yeah, its unlikely anyone will have the need to use this on a site, but hopefully I can get some feedback out of it and perhaps it can teach other beginners like me a trick or two. GitHub link again. /wall of text

If it is related to that what was asked here a few days ago, we may find it via google Look to the post from Fokke!

The path is the same inside as outside of PHP. Fun time. Good suggestions by the young entrepreneurs. You can also use echo "{$config->urls->assets}/images/IcoMoon/Icons/SVG/globe.svg"; I thought more it was about loading a file within PHP on server using path $file = $config->paths->assets . "/images/..";

Is that a question??? You don't know what Ryan has under his sleeves. Fun times ahead.

This should work if the file is really there. Try to inspect the html output and check if the path is generated correctly. If so, copy the url into the address bar and check if the image is really loadable. Perhaps something with SVG having the wrong mime type from the apache? Other than that I'd just create a new config setting: $config->urls->icons = $config->urls->site . 'assets/images/IcoMoon/Icons/SVG/'; And include the icons like so: <img src="<?php echo $config->urls->icons; ?>globe.svg" class="logo"> Your code is very unreadable, try to organize it better. Don't mix the output methodologies too much. EITHER you echo out php in your html OR you echo out HTML in you PHP, don't use both methods at the same time, or at least avoid it at all costs. I would not want to be maintaining this, and neither should you Just advice.

That's great and will surely become handy soon. May i suggest namespacing the css classes? Item, Facebook or Twitter are classnames that are potentially already beeing used across several frameworks and applications.

No problem. I was waiting for your facepalm post Looks nice!

I'm not seeing anything here. Well I'm innocent and it doesn't make sense as there is nothing. Have you installed ad blocker or any plugins ? What browser?

Hello, PageTable is described as a leaner way to enter large amount of repeatable data into the admin backend, possibly with different sets of fields (think different templates). The main advantages compared to the Repeater are: 1. PageTable can save new pages where you tell it to. Repeaters are saved deep down the Admin pages and are given cryptic names. 2. One PageTable field can make use of several different templates. Repeaters play according to the "One repeater = one template" rule (roughly put). PageTable is a PageArray, so relevant methods are applicable. For example, here is how to add and remove items from a PageTable field using the PW API: // create a new page // IMPORTANT: your PageTable field must be configured to use template 'basic-page' in the field Setup tab $newpage = $pages->add('basic-page', '/about/', 'address', array('title' => 'Write to us')); $page->of(false); // add the newly created page to 'pt' which is a PageTable field $page->pt->add($newpage); $page->save(); Here is how to remove the first item from a PageTable field: $page->of(false); // 'pt' is a field of type PageTable $page->pt->get(0)->delete(); $page->save(); That's a quick overview of this new field type. Give it a bit of your attention, it's quite promising. Cheers, Valery.

To be honest, part of this is plain laziness - by all of us. What I keep trying to find time to do is to create a really good catalogue as a starting point - and that can be done in PW without any additional tools. And THEN look at what I need. I suspect that the hill will be less of a climb once the first bit is done. So, perhaps the REAL conversation should be: what is the ideal catalogue structure in PW? And then go and do it.

I'm a total nobby no-mates over at ello.co so if you'd like an invite just check my sig' below PS: Posted because I grew up watching BBC TV not ITV and so when I began to see commercial television I found it particularly painful to have adverts inserted where TV programs always went when I was solely watching the BBC. Fast forward a few decades and now I find it equally painful to be browsing Facebook only to be kicked in the eye by an advert. Add to that the UI/UX disaster that is the Facebook experience and I am left detesting it but not having much in the way of an alternative. Enter ello.co. OK, I am being a bit optimistic, it's more than somewhat early days over at ello.co but it has the same sort of ethos as app.net, not going to spray me in adverts and also its got a rather lovely UX. OK, rantette over, hope to see you there and hope in the long term ello takes off enough so I can delete my Facebook login. Cheers, -Alan https://ello.co/alanfluff

Nice! I just did all this (build SN links) manually with a new site last week... Look forward to checking this module out...

Yeah, I have completely given up on running local dev servers altogether. The Grunt script includes a small local web server just to be able to server HTML files because sometimes JS won't work properly without a server. As for the whole MAMP/xampp/local Apache thing, I feel it's just not worth the effort. You only end up either having to deal with things that are set up entirely different on the live server or doing duplicate work. I also don't want to fill up my hard drive with endless local versions of projects (I'm working on a MacBook Air with a rather small SSD, so hard drive space is kind of precious). So if I ever need a staging server (if only to be able to show clients work in progress), I use a dedicated stage on my Uberspace for that. Uberspace is a German web hoster which offers a really neat and convenient server setup including ssh access, so it's very easy to quickly setup a stage there. Of course, that means I can't do some work if I don't have a net connection, but then again, if I don't have that, I usually don't work at all anyway.

For the Rabotheater website we implemented the JS / CSS method described by Jan Romero above. It's basically as simple as changing the outer CSS class of the items on mouseclick (as described by MuchDev). The CSS takes care of the rendering of said class and displays a listview or a gridview depending on the outer class. Using Firebug in Firefox (or something equivalent for other browsers) you can easily see changes made to the source on toggling between list and grid view. And you can also see which CSS renders the items.

I have played around with different views using just some basic jquery. If you are feeling a bit overwhelmed just start small. Here is a fiddle I found that really simplifies the process of switching from 1 class to another. http://jsfiddle.net/v57JF/ Basically you just need to write the css and have jquery listen for a on('click') event on your buttons. When clicked apply class to all divs that you want to be formatted differently. Having settings stay between page refreshes and next pages is a bit more tricky as you would have to most likely use some ajax as they said, but if you getting looking pretty, you should be able to build on that fairly easily.

I'm a old bloke and doesn't get really disappointed by this. But sometimes it seems to be helpful to raise the voice and threatening with the finger. You normally publish much, much better work! If you are interested in this EXIF stuff, you should get you ExifTool, a (platform independant) Perl library. Here a download from heise, - and there is also a GUI available for Win and there seems to be some kind of GUI for Mac too. You can manipulate all Metadata with it, what enables you to create a good set of test images. Also don't forget to throw in some gif and png into your test set. ------ Above I have tested your 0.4.0 version. The enhancements with 0.6.0 is nice and useful. The best experience for the users would be if they can pass a single keyname or an array with keynames to the get method, I think. Then it return a single value or an associative array / or object. This module, once it is stable, or close to stable ;-) , it can be used directly in templates but also in other modules to read data and maybe write it into fields, for example on images upload. If you make it robust, it can (and should!) become the dependency for all following modules that want to handle EXIF data.

On the Rabotheater page the DOM doesn’t change at all. The buttons just change the class of the list, thereby changing the CSS. I would recommend this technique unless you want your views to show different data. You can solve the different presentations either for the entire list, or for the individual films. I would probably go with the latter: You have three templates for a film page: film.php – Just your regular page template to display a specific film. This is the only film template that is represented in the Admin. film_list_image.php – Only the markup for a list item showing the film and perhaps some relevant info in the “collage” style. film_list_title.php – List item markup including the film title and perhaps release year, review score, or whatever. On the list page, you render films using the $page->render() method with the chosen template as the first argument: $film->render('film_list_image.php'); You can switch between styles by reloading the entire page with Post, Get or urlSegment input, and perhaps store the preference in $session or $user. You could also load the films with AJAX and call $film->render() with the template there, then return the new markup to the list page. Of course, it might be better to return the film information in JSON format and build the presentation markup of choice with JavaScript on the list page. As you can see, there isn’t one technique that fits all. The CSS option is definitely the fastest, simplest and arguably the best way, provided you can keep the markup the same between both list styles. Just have a look at the Rabotheater site in your Element Inspector. Wicked fast, no DOM changes except one class attribute, no additional server requests. You could even animate the change. I only go into the other stuff because it incorporates ProcessWire and because it answers your question about having two templates for one page.

SFTP for sublime has many features like sync, monitoring etc. Quite handy. When I need it I use https://sublime.wbond.net/packages/LiveReload with the Chrome LiveReload extension.

https://github.com/apeisa/Finnish-ProcessWire I pushed a big update to the GitHub. Some parts are still missing, and there are certainly a lot errors to be corrected. Additional pull requests are welcome EDIT: I used PW 2.5.8 dev when creating this language pack. More coming soon! You can find the old translations for 2.4 here: https://github.com/apeisa/Finnish-ProcessWire/releases

On the field's input tab you can define a css file under "Custom Editor CSS File", although that option is only for Inline Mode, although that is what I tend to use most of the time these days anyways. Just quickly, this (http://ckeditor.com/forums/CKEditor-3.x/include-custom-css-ckeditor) might be relevant for regular mode.

"If it's translatable, it's meant to be translated". Just my five cents If Finnish translations continue to be hosted at GitHub, should we consider different ProcessWire versions there? Branch for each PW version, with master being "current stable"? Tags would work too, but AFAIK that would make updating earlier versions impossible.

I have a project boilerplate that I use in basically any web project these days. It's not specific to PW projects, but can handle those fine just as well (basically by switching from .html to .php files). The quick and simple run-down of what this includes is: a set of SCSS files and partials which are not really a CSS framework (I don't like using CSS frameworks) but rather a solid CSS baseline and some extends/mixins, some of them for a collection of jQuery plugins and JS snippets that I find myself using time and time again; most of these were chosen because they are developed in a very solid way and available via Bower (I'll get to that in a minute) some basic non-HTML/CSS/JS files like a .htaccess, a robots.txt etc. some Handlebars/assemble.io layouts and partials, just because generating HTML from Handlebars makes it so much easier to generate static HTML sometimes (i.e. includes for navigations etc.) A this is handled/tied together by a Grunt build script which takes care of way too many things to list here, but among other things, it takes care of combining and minifying CSS/JS assets, minimizes images, adds vendor prefixes to CSS, generates favicons and more. I usually start any project by building a static HTML prototype because I never learned how to design a web site in Photoshop or something. So even for PW sites, I will first build a small static HTML version, which hopefully covers and showcases all the page types/layouts needed later. That's my base for the PW templates. Edit: Right, forgot Bower. It's basically a package manager for web assets (mostly JS/jQuery plugins, but not exclusively). Makes it so much easier to keep your JS plugins up to date, I don't even remember how I did that before Bower. Based on node.js like Grunt, so that's required. For PW projects, I have a bare-bones template, which is just my version of the default template. Similar to the static boilerplate, this already includes some functions and page templates that I know I will use time and time again in projects. Or not. It is also already adapted to the static boilerplate, so it will work with its files and build script out of the box by just exchanging .html files with .php files. (Yes, while I type this I realize that it may not be that easy to understand as I think it is for, well, anyone but me.) Basically, I can just drop the templates files in the static prototype folder, adjust the build script a little and then convert static HTML into PW templates. It will use the same CSS/JS/image assets just fine. As for modules, as I said in the “your favourite modules” thread, I usually try to only use modules if I actually need them. So, no modules included here.

I had forgotten about this post, but check out this new module - coming very soon https://processwire.com/talk/topic/7723-protecteddevelopment-mode/?p=78233 Based on the poll results, it will probably be released as a separate module, named ProtectPages or something along those lines.

Something you have on API side which is simple really. $p = $pages->get(1001); $p->of(true); // if in a template code, turn off output formatting $p->images->add("http://placehold.it/350x150.jpg"); $p->save(); $p->of(false); Everything is possible. With a simple module. As a basic start add a text or url field to the template near your "images" field, like a text field "add_images_url" Now with a autoload module (like site/modules/HelloWorld.module) you add a hook to when the field has url it will store it to the "images" field (or any on the page). All you need is to enter url and save page. <?php /** * AddImagesFromUrl * * On a page with fields * "add_images_url" text field * "images" images field * */ class AddImagesFromUrl extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'AddImagesFromUrl', 'version' => 101, 'summary' => 'Add images from url to images field', 'href' => 'http://www.processwire.com', 'singular' => true, 'autoload' => "template=admin", 'icon' => 'smile-o', ); } public function init() { $this->addHookAfter('Pages::saveReady', $this, 'addImage'); } public function addImage(HookEvent $event) { $page = $event->arguments("page"); if($page->template != "basic-page") return; if(!$page->add_images_url) return; // now interesting part, anything is possible here if(strpos($page->add_images_url, ".jpg") != false) { $page->images->add($page->add_images_url); $this->message("Added image from '$page->add_images_url' to images field"); $page->add_images_url = ''; } } } https://gist.github.com/somatonic/49f9e0a7faa8f6e6cfa3

Give me a couple of minutes...will post a solution... Confirm, do you want the URL to the pages even though the 'title' will actually be the $page->client? --------------------------------------------------------------------- Edit 1 Something like this should work... $posts = $pages->find('template=post, limit=10'); $customUrls = array(); //custom array with $url => $label pairs (url= page url; and label = value of page->client [text]) foreach ($posts as $post) $customUrls[$post->url] = $post->client;//I am assuming $post->client is a text field? echo renderNav('Custom Links', $customUrls);//set the last two parameters if you need to, i.e. $currentURL and $mobile --------------------------------------------------------------------- Edit 2 By the way, above I assume you want to reuse renderNav() within the Blog profile itself. Remember it includes /markup/nav.php/ in line #277. If instead you want to reuse the function elsewhere without having to include nav.php, you can bring in the nav.php code physically into your (copied) renderNav() code. If this is too complicated for you, just copy the renderNav() code from MarkupBlog; it is the same code anyway . The Blog modules tutorials could also be handy. Here's is the renderNav() one.

There is now setting for this in latest dev.

Thanks adrian Sorry for the delay in responding, busy weekend. I know I've seen this thread before, thanks for reminding me... looks like it should do the job Between this and the Page Edit Per User module I should be all set

Hi everyone, I'd like to announce a complete overhaul of this module - problem is that I am not sure whether to release it as an update to this module, or perhaps as something completely new, perhaps called PageProtector. UPDATE: The functionality described in this post is available as a separate module: PageProtector This new version (not on github just yet) makes it very easy for site editors to set up various password protected areas on their site, or to simply protect a new page or section while they are still working on it. New functionality Ability for your site editors to control the user access to pages directly from Settings tab of each page Includes whether to protect all children of this page or not Optionally allows access to only specified roles Ability to change the message on the login page to make it specific to this page Option to have login form and prohibited message injected into a custom template Access to the above "Protect this Page" settings panel is controlled by the "page-edit-protected" permission Table in the module config settings that lists the details all of the protected pages Shortcut to protect entire site with one click What do you all think - replace the existing module, or release this functionality as a separate version? Module Config Settings Page Protection Settings

It's made 100% in PW and sent directly from this server using PW's WireMail interface with either Teppo's WireMailSwiftMailer or Horst's WireMailSMTP.

New version available. The module now has the ability to update the filename when a new thumbnail is created via the thumbnails plugin. This is important if you use Amazon CloudFront option to serve the files and want to show the changes you've made to the thumbnails immediately (without waiting for the cache to expire). Because when you create a new image crop it's filename doesn't change, I had to force this change in both the thumbnails files and the source file.

After going through the process of testing out PageTable fields I came to this conclusion as well, but I don't think it is obvious the first time you set up a field, especially given that "Select a parent for items" is closed by default and even when you open it, it reads "This is optional. If no parent is selected, then items will be placed as children of the page being edited.". I guess I think it might help if this was initially open and the decription or note field stated that a specified parent is the more common usage because of the issues that can occur with mixing in PageTable children with regular children in a URL accessible part of the site structure. I can see lots of dropdown menus containing PageTable children before people figure it out. But, maybe it's just me Anyone else initially confused?

I would avoid putting it in /cache/HannaCode/. What does your include line look like? If your class file were placed in /site/templates/includes/ (for example) then your include line should look like this: require_once(wire('config')->paths->templates . "includes/YourClass.php");

Few days ago I've posted sneak preview of new admin template (it didn't have name then), so I've managed to squeeze some time to finish it and here it is... Ergo Admin Template DOWNLOAD https://github.com/nvidoni/ergo USAGE 1. Create folder named "templates-admin" under /site/ folder 2. Copy all files (including folders) into newly created folder 3. ProcessWire will load the new admin template automatically EXTRA If you would like to use custom TinyMCE theme created for this template, follow this steps: 1. Download TinyMCE Ergo theme from https://github.com/n...ni/ergo-tinymce 2. Copy "ergo" folder to /wire/modules/Inputfield/InputfieldTinyMCE/tinymce-3.4.7/themes/advanced/skins/ folder 3. Open /site/templates-admin/default.php and change in line 86 "default" to "ergo" If you find any errors please post them here so I can commit them accordingly. EDIT 1. Changes have been made according to diogo's and Soma's posts.

[img=http://domain.com/photo.jpg]

Few things that are "nice to know" when building PW modules: Autoload and non-autoload modules: autoload ones are loaded on every page load. So if you need to hook into core, then you probably need autoload. Non-autoload modules are run only by request: $modules->get("myUberModule")->doSomething() When you need hooks? Well.. common things are "do something when page is saved", "alter the output that is generated", "do something before page is accessed" etc.. Actually there is quite a many hooks and best way to find right hook for you need is to ask for it here. Building modules is pretty similar to working with templates. Nothing "special" there. Few notes though: You cannot directly access the PW API variables like $pages, $session, $input etc.. Those are available at $this->pages or wire('pages'). If you have static method(s) in your modules then you need wire('pages') there - so if you want to play it safe always use that (it works on command line scripts also) Modules can have settings - those are very easy to implement (just look examples from other modules that have settings) Modules are cool. init() is run before page is loaded, so if your autoload module needs to know the current page, that is available at ready() method. Forums is your friend, just ask and someone (probably Soma with his quick editing skills) will surely help.

@Gazley, to answer your original question: I don't think that there are too many proper tutorials on module development available. At least I haven't seen any, so please, someone correct me if I'm wrong There has been some talk about proper module development documentation and/or tutorial though, see this topic for an instance. In my humble opinion that's something the community definitely needs at some point, preferably rather soon, because (IMHO) asking the same questions over and over or trying to dig all the tips from dozens, hundreds or even thousands of posts is not very efficient in the long run. Of course many of us like to learn from examples, but I'd still prefer to have common guidelines, frequent questions / problems, basic components and things like that explained in one place -- this would make it much easier for new folks to get into PW module development. Anyway, once you've managed to grasp basics of module development, why don't you share your tips for others too? wiki.processwire.com would be a great place for such content.