Leaderboard

Hope this isn't taken as spamming - could one of the other mods please remove this if it is - but I thought I'd point out that Packt publishing is doing a month of free E-Book downloads - many of them will be PHP related. More details here.

No, it means: you cannot upload the same image to different imagefields on the same page! You can upload the same image to different pages because each page has its own subfolder under site/assets/files/.

Are we ready to go ahead and make this stable? I haven't encountered any further issues...

I've just checked, the module does work out of the box with FieldtypeOptions, so nothing to do for me Edit: At least for the "Interface". Seems like Ryan did not include an option for adding new options from the inputfield by now, like it's for FieldtypePage. The thing I don't like about including it myself is, that I can't really guess a value for the field, while this would give the ability to change the wording afterwards, even if it's only a typo. Maybe we should first ask Ryan if he could implement a standartised way for auto values, then it would be easy to include a "add option" field like for pages. I'll open a feature request over on github.

If not that, at least display the latest specified compatible version in the list view. I think this would be a nice and helpful feature to have, especially for some module categories (such as Admin Themes) with few listed as being compatible with 2.5... For now you have to open each module's page individually to view this info, and not only that but that brings up another minor annoyance in my experience with the modules directory, which is that trying to open a module's page in a new tab actually loads it in the source tab as well. I mean, the site does load swiftly, thank you guys for upholding such quality standards... but I still don't see why that's even desirable to do... You all know what I'm talking about right? I wish processwire.com was open source, especially to see how the newsletter system is done.

As if I didn't talk about other modules on the todo list in another thread. But actually it's not an inputfield which is bound to be used with FieldtypePage, as this states in the module declaration. ... extends InputfieldSelectMultiple implements InputfieldHasArrayValue The module does add itself automatically to be usable with pages in the settings of FieldtypePage, so maybe it's only missing it's entry in FieldtypeOptions' settings. I'll test this tomorrow and if it's that way, I'll add the addition/removal to install() and uninstall().

