Leaderboard

Added another little tool to the box that I sometimes use to detect best breakpoints for mediaqueries. A little Javascriptbox that displays the dimensions of body and a configurable custom container (by ID). What dimensions are shown, offsetWidth, ClientWidth, ScrollWidth, is dynamically configurable in the Top of the JSbox: To enable / disable it, select or drop the button in the config page, and, optionally, type in the id of a custom container.

You could put those items in a parent under /processwire/

Want to have a go at it? I can handle all the jquery and css stuff.

such a fieldtype could be really cool for seatmaps in a booking system http://iakob.com/canvas-area-draw/demo.html sorry... just dreaming

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

@Jugibur You don't need to be a programmer. Read some of the tutorials. This will help you. Start here: https://processwire.com/docs/tutorials/hello-worlds/ But you will become a programmer, (or something like that) if you stay with PW. This is my experience. Go for it.

ALIF - Admin Links In Frontend EDIT: latest version update with PHP 8 fixes on 05. Nov 2023 (!) The version now is 1.1.9 (!) This module combines some of the admin links that we want to use on the frontpages sometimes. It is a comfortable and easy way to do so. After you have installed and configured the module, you can inject the links into the frontpage with code like this in a template file: echo $modules->isInstalled('AdminLinksInFrontend') ? $modules->get('AdminLinksInFrontend')->render() : ''; . Credits: The comfortable Javascript Color Picker in the Configpage comes from Jan Odvarko (http://jscolor.com). Many thanks for this! * Toolbar The toolbar can be positioned by css values for top/bottom and left/right. It can expand in vertical or horizontal direction. The buttons are links to the PW admin, for logout, or for editing the page in admin, or informational ones. All settings, including the colors, can be defined in the modules config page. This is available for all PW versions from PW 2.3 up to now. Depending on how you configure this part, it can be used for authors and editors too, maybe. * Import / Export Settings It has the possibility to export and import its settings via two textarea fields. When importing settings, you get a second screen where you can select which settings you want to import. * One-click User Account Switcher For PW versions 2.6.8+, there is one really nice function available, that I use when developing / testing sites with different user / roles. A fast User-Account-Switcher that lets you view the same page from different user accounts with only one click. To enter this mode, you need to login as a superuser one time, and the feature needs to be enabled in the module of course. After that, you can log out, login with different user roles, etc. At least the toolbar buttons for the User-Account-Switcher will stay visible for you. This is session based. There is also an extra button with a trash can and the text "Session", that helps you to leave this mode once you are finished. As you can see in the screenshot, after clicking "guest", I was logged out, but a regular login button, a warning for debug mode and my three defined buttons for user accounts are available. When clicking another user button I login with this account. Very handy. ATTENTION! The use of the One-click User Account Switcher is mainly intended for dev sites, not for public sites! You should be aware that there is a huge security risc when using this feature on public reachable sites! We completly leave ProcessWires comfort zone in regard of security, - and the only thing between your site and potentially hackattacks is this module. (Oh mom, - what have I done?) PW 2.6.8+ has a comfortable function for admin tasks, that let us log into different user accounts via API without using passwords. This module uses this function! All data that is needed during a User Account Switcher session is stored in the session data on the server. So, if someone steel your session cookie, there is potentially risc that he can login as a superuser, depending of the user account buttons you have in your admin links collection! To prevent SessionHijacking, the module can be bound to a single IP address, it uses a fingerprint depending of IP(s) and UserAgent string. And you need to define a max time to live in minutes between 2 and 60, a User Account Switcher session may run. A User Account Switcher session only can be initialized by a Superuser who also explicitly has set a permission called 'alif-user-account-switcher', what is defined by the module, when installing it. So, the prefered way to use this module is, to enable and use the User Account Switcher while the site is unpublic, and before it goes public, remove the permission from the superuser role. This way, you can use its menu function, but not the UAS anymore. On a sidenote, for those rare cases where multiple superusers simultaneous developing on a site and want to use the ALIF, but the UAS should be used only by one, you can leave the 'alif-user-account-switcher' permission removed from the superuser role, but need to assign the role 'alif-superuser' to the single user account. This way, only that single superuser has the permission for UAS, whereas all other superusers doesn't have it. . . * The Configpage * Online demo I have pasted it into this old site and enabled it to be present every time (when the site is in demo mode only!). So, it is an earlier state, but the switcher is functional there: http://pwlaf.biriba.de/dbinfo/ * Download From our modules directory or from github repo

You can still visit unpublished pages when logged in as superuser, that's why your template code gets executed. If you want to handle via this via unpublished status, simply add this on top of your template file: if ($page->isUnpublished()) { throw new Wire404Exception(); } ... or if you want a message remembering yourself that you need to unpublish the page, instead of a 404, echo out something and return Cheers

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

Just make sure to keep the right thing in mind: Output formatting needs to be of if you're editing any fieldvalue of a page, especially if you're trying to save it afterwards. There's no correlation to pagearrays per se.

Wow! Another option! We discussed something similar here. But processwire is not in that systemIDs array. The search in all files from ProcessPageList module for "processwire" did not get me anywhere either. What is the source of that magic? And just like Cerulean I would like to hide branches like that without hooks any modules. Though hooks and modules do exist.

Every field is reusable in ProcessWire out of the box. This is how it works by default with processwire. You create the fields, create templates, assign the fields and optionally give the template a file to give it a view and to write markup or logic in it. For repeatable element we have Pagetables, Repeaters etc. All working with the above concept.

You could hook FieldtypeTextarea::sanitizeValue for that. If it's not a string with [ or { in the beginning, then encode it.

Good solution, thanks! Just curious: what is it about the /processwire/ branch that makes it hidden to non-superusers? Is it possible to create new branches that are hidden like this?

Here's the code: function convertGeoToPixel($lat, $lon) { $mapWidth = 38; $mapHeight = 109; $mapLonLeft = 16.37007904846189; $mapLonRight = 17.151481636352514; $mapLonDelta = $mapLonRight - $mapLonLeft; $mapLatBottom = 56.1947686858922; $mapLatBottomDegree = $mapLatBottom * M_PI / 180; $x = ($lon - $mapLonLeft) * ($mapWidth / $mapLonDelta); $lat = $lat * M_PI / 180; $worldMapWidth = (($mapWidth / $mapLonDelta) * 360) / (2 * M_PI); $mapOffsetY = ($worldMapWidth / 2 * log((1 + sin($mapLatBottomDegree)) / (1 - sin($mapLatBottomDegree)))); $y = $mapHeight - (($worldMapWidth / 2 * log((1 + sin($lat)) / (1 - sin($lat)))) - $mapOffsetY); return array($x, $y); } $pposition = convertGeoToPixel($pl->map->lat, $pl->map->lng); echo "<div class='litenkarta'><div class='punkt' style='left: {$pposition[0]}px; top: {$pposition[1]}px; '></div></div>";

I would disagree on the last one. For bigger systems let the writers focus on the content not on the visual output. When you let them focus on desktop experience changes are they will write for desktop. In my opinion content should separated from view, articles should be device independent. For you as developer you have to give them the fields they have to fill in. This way you can get the content that is suitable for the platform where you wish to publish it. In my opinion: A system should be a content management system (CMS), not web publishing tool per definition. The content should be written platform independent, (Not writing for a specific device).Provide enough fields to pull from, when the need is there. The content should be modularity, so that it's it's easy to add different types of content.Your example of page table would work. Insure your data is accessible and could be queried from other platforms (JSON API). Don't pollute your data with structural markup.Don't use div's or image strings etc in you text directly. Use Page tables or something for images, video's etc.

Have seen that it was mentioned in last ProcessWire Weekly. (sighh, have hurried up with it) I have tested it with PW versions 2.3, 2.4, 2.5, 2.6, 2.7 and with PHP 5.3 and 5.4. It works good from PW 2.4+ up! With PW 2.3, the Javascript Color Picker doesn't function. But 2.3 is really old and if someone has maintained a site until now without ALIF, he will do it fine in future too. Only thing I want to know is: in wich PW version was "showIf" introduced to show / hide Inputfields in the admin? Would be nice if someone can point me to that. So, it is ready for the masses now!

The 404 page is declared as system page in the constructor here https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPageList/ProcessPageListRenderJSON.php so there's probably no way currently to extend this exact behaviour besides editing the file itself. But you could hook Page::viewable and try to just disable the view access for that pages if the current process is ProcessPageList.

You are great!! Now it works fine! thanks

A settings field based on a hooked Profields Table. When running the code (in the spoiler), superusers are able to edit, drag & delete all, while other users are limited to edit the setting only. (Thanks MacRura for the idea) Superuser sees: Everybody else sees: Code lives in the spoiler. Maybe some time I build a Module for this one.

It seems Juergen is not talking about the "actual" template of a page, but the template of an edited page. There's a function on ProcessPageEdit to get the page you're editing (ProcessPageEdit::getPage). You really need to understand the fundamental difference between the frontend and the backend. The frontend is rendering the pages themself, while the backend actually consists mostly of pages with linked process modules (the ones you see in the page-tree as children of "Admin"). So the page being rendered in the backend is always the process, not a potential page being edited. If a process is showing a specific page you would need to ask the module to tell you which page it is. ProcessWire won't know. It's kinda like if you would use urlSegments on the frontend. The $page objects is always the same, but depending on the segment you're rendering a different UI. ProcessPageEdit does work the same. The $page object is the process, but it's rendering the form depending on the passed page ID.