kongondo

Guys, these are very nice! @heldercervantes, are you able to incorporate these into your original sketch please?

include=hidden in your search selector http://processwire.com/api/selectors/#access_control // results exclude hidden, unpublished or non-viewable pages $pages->find("template=skyscraper"); // results may include hidden pages $pages->find("template=skyscraper, include=hidden"); // results have no exclusions $pages->find("template=skyscraper, include=all"); // results may include pages user can't view $pages->find("template=skyscraper, check_access=0"); Edit: But why not just exclude your page from the menu using the API?

That's still in the works. ProcessWire 3 is here: https://github.com/ryancramerdesign/ProcessWire/tree/devns Version 3 has gone beyond 'alpha', btw.

Could or could not?

Thanks for the suggestions. Since these are just for the backend, functionality is more important than style so I want to keep this to the bare minimum and maybe only offer two choices. Circle and Rectangle with a pointy-thingy (a callout rectangle).

I'll wait . We'll still need to position them using top and left, or would that have to change?

Is it possible to use CSS only to create such markers or would this require using icons/images? I found a couple of CSS-only fixed-header-vertical-scroll-table solutions. I am leaning towards these...

OT: I have been meaning to ask you how you do your cool animated GIFs. Thanks!

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

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?

Yeah. I'm horrible at CSS ...Not sure if it needs some padding or what

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

I like your markers. Think will use them instead

Actually, quite easy to make it configurable on a per field basis, i.e. user can specify units to suit their needs, so offer all valid CSS length units as long as we can convert them in javascript: em, ex, %, px, cm, mm, in, pt, pc Edit: Hmm..but would still have the challenge of setting the base image width based on these...hmm. So maybe stick to % and let user convert that to whatever they like at template file level...

I prefer percentages but would like to hear of any disadvantages to using them, if any?

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

Jim, What the guys said above. Welcome to ProcessWire and the forums Guilty as charged! ProcessWire makes hard things easy...but you also need to be willing to get your hands dirty. Nothing is output for you. In addition to the stuff above, have a look at the docs (page, pages and selectors are a must)...and you should be on your way I think these guys are on to something http://directory.processwire.com/

Managed to quickly put something together. Will post an update here Sunday or Monday if possible + send you some requests for the JS...

I remember seeing that one. I think you need to create a comments field first, IIRC (as a workaround).

Not too difficult Easy as the list comes from the saved values in the DB. Using $config->js, we send saved coordinates to javascript to show saved coordinates on the map/image. jQuery [not my strong point] jQuery + CSS

@heldercervantes, OK, I see. Make sense. However, I think all the editing of the 'dots' should happen in one place. The sub-pages should just be referenced (by the dot in the parent page) and will contain all the secondary info (i.e., not the coordinates) about that 'dot', e.g. location, color, price, whatever. In fact, the referenced sub-pages do not have to be child pages of the page with the dots. The sub-pages are just info pages. The info they contain can be reused by any 'dot' page. Here's how I see it: Let's take the example of the Room Archive. We'll have a template called 'products' with the Field ImageMarkup (or whatever you call it). This field allows for the uploading of an image and the 'marking-up' of that image. Let's say we create a page called 'Room Archive' that uses this template and we upload to it the image of a 'room' [or part of a building]. Let's say we also have pages that contain information about 'dots'. These pages could be using any template, with any number of fields, with all sorts of information. Let's call these 'info pages'. Some of the 'info pages' contain information about our Room Archive, others contain info about other similar product pages, and some of the info could also be common to all products. Each dot placed on our 'Room Archive' image references some other page on our page tree with info that we need. Our 'Room Archive' page doesn't care what that info is. For instance, it doesn't care whether that info is about the materials used in the building, or the colours, or the size of the door, etc. That info, for all intents and purposes, will be accessed via the API much like ProcessWire's page fields. A page referencing another page in its pagefield doesn't care what that other page does. All it saves is the ID of that referenced page. With that single info, using the API, you can access and display and manipulate every little bit of info about the referenced page. So, back to our example, the 'Room Archive' page [or the 'dots' page if you like] only needs to save three bits of data. The x-coordinate of the dot, the y-coordinate of the dot, and the ID of the (info) page referenced by these coordinates. Nothing more. Then, similar to how we access page objects stored in a pagefield, for each saved 'trio' of data, our Field will return an object of each referenced page as well as the coordinates. We then use these to output whatever we like in our template file for display to the user. E.g. $page->image_markup->title, $page->image_markup->description, whatever. This way, we edit all dots for 'Room Archive' in one place, rather than in the 'info' pages themselves. If the information in the 'info' pages change, the 'Room Archive' doesn't care, it still has a reference to the info page. The 'Room Archive' page also doesn't care how our 'info' pages are organised. This is how I would do it, unless there's something am missing...

Its not clear to me why each dot should be a sub/child-page? Apart from co-ordinates, what other information does the sub-page hold? if it's simple info, can't the dots all be in a single 'table'?, (similar to the events fieldtype), i.e. x y info 1 info 2 info 3 34 336 aaa bbb ccc

OK, that looks pretty much straightforward. Seems the js will be doing most of the heavy lifting. All the Fieldtype/Inputfield will do is so display and save the data (of course ;-)). A couple of questions: How many dots per image; single or multiple? [am guessing multiple] Save when you hit a button save or ajax? [am guessing button; otherwise, potentially too many ajax requests] How many 'maps' on one page? Single or multiple? Edit: Aah, I see some of my questions have been answered in your earlier posts. In your present CMS, how do you edit a point? You click on the dot? Or you edit entries in some table?

@Jugibur, Welcome to PW and the forums. What the others said . If you are in no hurry to build something, I'd suggest stick with reading the docs first. Otherwise you might end up doing things the hard way. There really is no magic in wrapping fields with HTML. You don't need to create a function for that. It's as simple as outputting something like below in your template file. $out = "<div class='my_field_class'>" . $page->body . "</div>";// body is a text field called 'body' on the current page echo $out; Please note there are different ways of outputting code within HTML...(as you will see in examples in the Docs and the forums. The above is just one way.

@heldercervantes, How did you build the on in your 'CMS'? (i.e. what web technologies)...Maybe it could be converted to a Fieldtype, but we would have to see the underlying code...(if at all possible)...