@ last 3 posts - I agree but there are still times where, as long as you trust the person editing to do it properly, this is still okay (although not usually ideal, I agree). With regards to the craft screenshot and Apeisa's link to SirTrevor - this is the ideal way to handle this and I did actually start to play with an inputfield to accomplish this using SirTrevor but couldn't get it to work properly (I may go back and check it again now I've got more experience). The idea is simple enough - allow as many image fields and text editors as you like in a single fieldtype (I got that working) and simply have ONE textarea field that stores the order of the elements and the editor content as JSON. That way you just need one multi-image field to store the actual images, and the textarea field stores all the editor contents. A nice little render function would pull the content together to display on the frontend and you're sorted I think if I revisited it I wouldn't even bother with SirTrevor to be honest and I'd roll my own interface so as to keep the styling in line with the PW admin themes.

Menu Builder As of 29 December 2017 ProcessWire versions earlier than 3.x are not supported Modules Directory Project Page Read Me (How to install, use, etc..) For highly customisable menus, please see this post. If you want a navigation that mirrors your ProcessWire page tree, the system allows you to easily create recursive menus using either vanilla PHP or Soma's great MarkupSimpleNavigation. In some cases, however, you may wish to create menus that: 1. Do not mirror you site's page tree (hirarchies and ancestry); and 2. You can add custom links (external to your site) to. That is primarily where Menu Builder comes in. It is also helpful if you: 3. Prefer creating menus via drag and drop 4. Have a need for menus (or other listings) that will be changing regularly or that you want to allow your admin users to edit. The issue of custom menus is not new here in the forums. The difference is that this module allows you to easily create such menus via drag and drop in the Admin. Actually, you can even use it to just create some list if you wanted to. In the backend, the module uses the jQueryUI plugin nestedSortable by Manuele J Sarfatti for the drag and drop and is inspired in part by the WP Custom Menu feature. Please read the Read Me completely before using this module. For Complex or highly-customised menus, it is recommended to use the getMenuItems() method as detailed in this post. Features Ability to create menus that do not mirror your ProcessWire Page Tree hierarchy/structure Menus can contain both ProcessWire pages and custom links Create menu hierarchies and nesting via drag and drop Easily add CSS IDs and Classes to each menu item on creating the menu items (both custom and from ProcessWire pages) or post creation. Optionally set custom links to open in a new tab Change menu item titles built from ProcessWire pages (without affecting the original page). E.g. if you have a page titled 'About Us' but you want the menu item title to be 'About' Readily view the structure and settings for each menu item Menus stored as pages (note: just the menu, not the items!) Menu items stored as JSON in a field in the menu pages (empty values not stored) Add menu items from ProcessWire pages using page fields (option to choose between PageAutocomplete and AsmSelect [default]) or a Selector (e.g. template=basic-page, limit=20, sort=title). For page fields, you can specify a selector to return only those specified pages for selection in the page field (i.e. asm and autocomplete) For superusers, optionally allow markup in your menu titles, e.g. <span>About</span> Menu settings for nestedSortable - e.g. maxLevels (limit nesting levels) Advanced features (e.g. add pages via selector, menu settings) currently permissible to superadmins only (may change to be permission-based) Delete single or all menu items without deleting the menu itself Lock down menus for editing Highly configurable MarkupMenuBuilder - e.g. can pass menu id, title, name or array to render(); Passing an array means you can conditionally manipulate it before rendering, e.g. make certain menu branches visible only to certain users [the code is up to you!] Optionally grab menu items only (as a Menu object WireArray or a normal array) and use your own code to create custom highly complex menus to meet any need. More... In the backend, ProcessMenuBuilder does the menu creation. For the frontend, menus are displayed using MarkupMenuBuilder. Credits In this module's infancy (way back!), I wanted to know more about ProcessWire modules as well as improve my PHP skills. As they say, what better way to learn than to actually create something? So, I developed this module (instead of writing PW tutorials as promised, tsk, tsk, naughty, naughty!) in my own summer of code . Props to Wanze, Soma, Pete, Antti and Ryan whose modules I studied (read copied ) to help in my module development and to Teppo for his wonderful write-up on the "Anatomy of fields in ProcessWire" that vastly improved my knowledge and understanding of how PW works. Diogo and marcus for idea about using pages (rather than a custom db table), onjegolders for his helpful UI comments, Martijn Geerts, OrganizedFellow, dazzyweb and Mike Anthony for 'pushing me' to complete this module and netcarver for help with the code. Screens

Introducing ProcessDiagnostics and it's helper module suite. (Is this ProcessWire's first community-created module suite?) Description This suite adds a page under the setup menu that displays information about your installation. Each section's data is provided by a specialist diagnostic helper module but it is all collected and displayed by ProcessDiagnostics. The ProcessDiagnostics module itself does not encode any knowledge about what makes up a good or bad setting in PW - (that's done by the helper modules) - but it does the following... Gather the diagnosics (thanks to PW's hook system) Display the collected diagnostics Provide helper functions for describing some common things Dispatch actions to diagnostic provider modules (again thanks to PW's hook system) And eventually it will: Allow control of the verbosity of the output Allow the output to be emailed to a sysop Store the results between visits to the page Detect differences between results at set times Send a notification on detection of changes Although I am curating the collection, anyone is welcome to fork the repo, make changes in a topic branch, and submit pull requests. I've already had submissions from horst and Nico. Diagnostic Providers The current diagnostic providers include... DiagnosePhp - Simple diagnostics about the PHP envirnoment on the server DiagnoseModules - An ajax based module version checker by @Nico DiagnoseImagehandler - Lets you know about GD + Imagick capabilities by @horst DiagnoseDatabase - Checks each DB table and lets you know what engine and charset are in use DiagnoseWebserver - Checks the webserver setup DiagnoseFilesystem - Looks at how your directory and files are configured and warns of permission issues (currently incomplete) There is also a bare bones demonstration diagnostic module... DiagnoseExample - minimal example to get module authors started. Translations English & German (thank you @Manfred62!) Help translating this suite to other languages is always welcome. On The Net Check out Nico's blog post about this suite on supercode.co!

