Joss

Just looked him up on Wikipedia - reminds me of my brother's ex boss from the 70s, Ed Ross who invented the statistical surveying software Quantum. Not sure I agree with his views on PowerPoint though - seems he has missed the idea of being entertaining while presenting. More props the better, is what I say - and if they are over simplified and idiotic, better still. But then, this maybe why when I did some lectures on sound techniques I was more popular than the prof who proceeded me! (I point blank refused to give out briefing notes - why spoil the surprise?)

Strangely, I was looking this up yesterday! Doesn't that limit characters? If you want to do words: $text = implode(' ',array_slice(str_word_count($post->summary,1),0,$maxpostlength)); Where $maxpostlength is the number of words and $post->summary was the field I wanted to truncate.

On your second point, I would always go the two field direction - it makes it very clear to the user what they are expected to do and you can have fun later. You can add custom classes to TinyMCE on the configuration for the field, though you need to be very specific with your needs. Generally I would avoid unless there is something special you want to add. You can also use JQuery to add classes to specific elements, as long as you have them identified clearly enough. As an example, I use that to add the class "fancybox" to all <a> tags that are wrapped around images within a certain area of my template. $('.blogpost img').closest("a").addClass("fancybox ").attr('rel', 'group'); That finds an img tag within my blogpost div then adds a class and attribute to the closest a tag. Then, in tinyMCE when you add an image, just make sure that you tick the "link to larger image" in the image modal. However, most of the time, things like my main images are separate fields and not added to the text in the form - again, it is clearer that way and less likely to cause issues. ###### On your first point, I am not totally sure why you need a repeater, so I will ignore that for the moment! It is perfectly fine to let the user choose an icon for the beginning of a title, or whatever. While it is important to control how creativity affects the layout of a site, you shouldn't stifle it either unless they have a full time editor to do the hard work! Just use a Page field for this job. Create a hidden page somewhere on your page tree and call it Icons. Give it a template that has no file associated with it. Now, create a series of pages - each title field represents an icon. Create a pages field for your article template - it should be for a single select (third option on details) and just a normal select box on the input tab. Select your icons page as the parent. When you create a new article you can select the icon from that page field. In your template, just set up a series of conditions referencing the page field. if($page->page_field->name = something) { echo "My Icon"; } and work your way down the list. You can read more on using the page field for creating select lists here: http://wiki.processwire.com/index.php/Page_Field If you want your reference to be different from the title in the drop down (if your titles are a bit descriptive, perhaps) then create a second field in your icons page and use that for your reference. Does that help? Joss

