kongondo

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)...

@Peter, No. Just re-parent them or leave them as is and rename parent(s) (if you wish) Blog to whatever you want (e.g. Blog 2 ) No. Ditto If you uninstall Blog without first running the Cleanup utility (only seen on menu if logged in as superuser), none of your fields, templates, demo template files, blog pages and role 'blog-author' will be touched. They will be left as is. So, don't run the Cleanup utility and you should be fine.

I read through this quickly so might have missed something. Just wanted to point out that Blog (since version 2.3.2) has a 'related' posts implementation: renderRelatedPosts(). Posts can be related by tags, categories or both. Have a read from here onwards and examples here. This is yet to find its way to the documentation, sorry.

@Asdiff, Welcome to ProcessWire and the forums. Have a read here about determining file permissions (who Apache is running as, etc): https://processwire.com/docs/security/file-permissions/

Maybe the ideas presented here The Wire Render Pattern by @cclsource ould help you decide?

Yes, MenuBuilder too ...(but uses JSON) IIRC, somebody already did this? i.e. there's a fieldtype around here somewhere... Edit 1: Yeah, what @LostKobrakai said... Edit 2: @tpr: Moving this topic to plugin development. The current board (ProcessWire Support Forums → Community Support → Modules/Plugins) is for supporting released modules

Hey Ben, that's brilliant news! Finally, someone who knows about ProcessWire writing about ProcessWire . Could you please start a new thread about this? It is an important issue and should not 'be hidden' here amongst other stuff, thanks.

@Roderick, For each new question unrelated to the original title of a thread, we start a new thread. Please start a new thread for your new question. Secondly, if a question you pose is answered to your satisfaction, please mark it as solved. Thanks.

That field could be a text field (means you have to type it up always), a page field (single select) or an options field (probably easiest) (single select). If you don't have many child pages, you can use CSS/HTML IDs instead of classes, and do something like id=child-1, id=child-2, etc Welcome to ProcessWire and the forums Edit: Also depending on how the children pages are named and the number you have to deal with, you could use their names for IDs...

Something like this maybe?

No. This is just a quick fix and Ryan's implementation will most likely be better than mine . You might want to better draw his attention to your request though via GitHub, and if you wish, point him to this quick fix.

A temporary fix in response to this request ProcessCommentsManagerEnhanced This is a slightly enhanced version of the current core ProcessCommentsManager. I've tested it in the current dev version of PW and it works fine. I cannot provide any guarantees nor support the module though ....it is a working-nicely-proof-of-concept. Download GitHub Install Just like any other ProcessWire module. It requires FieldtypeComments to be installed. You do not need to install ProcessCommentsManager. Demo Screen

@Peter, Here you go, a temporary solution as you await Ryan's response to your request: ProcessCommentsManagerEnhanced This is a slightly enhanced version of the current core ProcessCommentsManager. I've tested it in the current dev version of PW and it works fine. I cannot provide any guarantees nor support the module though ....it is a working-nicely-proof-of-concept.

Couldn't these be done with the comments manager? I haven't tried it myself though... Edit: OK, not exactly: https://processwire.com/talk/topic/1681-module-comments-manager/. I also now see your earlier comment there.

OK, your error is being generated at this line. Can you confirm your slider is actually called Slider1? That line indicates your slider was not found. I am not sure whether its case sensitive.

@hamzaalibhatti Did you install all the three modules that come with this module? i.e.

@David, The module consists of 3 modules: A Process module, a Fieldtype and, you guessed it, an own Inputfield . The Inputfield is what you see in the first and second screenshots above.

@Mobiletrooper, I think you are right on the money . Been experiencing this a lot lately in Chrome Edit: Welcome to the forums

Update: version 0.0.2 As requested by @Macrura, added a markupValue() method to correctly output the field's markup output in listers.