Leaderboard

Small (but important update): Switched to percentages + adopted @tpr's markers (thanks!) + renamed .dot to .marker

I was looking for a more comfortable solution to add pages from a PageField Select. I ended up in this small module. Which is quite simple, but very useful. I created a PageField and another field of Type AddPage (requires FieldtypePageTable) with same settings for template and parent. Now I can easily add the page in the Modal. If you need it, take it as a Christmas Present from my side. (no christmas smiley available ... ) Dear Ryan, dear community, I wish you all the best for christmas and the upcoming year. <?php /** * Excellent side dish to Fieldtype Page. Doesn't store any data. Provides comfortable page creation. * * made by kixe (Christoph Thelen) 22.12.15 * Licensed under GNU/GPL v3 * * ProcessWire 2.x * Copyright (C) 2015 by Ryan Cramer * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://processwire.com * * */ class FieldtypeAddPage extends FieldtypePageTable implements Module { public static function getModuleInfo() { return array( 'title' => 'Fieldtype Add Page', 'version' => 100, 'summary' => 'Excellent side dish to Fieldtype Page. Doesn\'t store any data. Provides comfortable page creation.', 'author' => 'kixe', 'requires' => 'FieldtypePageTable' ); } public function init() { // prevent data storage $this->addHookAfter('FieldtypePageTable::sleepValue', function($event) { $event->return = array(); }); // unneeded configuration fields can be removed $this->addHookAfter('FieldtypePageTable::getConfigInputfields', function($event) { $inputfields = $event->return; $page_behavior = $inputfields->children()->get(2); $removes = array('sortfields','trashOnDelete','unpubOnTrash','unpubOnUnpub',$page_behavior); foreach ($removes as $remove) $inputfields->remove($remove); $event->return = $inputfields; }); } } Screencast

er314, I think your intentions are in the right place and I appreciate your determination. You are still asking for an established method with a specific purpose to have a different purpose and an access controlled front-end context, when that is not the purpose or full context of the method. So I hope you can understand why it's not realistic to just change the definition and implementation of an established method. But I get where you are coming from and think you've identified a potential helpful addition in the API, so I go ahead and add a "one" method or change the "findOne" method (in PW3) to behave as a "find just one" method with regard to access control, hidden/unpublished visibility settings, etc. While I don't personally think I will ever use this method, I think that you and Teppo have identified a couple of situations where some might find it handy. Even if one doesn't need it, perhaps just the presence of it in the API will further clarify the intentions of the methods as a whole, for folks that may have thought that the existing find() and get() were the same. I still worry a little bit about people forming an impression that PW's API is doing access control for them, when our entire API is based around providing methods for the developer to control access the way they see fit. The viewable() method is the basis of that. But we've already dipped into that territory with the find() method, and by adding the proposed method, we're not removing any control, just adding more options. So I think it's an okay. What I was stating is that I'm not aware of an instance where anyone has introduced security problems into their site as a result of using the get() method. Though you stated above that you did just that, so now I'm aware of an instance. You are correct that if a developer uses a $pages->get() method to retrieve a page that came from user input, and neglects to validate that the page is one you allow, then that could be a problem. But the same problem could surface anytime a developer neglects to properly sanitize or validate something–anything–that originated from user input. And this is not something you can skip regardless of what method you are using to retrieve a page or group of pages. Simply validating that a page is viewable does not mean it's valid for whatever operation you may be performing upon it. You would need to validate that it uses the expected template, comes from the expected parent, etc. So while we are adding a PW3 method to support your request, be careful not to get the impression that you no longer need to validate a page that originated from user input. Also keep in mind that a $pages->find() or proposed $pages->findOne() method that filters results is based on database-filtering, not runtime filtering. Part of PW's access control model supports runtime hooks to Page::viewable. If your situation includes any runtime access control options and pages you are loading as a result of user input, you shouldn't skip a $page->viewable() call regardless of what method you used to retrieve the page.

@ryan How about using this http://stackoverflow.com/questions/5716362/how-can-i-get-the-value-of-mysqls-ft-min-word-len-configuration-variable-usin to retrieve the value on install and maybe a setting somewhere, where it can be readjusted ($config maybe)? It's hard to imagine this value to change often.

@Pierre-Luc, if possible, you should update the compatibilty list of that module, - it only shows PW 2.4. All your other modules are up to date in this regard and shows versions inkl. PW 2.7

Hey, this is the exact use case why I made the http://modules.processwire.com/modules/process-field-generator/ module. It will generate crypto safe strings to use as page names (you don't have to expose the page id, especially with the combined use of urlSegments as a view handler).

After some puzzeling you found out how to do a navigation with PW https://github.com/ryancramerdesign/ProcessWire/blob/dev/site-beginner/templates/_head.php#L28

Tom, there's a setting in MySQL called ft_min_word_len and the default is 4. That means that if you have any word in your query that is less than 4 characters, MySQL won't be able to match it unless that setting has been adjusted (and you've forced it to rebuild the indexes on your db/table). That's why you aren't able to match "Disability Act", because "Act" likely falls under your ft_min_word_len. You should be able to get the result you are looking for by using %= instead. But since you want to match "disability" and "act" anywhere in your search, you'd need to do this: template=document, title%=disability, title%=act The following code should use %= for words less than 4 characters and ~= for the rest. $search = $input->get->text("search"); if($search) { $selector = ''; $parts = explode(' ', $search); foreach($parts as $key => $part) { if(strlen($part) > 3) continue; // use MySQL LIKE for words under 4 characters in length $selector .= ", title%=" . $sanitizer->selectorValue($part); unset($parts[$key]); } if(count($parts)) { // use MySQL fulltext index for words 4 characters and higher $selector .= ", title~=" . $sanitizer->selectorValue(implode(' ', $parts)); } $results = $pages->find("template=document" . $selector); } else { $error = "Please enter a search term in the search box above."; $results = null; } Come to think of it, it might be nice if PW just did this for you automatically when it detected the condition... but we don't know what the ft_min_word_len setting is.

Right in time for Christmas for my client, a brand new Processwire website : Vip Air Limousine. Nothing too fancy in this one pager except it's always a pleasure to work with our CMS of choice !

apeisa since.u not like other avoter.i make for u i makes. unew one

hi everyone, i'm happy to share my first little module that could have broader use... use at your own risk! i'm quite new to module development Usage Just install the module and place your preview images in the folder /site/templates/TemplatePreviewImages filename = template-name.png Github https://github.com/BernhardBaumrock/TemplatePreviewImages Notes jquery image picker used in this module (MIT license): http://rvera.github.io/image-picker/ Room for improvement / roadmap: Images are resized via CSS (height: 200px) Images could be placed via masonry or the like create image-field to upload preview images directly to the template looking forward to hearing your feedback ps: is it intentional that i am only allowed to choose from 2 templates when adding the page and have more options available when editing the template settings of the page like you can see in the video? i'm wondering why this should be like this?!

Hey Guys, just wanted to wish happy holidays to all of you from Erika and me! ...and also share a small animation we did to celebrate the occasion: http://ed-works.com/christmas2015/ (this is pure CSS, there's no JS involved)

Have a look at this discussion: https://github.com/ryancramerdesign/ProcessWire/issues/839 Also, doughnuts.

What I would do to render things inside Resume, is to have the template assigned to the Resume page have something like this: $jobs = $pages->get("title=Jobs")->children; foreach($jobs as $job){ echo $job->render(); } In this example, I would be rendering each page under the Jobs page inside the Resume rendering. In the jobs template, I would have to include only the HTML needed to render each job (wether it is a li element or something else). Heck, if its only a list I would render it in the foreach loop above.

Hello, Could you paste here the source code, before and after pasting it in CKEditor (you can save the page, or you can normally just "validate" the source code window and then come back to the same window to copy the code)? Does you code contain divs? By default div tags are converted to paragraph tags normally. For each field like this one, you have to authorize in its settings the use of particular classes, etc. And, you can customize a Style drop-down list in CKEditor. Example Admin > Setup > Fields > Edit Field: body, and then in the "Input" tab: Extra Allowed Content Custom Editor JS Styles Set I've had to customize all this in order to use UIkit specific markup in at least the (CKEditor) Body field. NB: is it what you are really seeing in your Summary and Body fields, or is the image altered (for privacy purposes...)?

@LostKobrakai above answer not for you : I don't need a template engine or a js library. I write this function like i said, Use less html elements inside your php codes ! its for first comment. I converted markup to a module and working on it. Can you check here and if you have time can you check usage ? https://github.com/trk/AvbMarkupHtml i will update repo if have have new things

Your PHP version not supporting new array syntax, this is why you have this error message. I updated module to ve 0.1.0 now i think module fully supporting old php versions. New features for v.0.1.0 : Custom CSS file url support Added hook method ___beforeRender(), you can check hook example for usage Added multiple icons library use option Added Ionicons Library Now module using cdn for load icon fonts

Correct me if I understood wrong. This looks like you're assembling the navigation menus manually. Hardcoding an absolute path for a navigation entry will of course point to the page in its default language if you don't specify a prefix for a different language. In that case, fetching the page in question and assembling the link from its properties is the way to go. Perhaps you could add a function that abstracts away the repeated verbosity. <?= navItem('/contact/') ?> <?= navItem('/faq/') ?> and further down (or in _init.php or such) add your function: function navItem($path) { $pg = wire('pages')->get($path); return "<li><a href='" . $pg->url . "'>" . $pg->title . "</a></li>"; }

Amazing work my friend. Looks like my help isn't needed. I agree with percentages. Evaluating the site I'm working on I figured I'd have to compare each dot's coordinates with the image size to make everything scalable and responsive, so I think it's better to have it standard as percentage and convert to px on the frontend if needed. If you can make this available this week, I'll be setting up the CMS on my site starting monday. It would be a good testing ground. (Still stoked by the support this community offers, btw)

$sanitizer is a variable like $page or $pages as well. // In functions replace $page with wire('page') and $sanitizer with wire('sanitizer') $alltags = explode("|", $page->thumbnail->tags); foreach($alltags as $tag){ $sanitized = $sanitizer->pageName($tag, true); … }

Sanitizer docs are here: http://processwire.com/api/variables/sanitizer/ Maybe one of the $sanitizer->array() will do what you are after...?. I am not sure this will work, haven't tested: Edit: It will do what you are after. Tested and it works. But don't know how to pass the 'true' to it $sanitizer->array($value, 'pageName'); Otherwise, loop through the array and sanitize each value as you save them in a new array

I have a similar problem, but I guess there isn't much to do here. The problem derives from MySQLs fulltext search. If you have root access, you can always change the letter minimum (http://stackoverflow.com/questions/1585611/mysql-full-text-search-for-words-with-three-or-less-letters) and rebuild indexes (be aware of performance impacts). SQL fulltext searches are very basic and imperfect. They are fine for most of us, but if you need a real reliable, tolerant/fuzzy site search you would need to implement something more professional. There are many products on this topic, like elasticsearch (awesome), Lucene or Solr, but they all need a server with root access. The topic is comprehensive. Easy to learn, hard to master. If you can't be bothered with that, there is still this Lucene implementation from Zend, which is just a buch of PHP files without a full blown server (http://framework.zend.com/manual/current/en/modules/zendsearch.lucene.searching.html), badly documented though. It's a nice start and you can learn the very basics of search engines/indexers with it. But, naturally to PHP, this solution will not be able to handle big amounts of data. Af few thousand documents in the index and the fun is over already.

Markers seem OK to me. Perhaps it would be wise to change them to rectangles with arrows pointing down (gmap-style, or speech rectangle style), to eliminate styling issues. And this would allow more precise positioning imo. Hiding all and make one visible only if clicking on its marker? Plus optionally allow the user the view all, with a button for example. Or setting a max-height on the table and make it scrollable. But maybe others came up with a better idea.

$page is a local variable in template files just like each custom ones you define yourself. These are not somehow automatically available in functions. There are already other topics about that in the forum, just search for something like "variable scope" and "functions".

Forgot to clarify that I am still using @heldercervantes HTML (has a couple of nested DIVs) but with (most) of your CSS. I found it to work better even when an image was viewed at its actual size (e.g. the above is 4500x2234). The markers largely stayed in the right positions. Regarding the two-digit markers, I have only had to adjust the padding to 'padding: 0.5em 0' and it looks acceptable, I think? Haven't tested with 3-digit markers. Anyway, once I put this up on GitHub you guys can tell me if the markup needs adjusting, etc. Thanks. <div class="fieldContainer"> <img src="base.jpg" alt="" /> <div class="marker"> <div class="circle"></div> <div class="center"></div> </div> </div> Edit: With lots of markers, the table of coordinates becomes a bit long. Wondering whether to do something about it and how?

This is probably what you're needing to create the href value: http://cheatsheet.processwire.com/sanitizer/properties-and-methods/sanitizer-pagename-value-true/

Remarkerable updates Two-digit markers seems to need some fix but that's a minor thing.

This is a quick and nice scroll effect (just add to the site): https://github.com/galambalazs/smoothscroll-for-websites

yes, sometimes for simple sites i do something like this (usually use a table, but repeater should work); i'm not sure about depth - seems maybe unnecessary; i usually have a checkbox called child which simply makes the current row/repeater a child of the previous non-child item in the order that the items appear in... also i think you can maybe use this shorter ternary syntax if you are using the code above $prev = $item->prev->depth ?: 0; $next = $item->next->depth ?: 0;

Did you consider animating the scroll with something like this http://plugins.compzets.com/animatescroll ? I think it actually makes it more obvious what's happening when navigating the single page.

I am little afraid of all the hidden meanings of that avatar... no.hidden meangins i speaks.yur name and.my mom say APE PIZZA ? i says no.u gross .mom say APE PISA ? i says.ok mom say STILL WANTS PIZZA i says ok.i put in pizzas mom says I DONUT WANT TO SEE BALLS ON MYS PIZZA i says ok i cover.balls w pizza mom say I WANT SUM grASS W THA PIZZA i says ok.and put sum grass at avoter buttock mom says OK.i says ok

The tittle placement is spectacular!

Thanks Willy! I really like it.

mmm... again, we cross-posted. I guess my post will clear up most things, as when reading yours, I agree with everything * , so I hope my explanations about my objectives & my strategy are clear ; I can't do better. * I disagree (heavily on one point though : " In the more than 5 years of this open source project, I'm not aware of any instance where someone has misused a get() method and caused a security problem " Actually I don't understand why you say this, it mostly contradicts the rest of your purpose Anyway, let's go : without speaking specifically about PW, I can see the following main reasons for not being aware of vulnerabilities is a given web app : 1. the web app has no flaw (because very good design & development processes + developer awareness + reviews + not too big & too complex + etc... + point .2.) 2. the underlying CMF does a good job at preventing and/or assisting the designer & developer against many kinds of flaws (mostly for the syntaxic ones, less for the semantic ones) 3. the web app has not a huge traffic / not a huge potential "value" for compromise ; so apart from script kiddies -which would be stopped by .2.-, no talented attacker has the motive to try and break it 4. the web app has not been subject to a thorough security audit 5. compromise occured, but as not been detected hihi Our current discussion sits mostly in point .1. , where I'm trying to get the best out of .2. , in terms of how to adapt my processes. The fact that PW core has a strong reputation in terms of security (strong sec. framework + no known vulns) is also a strong point for another reason : it keeps script-kiddies and general lurker away from the web sites built on this platform. That being said, to make the asumption that there's no flaw, because we are not aware of any exploited in the wild... ! Well, this may be said for www.cnn.com , for your online banking app, at&t selfprovisioning, ... ok, they are constantly probed and shaked. You guess mainly from where in the planet, and it's confirmed by real world statistics. Look, if we take as example PW CommentForm.php as above. If you had forgotten the check $page->viewable() , there would be a security flaw. Detectable and exploitable, just by testing from the internet for data inputs, even without code review. I'm just taking this as a "pseudo"-real case. So, now : - Do you think, that all PW applications in the wild have all, and always, this kind of check in place where needed ? my experience (in webapps security in general, not PW related) tells me no. It's human. Some rare people are geniuses (I have the chance to tchat with one right now , but most are human, with sometimes not the right background, sometimes not being given the right priorities, sometimes make mistakes, etc... And if you don't know a single case, I cant tell you that yes, you have one : me ! Until I did a full review, I had a few issues of this kind. - Do you think this would be detected in the wild ? clearly, to detect this, it means that it's not a script-kiddie, it means that it's a real person, with his brain, whose aim it to find a flaw in the logic of this particular application. Frankly, even for processwire itself, I'm not sure that, would this check be forgotten, someone would have discovered it as of today. So, for a given custom web app made with PW, well... it depend on the traffic. If more traffic than PW, then more chances. In can happen. or not. So basically, I'm sure that yes, some web apps built with PW have security flaws. Semantic flaws, in their logic, in corner cases. Of course ! And it's not PW fault. And there would be even more flaws if PW security foundation was not what it is. I have the impression that I'm saying obvious things, no ? Actually I don't understand why we don't agree. And I don't even criticize PW in any way ; there I would have understood

ImageMarker beta 1 is out (well, sort of) Largely based on @ryan FieldtypeEvents + @kongondo MenuBuilder Up on GitHub later (if I get the chance before x-mas ) + Move to own module support forum API // assuming an ImageMarker field called 'marker' $page->marker->info;// ID of the info page (i.e the page represented by the 'dot'/'bubble' $page->marker->x;// x coordinate in px $page->marker->y;// y coordinate in px $page->marker->infoLabel;// title of the info page @todo/@brainstorm Default/New X/Y coordinates are 0,0. Is this OK? Configurable unique colour for each bubble? Would need to use colour picker + save value to db. Edit. No need actually. See post #34 below; now numbering each marker. Rename dot to bubble? Edit. Renamed to 'marker' Configurable dot/bubble sizes? Default colours? Slider/up-down arrows thing for manual edit of px inputs? Probably not; it is faster to type Reno Theme issue; since using img width 100% height auto in CSS, and since x/y saved as px, dots are off in reno theme. Using percentages should sort this out but do we want to do that or force user to upload image of max width w and max height h?. Edit. See post #34. Using percentages. Rename 'info' property to something else? Make tooltip more specific to IM dots only + unobtrusive Currently loading only info page ID in Field rather than the whole page object. User to grab pages within template file instead. Reasoning is potential performance issues if there's lots of bubbles? GitHub repo Own module support forum (assuming this goes forward ) Note Requires user to set up a file field + upload a base image to that field Currently, I really don't have time to work on this. Managed to do this in between stuff, when I got tired/bored of coding that other stuff Demo

While I liked the idea of having a new method, which would provide an encrypted id (autogenerated salt like for the user passwords) I don't think there's any necessity to change the underlying id system, especially as this is a default behaviour of mysql. Do you have any usecase examples, where this would be needed?

$alltags = explode("|", $page->thumbnail->tags);

I find the contrast between bg color #eef2f5 and body text #666 a tad low for the eye (not that one should care too much, but with a contrast ratio of 5.1:1 it fails WCAG AAA). Also, no German, but should it not be Sprachen instead of Spachen? Otherwise a nice, clean looking site without too much bells and whistles.

Hi zyON, I think the problem is that the used fonts don't contain your portuguese characters. Can you try to change your WirePDF settings: Mode: "s" instead of "c" Font: "DejaVuSans" See this post for more information: https://processwire.com/talk/topic/3008-pages2pdf/page-6#entry96263 If this does not work, you'd probably need to add a font that supports your character set by yourself to mPDF.

When using PW's API, you should always consider your code to be operating as a kind of superuser, just like in PHP. In find() operations where you are retrieving multiple pages that you don't know exactly what they will all be, it's a sensible default to exclude "hidden", "unpublished" and no access pages, unless you request otherwise. This is there as a matter of convenience and pagination, not security. Of course you can override that (when you want to) with the "include=hidden" or "include=unpublished" or "include=all" options. Whereas with get() you are being very specific about what you want–a single specific page. Otherwise why would you get() it? Neither find() or get() are intended as a primary means of access control–we have other methods for that (see below). They are methods setup to operate in the most common use cases and keep your API calls as short and simple as possible. Just because find() filters out hidden, unpublished and no-access pages by default does not mean you should count on it for access control. That's because the pages excluded from a find() don't include runtime access control, just that which is stored in the DB. Further, the behavior of whether or not a no-access page shows up in a find() result (that isn't overridden with an include= directive) is configurable with template access settings. Granted, in most cases find()'s defaults are giving you exactly what you want in terms of excluding pages the user can't view (for your convenience), but that's not the entirely of PW's access control, which supports runtime hooks. PW's job is to provide access control for the request, but not for your own code, that's the developers job. PW intends to give you, the developer, access to everything (like you would with jQuery and the DOM), and you decide whether or not it should be available for output. PW provides you with some handy access control methods to help with this: $page->viewable(); // is the page viewable? true or false $page->viewable('field_name'); // is the field on page viewable? true or false $page->editable(); // is the page editable? true or false $page->editable('field_name'); // is the field on page editable? true or false If you want to have you own get() and find() that operate under different defaults, this is easy to do with hooks in your /site/ready.php file. For instance, this would add a $pages->one("selector"); method that automatically does a viewable() check for you and returns a NullPage() if the page is not viewable: $pages->addHook('one', function($event) { $page = $event->object->get($event->arguments(0)); if($page->id && !$page->viewable()) $page = new NullPage(); $event->return = $page; }); Would there be value in adding a method like the above to our $pages API by default? Maybe. It wouldn't benefit my own API use, because the only time I use $pages->get() is because I want to get something without conditions. But if it would be super handy for others I'm happy to add it. Here's another example, lets say you want a method in $pages, like $pages->all("selector"); that always returns all pages with "include=all" implied: $pages->addHook('all', function($event) { $event->return = $event->object->find($event->arguments[0], array('include' => 'all')); });

Makes sense to me, I'll move that <?php endif; ?> down one line, so that the name/version only appears when logged in.

I need to rewrite that post because there are many improvements and simplifications in that process. My ultimate goal is to create a site profile (maybe a multilanguage one) with Latte.

What I use a lot is: ob_start(); include('tralala.php'); $var = ob_get_clean(); This way tralala.php has access to all variable above ob_start(); (no need to pass it variables)

I'm using a similar setup in my PW projects. The major difference is that I'm using Latte template language which takes it a step further by allowing master templates, overridable/extendable blocks, email templates, includes with variable passing, etc. Plus much cleaner code in view files, which alone would worth the switch . I like it just as much as I like PW, but having both at hand is the best. I've tried switching to Twig but I felt it less productive. While I agree with Ryan that PW doesn't need a template language, using one can save a lot of time.

Hi everyone, I did a little thinking and coding on this issue last night. There is a gist on this post (https://processwire.com/talk/topic/8605-user-editsaddsmove-only-his-own-page/?p=84835) which hides uneditable pages, but be sure to read my comments in that post. And based on my comment about the issues with "is editable" checks and the need to display non-editable parents to allow a user to access editable grandchildren, here is a much more comprehensive module that allows the ability to hide specific pages (and obviously their entire branch of children/grandchildren) based on the user role. It is based off my Page Protector module so it will look familiar to anyone who have used that. It is just a first draft, so test carefully It is attached here for now. Any thoughts? AdminPageHider.zip

module doesn't uninstall properly. put issue notes on github. If possible for you and not annoying for people using this module I would really recommend to rename your module since it doesn't generate fields at all. What about ProcessValueGenerator or ProcessRandValueGenerator.

Hanna code is if you talk in MODX language, a combined snippet & chunk on steroids

Ok since you hook Page::viewable every page in PW will be somehow affected, even admin pages as they are also just pages. So the message with $event->object->name is the admin pages rendered in the admin template. I'd guess it's the navigation. But since the ProcessPageList module is ajax driven you won't see any messages from there. $event->arguments is nothing there I think, as the important with these page access hooks is the $event->return value. So you would do set it to false or true $event->return = false; // page won't be viewable All the viewable hook does is define if a page is viewable or throw an 404. In case of the admin page tree the page will still be visible and only have no -view- action button. That's all. If you really want to hide pages in the admin I'm with Ryan, but see that there's cases where it would be nice to hide pages from users and keep a branch hidden from them. I already stumbled and tried very hard 1-2 years ago, but realized it's not easy as there's no obvious hooks available where needed and it's done with ajax and there's some things to consider, didn't really bother. Now after thinking for some time and try error I found an easy way to just remove pages from the page list tree. The trick is to modify the JSON output that goes with the ajax response, convert it to an array and Long story short here's an example module for those interested. I used a pagelist_hidden page field added to the user template to define pages that are hidden for a user. Of course there could be endless configuration possibilities, with roles and what not, but don't want to go any further and maybe someone else finds this useful or as a start for a new module. If Ryan reads this and is still with me. Would you consider adding some hooks to ProcessPageList.module? Or do you think the JSON manipulation is a good way? Most likely there would have to be some additional take care to make those pages also not editable. Those page will still be accessible manually through admin url. Such a module shouldn't be used to hide pages for access restriction, and it's only and best suited for hiding "private" branches in the admin, or functional pages that can't be in the /Admin/ branch for some reasons.

I built a function that does exactly what you asked for, it recognizes the format {image_1}, {image_2}, {image_22}, etc: function imageTags($p, $field){ $string = $p->$field; preg_match_all("/{image_[0-9]*}/", $string, $array); foreach($array[0] as $match){ $number = preg_replace("/[^0-9]/", '', $match); $index = $number-1; $image = $p->images->eq($index); $image = "<img src='$image->url' alt='$image->description'>"; $string = str_replace($match, $image, $string); } return $string; } echo imageTags($page,'body'); // first parameter is the page object, second parameter is the field name. // you can also do this: echo imageTags($pages->get(123),'summary') edit: did some cleaning on the code. if you want another format for tags, {img:22} for instance, just change the regex on the 3rd line from "/{image_[0-9]*}/" to "/{img:[0-9]*}/".