Yes, "Deutsches Processwire" is not so comfortable to say. What ever you choose, it should survive being said out loud - strangely, it makes it easier to read in your head. (Old writer's trick) We don't actually need a British English version, but if one were created it would probably be called ProcessWire UK. So you could always go for ProcessWire FDR - Is that ever used like that in Germany? I am having a lot of fun rolling the R in Process in my head! Sounds cool...

Ryan, for a completely different reason, that was a really useful little tutorial!

Possibly "ProcessWire Deutsche" without the website? Or even ProcessWire Deutschland Perhaps just ProcessWire.de

Well, it is about adapting the images to the viewport, which is strongly related to responsive layouts. I have always felt that it is not just about file size (though with more 4g licences granted today in the UK, that will slowly become less of an issue), but about how the image works a design sense as well. If the up side of responsive layouts is their adaptability to the viewport, the downside is that does not necessarily mean that the "adjusted" layout is the best use of the smaller viewport. Adapting the image both in physical dimensions and in chosen portion is one step towards getting that better. Now I have to run off and rewrite half of my blog system to practice what I have just preached .... damn!!

Of course, this also depends what framework you are using. For instance, if you use the Crop image field and then associate that with Bootstrap, you can specify using different thumbnails for different media queries. In addition, you can add classes in Bootstrap to either show or not show elements for various devices. (Other frameworks have similar approaches) Mixing and matching this way allows not only different sizes, but because of using the crop image, you can also change the area of the image viewed. So on the desktop the thumbnail image might be a landscape, but on a phone where that would bad, you would have a close up of one distinctive element in the image. It has been one of the joys of the Thumbnails plugin that I can easily spend time thinking about not just what size an image should be, but also the context - whether that is in relation to the surrounding text, or the size of the browser.

See ... you used "content" !!

Yep - definitely over-nerded there! The trouble is, I am not totally sure why the first version works, let alone the long version! I ought to find out at some point and write it up - it is one of those useful techniques that should be not just buried in the forum. As for the code blocks - yes, they can be very ...... roomy!

I have no idea about this really, but I would think you would normally add these manually to the template for the form. Generally speaking, PW doesn't force you to load anything unless you actually want it to! At least, not in the front end, which is seen as your domain rather than PW's domain. Which is unusual and rather welcome On the other hand, this might be something else entirely....

Not a problem, mate! I will try and find the old posts from Ryan that you talked about Thanks! Edit: Okay solved it! It is still a tiny bit limited, but perfectly useful. So, on the mother page: $items = $pages->get("/content-management/widgets/")->children; // some widget page foreach($items as $item){ $item->calledfrom = $page; // save current page from where widget is rendered } It was worth a shot just trying it. Thanks again Soma.

...party How would css generate a "1" without using content? It feels a bit like a count, I must admit. Is the page publicly viewable?

HI Soma Okay, that worked! I boiled it down to: On the mother template: $item = $pages->get("/content-management/widgets/sidebar/"); // some widget page $item->calledfrom = $page; // save current page from where widget is rendered on the widget template: getChildCategories($page->calledfrom); The next question is: Is there some generic way of passing this value from the mother page to the widget page without having to start by specifying a particular widget page? I suspect there isn't, but I need to possibly render up to 6 different widgets like this that are doing different functions - it would be nice to have some way of covering any function in one hit - so one value that basically is the mother saying "this is me" that I can use in any widget that is rendered into that page.

Here is a simpler scenario that may help - if I can get this to work then the original problem should fall into place. I create a widget template that has the following code in it. echo $page->sidebar The widget is called into another page (call it the mother page) using a page field. The output of the page field simply uses render(). The sidebar I want to display belongs to the mother page that the widget is called into. At the moment, it displays the sidebar field belonging to the widget template (well, it would if the widget template had one!) That is how it is meant to work, of course. So, WHAT do I echo so that I get the sidebar field belong to the mother page that has the page field that calls in the widget? (You know, however I write this, it always comes out as "there was an old lady who swallowed a fly...") Joss

A complete aside: Just working on a blog profile and I am thoroughly enjoying the plugin! So thanks! Thought I would just say that. Joss

Indeed! I think this is possible because your location is a sub domain. You should also read this: http://www.000webhost.com/faq.php?ID=16 I just had a look in the 000webhost forums, but it seems that it is full of rude idiots - but then, it is host to loads of phishing and other scam sites, so no surprise there!

Just a thought, but that is the ID of the home page - 1

There can be many. The page field is a multiple select. The templates of the various widgets vary and are mostly the normal markup of title, text and so on. For this particular widget, however, the template has the title field but also the getChildCategories(); function call. However, that function thinks it is talking about the widget. There must be a way of declaring a global on the category page which can then be passed to the widget page and thus to the function. But I cant seem to break through the barrier between the category page and the widget page. Obviously there has to be a barrier there otherwise when I call $page->title on the widget template file I would end up with the category title - and I don't or course.

Have you checked within any PHP you might have at the very head? Before the opening <html> If that is echoing out anything, it can appear at the bottom. Oddly enough.

Thats a pity - I had hoped you had a stray sub directory in there. And you didn't change the name of the admin page when you installed? There is an option for it - it doesn't create an actual directory, just changed the name of the admin page.

Okay, I am starting at this and getting lost in my own work flow. So let me try and write it out see if I can make sense of it. Remember, that in this, all the functions actually are in a single included file, but that might not matter. So... 1. I have a category page that I am going to view. 2. In the category page I call a function that retrieves pages (widgets) that are listed in a page field within a central setting page. function categorySidebarWidgets() { $categoryWidgets = wire("pages")->get("/content-management/settings/site-settings")->site_category_sidebar_widgets; foreach ($categoryWidgets as $categoryWidget) { echo $categoryWidget->render(); } } 3. The page field select a widget that has its own template and template file (obviously) It only has a title field. 4. In the widget template file I call a function getChildCategories(); 5. The function lists out the child pages (sub categories) of the category page I am viewing (That is the function I talked about earlier) Currently I am doing it exactly as above. If I ignore all that and just call the function into the category template, then it lists the category page, followed by the children. However, If I do it as above, it lists the widget page, not the category page. It doesn't list any children since the widget page doesn't have any. Does that make sense? Sorry, this is a really mad route round! But it means that the widget position and location can be managed through the admin - so there is some good reasons behind the mess! Joss

hehe - I need to rebuild the system I tried this with. Once I do that I will be able to try these. I hadn't thought of calling it like that.

Moved the wiki article to http://wiki.processwire.com/index.php/URL_Segments_in_category_tree_example

Not sure. I will have to try I think the problem is that the function is not actually called into the main page, it is called into the widget page. So when you ask for $page you get the widget. Because this is used in lots of different main pages, I cannot give it a specific page, only the page it ends up being rendered in, if you see what I mean. By the way, thanks for your help on the URL segments - I have now written that up on the Wiki.