I noticed that although there's an InputfieldSelect module, there wasn't a FieldtypeSelect that would produce a drop down list (via a "select" input) that would allow you to define a list of options in the field's configuration. (Somewhere in this forum, I saw that the "Page" fieldtype was suggested to do this - and it works - but it didn't seem as easy as it should be.) So, I went ahead and created a module to do it! After installing, you'll have a new "Select" fieldtype that will allow you to define the items you'd like in the drop down. You'll be able to define these options in a text box on the field's configuration screen. Just put each option on it's own line. Hope this helps someone out! Let me know if you experience any issues with it, find any bugs or if you have some ideas on improvement. EDIT: The module is now on github: https://github.com/Hani79/Processwire_FieldType_Select_Drop_Down (Thanks for the prompt to put it up there, Soma.)

If you're on a Mac have a look at Tree.

I, for one, would love a solid module that handles menu management. I have a large site coming up in a month or so that would require it. Automatic menu generation doesn't sit so well for me - so this is a must have. If you decide to not do it, then I'm sure I can make use of a page structure under admin to mimic the functionality... But, I think a dedicated module is better - especially for the client, who needs to be able to modify certain menus as and when needed.

Revisiting this old thread to feature Fargo. This is a really nice online outliner that can be used also as a CMS. Amazing! Edit: just to put it in context for those that don't know what a outliner is. A outliner is a software that let's you organize info (thoughts, notes, to do's, text, whatever you want) in indented lists. Great examples besides Fargo are WorkFlowy and moo.do. Of course, these don't include a CMS

That is correct behaviour. I just tried the delete methodof (first time, didn't know that before) and it worked fine, although I got the notice about that it couldn't delete module. Fredi (and it's companion module) install and uninstall just fine. I believe the issues here are with pw module handling and how those work with 'installs' information.

Hell yeah. I didn't encounter any further problems, but I haven't done the big test yet.

When I get some time in a few hours, I'll try it out on a fresh install, and narrow out what the problem could be.

Uninstall a module PW will now create a ".ModuleFolder". You can then via direct download url install the module again and it will add a new folder. If using the class name it will find it already there and show message. Surely some quirks going on with core module manager.

I think this is on purpose. The first row does always provide the link, which does show/hide the edit / view links. I think it was different some time ago, but it didn't feel nice, to be honest, to click the image and have the extra links appearing besides it, maybe even barely fitting in the rows. I really don't remember images in the first row being a good idea.

Great to hear....if you strech your brain once in the right direction with PW there will be almost no limits....

You stretched my brain A LOT, I dunno how to appriciate for that! BIG THANK YOU!! I modified mr-fan's example, needed about 1 hour and half for that (after 4-5 hours of yesterday's journey to nowhere). I'll update this topic with my solution... It's look like a little rusty atm and will see if I would make more elegant solution. Again, thank you!

Hi, you didn't tell us what mamp you are using free or pro version. From your terminal verify that /usr/sbin/sendmail exists and can be called by your apache/php user. From the cli, as your apache/php user, try sending an email using sendmail: # sendmail -v you@email.com testing Check that your MAMP mail function is enabled as it is not always by default and you have to enable it yourself. Navigate to Applications\MAMP\conf folder and look for the folder that corresponds to your php version and open the php.ini file contained within with a text editor. Scroll down to the section that says [mail function]. ;sendmail_from = me@example.com Change the parts there using the appropriate email address and smtp hosted on your server. e.g. make sure you change your email from yourname@example.com to your own email. You can also use postfix as it comes preinstalled on OS X and requires almost no configuration

Why not use PageTable or PageTableExtended for that? To the topic: I also don't see a use case where I allow my clients to insert editable images directly into a RTE field because I always want to separate design and content. But nevertheless if I needed it, this implementation is just awesome. And the upcoming ability to generate thumbs of a given image in the standard image field – even as a byproduct – is the thing I am looking forward to! What I don't quite get: All the features described above (see quote and posts before that) are already achievable with PageTable and PageTableExtended. The module still is in early stage (had no time to develop it further) but works pretty well and allows to define custom layout parts. A next step would be to get rid of the popup while editing and put the edit interface into the layout itself (shouldn't be hard with an Iframe). But I would never advocate a WYSIWG editing capability because editors then tend to "make the content fit". And this can never work considering the unexpected output on other screen resolutions/devices which an editor can't foresee. So my approach is to make the interface as clear as possible and present the content in a comprehensible way, but never in a 1:1 way, because this can never be real, neither in front- or backend. Edit: Take this page: http://schutzbelueftung.de/montage-service/ This it how it looks like in the admin (cut-out):

Don't know much about this but it seems there's one or two issues to consider here. First, the issue about making data entry as easy as possible for the client. They don't want to be 'typing' all those aliases with every page edit. Secondly, there's the main issue - how to create those aliases. In respect of the latter issue, the 'master name' will have to be related to its aliases in one way or another. A common way of relating things in ProcessWire (and you probably know this) is to use page fields. These are related to the first issue in that depending on the level of complexity, page field input such as auto-complete or asmSelect (plus the new tag select) can be quite handy. Is there a reason why you can't use such a system? Will the aliases be manually entered or imported into your (or maybe read from a custom) database? For some really powerful searching, there is also the module Elastic Search. Maybe that could help? See this for instance. I haven't use the module (nor the tool it implements) so can't comment much further. Anyway, these are just initial thoughts...

You cannot upload images directly like that...See the message in the 'green' info bar. Add an image field to the template that page is using then add an image to it to be able to select it in the RTE. Alternatively, see the text below the 'green' info bar about uploading images from other pages...

Nope..you can call it anything you want (as long as it is a valid PHP variable name) - $b, $myBlog, $thoughts, $blahBlah.... RE comments, maybe paste your template code in pastebin and I'll have a look if I can find some time....

As mr-fan stated the key here is the FieldtypePage. It lets you link those pages. For your performance concerns, I would say build your code well, use "limit" in selectors as much as possible and let ProcessWire handle the database stuff. It does it very well.

there are two main concepts... all are pages == models, objects and so on fields are your data with a pagefield you could combine all together an get your 1:n n:1 1:1 connection of your models... have a read: http://processwire.com/videos/page-fieldtype/ next hint: you have 3 models like LostKobrakai wrote: messages (messagetext, pagefield for the thread, pagefield for the user_profile) --m1 --m2 --m3 threads (simple pagefield for the connection to the messages of one thread) -t1 -t2 -t3 -user_profiles (would make this maybe separate from the existing usersystem - depends on the other things on this site/app) -u1 (refer to the $user and pagefield with saves all his messages) -u2 there is a module that helps you to get information about the pagefield relations: http://modules.processwire.com/modules/page-references-tab/ if all is configured right you could use the PW API to get your data and save your data right how do you like. For Frontend or Bakendusage (there is a module for custom admin pages). best regards mr-fan

The problem I have with SirTrevor and other similar projects I've seen are that the actual editor experience just isn't as good. It feels downright unnatural relative to anywhere else one might edit text. When I experiment with SirTrevor and others, I can't convince myself I'd want to use it on my own site. And if I can't convince myself, I won't be able to convince my clients to use it. How would you like it if we switched to SirTrevor for the editor in these forums? I think we'd have a lot less activity. There is an assumption with these tools that the end user is actually authoring the content directly in the editor. That's what I do most of the time, but most of my clients author content offline or work with existing content created by somebody else. Basically they are pasting content and often lots of it. These block editors become an especially huge pain when you are doing that. Many other types of edits just become unnatural and clumsy. It's not about the implementation of the block editor being faulty in anyway, its just that the entire concept doesn't result in a better editing experience. Where I like the block editors is that it's less to accommodate and worry about on the front-end development side. It also opens up some other kinds of element placements and previews that would be difficult with a regular RTE. So I totally agree there is a place for these editors. But I don't think we'll ever see RTEs replaced entirely by block editors, no matter how good the implementation is. Though I'm sure we'll see some good hybrids.

Absolutely, I consider it essential. Placement of images is one of many reasons to use an RTE, but it's a big one. Our tools were somewhat lacking in this area before, and that may have even been a reason not to use them. CKEditor is perhaps the Inputfield that our (or at least my) clients interact with the most in PW, and I'm committed to making sure the tools we provide in this area are the absolute best they can be, as with all areas of ProcessWire. That doesn't mean you have to use all the features an RTE provides. In fact, I rarely recommend doing that. You may find some features suitable for some situations more than others, and you have control in your field settings to determine what is available. There are some site designs I work with where I'll turn off the ability to insert images at all (or even turn off the RTE all together). But there are also plenty of site designs I work with where that ability is very important to the client or the needs of the site. One of ProcessWire's key benefits is not pushing assumptions about the front-end, or pigeonholing the software into some specific types of sites. We're trying to accommodate a diverse range of needs, not just specific ones. We accommodate specific needs with configuration. We've always provided image placement capability in our RTE, but with limited ability to manipulate the image beyond just resizing it. I've been looking to make this part better for a long time for the needs that I see with my own clients. That's what the first paragraph of the blog post was trying to explain. Beyond that is selling PW itself. It's one of those things that users look at when evaluating a CMS. Regardless of what you may think about RTEs in general, lack of RTE is a deal killer for many/most, and how good the RTE and related tools are is a seller. Look at WordPress, which is limited relative to PW in so many ways, but their tools like the one discussed here have always been significantly better than ours. ProcessWire has very little in common with WordPress, but when compared side by side for editing features, things like this make WordPress look better to the casual evaluation. This is one reason why you see WordPress used in so many inappropriate scenarios. So when it comes to tools that we provide already, I want to make sure they are the best they can be, and not just half way. That has not been my experience. I have had clients mess up things in RTEs, but rarely related to images. It's usually about typography, so I like to introduce limitations about what markup elements the client can use, particularly headlines. CKEditor with ACF and Purifier enabled has also solved the vast majority of clients-messing-things-up issues I've had in the past. Maybe your experiences are different, but these are the problems with images that I've seen with my clients: It's nearly always about poor image selection, not placement. By that, I mean the client will upload really bad stock imagery of business people on 1990s cellphones and such. This issue has nothing to do with an RTE, and is an issue anywhere the client can upload images. Clients rarely have the image tools [on their own computer] necessary to prep their image before uploading. They've not had a way to crop images to make them right for the context. For instance, needing to show a picture of a specific person but instead having only a photo with a group of people, and using anyway. Though this update does solve that problem among other things. I understand there are site designs where you want limit what the client can do with images, or maybe you want to prevent them being able to place images in text at all, leaving that for your own code to handle. This lets you have more control over the resulting layout. I get that, and I work on plenty of those too. But understand that this is a specific need in some layouts, not a universal need in every site or design. The same goes for use of an RTE at all. There are plenty of situations where entity encoded plain text or an LML like Markdown or Textile is more appropriate. But for situations where an RTE with image placement capability is the appropriate tool, I want it to be as good as it can be. This is a tool we already have, and so this update was about enhancing that tool to make it better for its intended purpose.

I'm with Soma on this one. I don't like using RTE's as well. What I would really like to see is something like craft is doing: I can see, that this is a quite complex thing with processwire's pages methodology and PageTables even provides something slightly similar already, but I see it more as a RTE replacement. You'd use it in places where you used only the RTE before. In my opinion such a field doesn't need to support more complex things besides images or textual elements. It would also just save markup for the frontend, while it would probably need to save the different fields somewhere as well. For me it's mostly about the interface. It just guides the user much more, so I would even think it's easier for them to understand, while in the same time limiting the potential points of error. Edit: I don't fully understand, why there's still a image-icon in the screenshot's RTE.

ryan, everything you put out there is so friggin' polished. Outstanding work!

Another Friday blog post with core updates just posted. This time we've got several image editing updates, particularly with regard to image editing for images placed in rich text fields. Also included are HiDPI/Retina support, an image variation tool, and more… Read all about it here, plus a video and screenshots: https://processwire.com/blog/posts/new-image-editing-features-2.5.19/

Can you please check the access rights via FTP? If the PHP script has crashed, it might be not accessible for everyone but your user.

There's a weird thing going on or I must do something silly. (dev 2.5.18) /** * Options need to be set, if not I see the below error: * Error: Exception: Error when trying to save the MemoryImage: we have no Targetfilename! ... * (weird I guess) * */ $options = array('outputFormat' => 'jpg'); // Call PIM $pim = $image->pimLoad("bright", true)->setOptions($options)->contrast(100)->brightness(100)->pimSave(); /** * There's no prefix in the filename of the image (should be 'bright' I guess), * Now the original image is overwritten every time, after 3 or 4 page loads the image will be blank. * */ /** * Setting setTargetFilename() in the PIM call and PIM works as expected. * */ $watermark = $page->rootParent->png; $assets = str_replace($image->ext, '', $image->filename) . "video.150x112.jpg"; $pim = $image->size(150, 112)->pimLoad("video", true)->setTargetFilename($assets)->watermarkLogo($watermark, 'center', 0)->pimSave(); $image = "<img src='$pim->url' />"; ---I've spend a few hours to debug, but can't find any clue.

@adrian - I have added an API method, I'm sure it will come in handy. $this->modules->ProcessJumplinks->add(string $source, string $destination, string $start = '', string $end = '') I think that the WP migrator module should check the permalink format being used (%year%/%monthnum%/%postname%/, for example) and convert it to the Jumplinks-equivalent ({year}/{month}/{name}/, in this case).

First post cleaned up as documentation is [mostly] ready. Module is now stable, from what I can tell, though v1 can only be released when PW 2.6 is released. (I'm assuming this is still a little while away... yes?)

Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.

Thanks for the welcome Can't say I have a lot of time on my hands, but our real time analytics showed a new link sending traffic our way, so thought I would check it out

There is other CMS'???

Taking a closer look now, and apologies but I haven't had enough sleep -- the parent is responsible for the order of children. So page-edit on the parent is a pre-requisite to being able to apply page-sort there. The order of children is considered kind of like a field on the parent. If it weren't, then the user with page-sort permission would be able to go sort anything they had view access to (which I'm guessing most of us wouldn't want). Though it may be feasible that I could make page-sort accessible if the user has page-add permission on the parent.

I wasn't sure what first what you meant by switcher, but now I think I get it. Assume I understand correctly, you need something to target the switch like a GET variable, i.e. domain.com/?theme=pretty Then before you send any output (like before your <doctype>) you'd check for that GET variable and stuff it in the session. if($input->get->theme) { // set the theme $session->theme = $sanitizer->pageName($input->get->theme); } Now that value in $session->theme will be retained regardless of what page they click on, or at least until they set another. When you get into the <head> part of your document where you are going to be outputting the stylesheet links, you would just check the value of $session->theme: if($session->theme == 'grunge') { $css = 'ugly.css'; } else if($session->theme == 'pretty') { $css = 'baby-unicorn.css'; } else { $css = 'default.css'; } echo "<link rel='stylesheet' type='text/css' href='{$config->urls->templates}styles/$css' />";