Rob

Another thing that this is all making em think about is the general concept of "composite" fields - those can have multiple parts. Repeaters items are basically creating this functionality by combining multiple fields into a new template type and creating pages of this type to hold the data. Is it worth considering a better/different way to tackle this concept? I know that I can write my own composite field type, and I have done as a test, but there was a notable learning curve and it isn't much good to those PW users who are a bit less technical or who have less PHP skills. The repeater has abstracted some of this work, but it feels like some people are suggesting that the repeater is not an ideal candidate to "kludge" this kind of functionality. @diogo - Yes it is very similar, I guess I am just trying to think out loud and get some ideas down on paper so they can be further developed and refined.

One idea that just popped into my head is the idea of fields having a parent in the same way that pages do. This would actually NOT reduce the number of fields, but it would perhaps be a structural improvement that would make complex templates and sites easier to manage. If we were able to "nest" fields with a parent/child relationship then we might end up with templates with structure like this: Employee (template name) - Name - Age - Description - Salary - Department - Name - Description - Role - Name - Description With the above structure, you would have multiple "Name" and "Description" fields, but each would be nested under another field. If this nesting structure was visually indicated on the field listing in the CMS then it would be a clear visual AND structural way to have a field hierarchy. Accessing this data would look something like $pagedata->name, $pagedata->department->name, $pagedata->role->description etc. Or, in my case because I use TWIG templates, {{ pagedata.name }}, {{ pagedata.department.description }} etc. I suppose my basic "issue" (if it can even be called that) here is that the page fields are just a single-level flat list, and having some extra structure would be nice. All just food for thought anyway, I welcome feedback and discussion!

That's a bit more like it, let's get some discussion going!

Then why does Ryan even bother even touting the ability to reuse fields? You might as well say that you should prefix the template name onto the field if they are 2 different things on 2 templates, but I bet plenty of people have a "title", "description" or "heading" field that is used on multiple templates. Why not allow me to have multiple fields on the same template in difference contexts? In fact, with a repeater, I can do it already because, as I have already said, a repeater is really just a container for multiple existing fields. The simple solution here is to implement the same "max items" option in repeater field that I have with an image field, so I can just say "1 max item" and then have it dereference the first item automatically. This would effectively make the repeater a more flexible field type without having any impact on it's current use. As for the reason to have them share the same field is simple - less fields to manage for the developer, and it fits with the ethos of PW that was sold to me when I first came across it!! I'm surprised by the "there's only one way to do things" attitude on display here, it's not in keeping with the open-mindedness I've generally found in this community.

Well, it seems to me that PW has been designed to allow the same field to be used in more than one template, but sometimes (in fact, a lot of the time) there can be a need for the same field used multiple times on one template. having to have "description_person" and "description_job" pretty much destroys the concept of having simple re-usable fields. I thought the point was to be able to have nice, simple, generic field names that can be re-used. If I have to have prefixes or suffixes on my field names, this re-usable field concept goes out of the window. Basically the repeater concept has the ability to namespace by "nesting" fields under a "parent" field, and as I suggested above it would just be nice to have the ability to limit to a single item. The repeater need not "repeat" anything, it can just be a container for other fields. Sorry if I wasn't clear, but this is NOT to do with visual organisation but being able to keep fields generic and reusable. I don't want x_title, y_title and z_title if instead I can group my fields in a sensible way and only have a single "title" field in the CMS that can be flexibly used in several places.

We're getting more deeply into a project that has a lot of content, a lot of different templates and a lot of fields. As I understand it, you cannot have more than one of the same field (i.e. with the same name) in a single template. I understand this from a DB design and performance perspective and it makes sense. The issue here is that there may be perfectly legitimate cases where you might want to have a "description" field in more than one place on one page/template. Let's say I have a page that contains details of a person and their profession. I might want a "description" field for them and a "description" field for their job. In this case, what I would do currently is have a field called "person_description" and a field called "job_description". This works fine, but it would be nice to be able to nest or group fields so that instead what I get is "person.description" and "job.description" but under the hood I only need a single "description" field which is used twice on the same template by virtue of being "namespaced" in some way. One option I have is to create 2 repeater fields and both have the "description" field as a child. I can't see why this wouldn't work, but unless I am mistaken I can't restrict the number of items to 1, like I can do with the image field, and then just get the auto-dereferenced first item. I also know that I can visually group/nest items with the fieldset type, but I believe that this is purely visual. It is a great and very helpful feature but it would be nice to have this nesting control at the actual field level not just as a visual helper. I would welcome people to share their methods for managing large sets of fields, because I can see things getting pretty unwieldy quite quickly, and also I don't like the idea of having templates filled with extremely verbose field names that I have "manually" namespaced by having lots of underscore in their names! I hope this all makes sense and perhaps it will help generate some ideas for managing large field sets and how to minimise clutter for the developer. Thanks!

Yes we're talking about how small changes to a site, as it is being built/adapted in a development environment, can then be mirrored safely to a "live" site.

Not a problem, I totally understand, most devs are in the same position! I'll give it some thought myself. I'm sure that there must be some way to smooth the migration process, even if it isn't a fully-automated tool. It might be possible to at least figure out some guidelines to help people know how to manually export SQL at one end and then import the right bits at the other end.

Can anyone shed any light on the current status of this code/idea/module? The idea of recording changes into a "log" os sorts so they can be mirrored between stage and live versions of a CMS is something I've seen work very well i nthe the past. an ex-colleague wrote a plugin for anotehr CMS that did this exact thing, and it worked just fine. I certainly consider this to be a very useful feature and the kind of functionality that I know many, many other web developers often need. Most places I have worked including big publishers, design agencies and whatnot all had development->stage->live workflows and it really is a pain without this kind of thing. It would certainly be a MAJOR selling point for new users (developers and publishers/editors etc) coming to PW.

Yes that looks like the case I've upgraded to the latest dev version and that seems to have fixed the problem. Thanks!

The plot thickens.... I created a user in the CMS and I can't login with that one either. I have created new users this way before (through CMS) and had no problems, so I can't think what the problem could be.

Thanks for the help gentlemen, but no luck yet! I tried this... $u = new User(); $u->setOutputFormatting(false); $u->name = 'testuser'; $u->addRole('superuser'); $u->pass = 'test123'; $u->save(); ...and yet again the user is created and is displayed, with correct superuser role, in the CMS, but I cannot log in with it. Worth mentioning - I am using version 2.2.9. This is going to drive me mad!

I have been experimenting with using the API when in PHP interactive mode, as it seems it can be a lot quicker for some tasks and also a good way to recover in the event of DB problems/corruption and other problems. So I tried to create a user purely on command-line with the following series of commands, each typed in series in PHP interactive mode. include "admin/index.php"; wire('users')->add('testuser1'); $u = wire('users')->get('testuser1'); $u->pass = 'test123'; $u->addRole('superuser'); $u->save(); What I was expecting, at this point, was to be able to log into the CMS web interface with the above credentials, but it rejects me. Is there anything I'm doing wrong? I logged in with another user and confirmed that the user had been created and had a superuser role assigned. I am somewhat stumped!

Great, thanks!

Thanks Ryan, that's all useful stuff moving forward. However what I am still unclear on is where I can find the list of existing permissions, be they created from the core PW code or other people's modules. That is to say, the list of permissions that come from the PW core and core modules is 'page-edit'.....and what else? Is there a list or a reference?

Having some confusion over the purpose/config of the 'permission' array item returned from getModuleInfo(). I can't find anything in the forums or the docs about how this works. If Iserach the PW codebase there are many references to various 'page-XYZ' permissions but I'm not really sure how to use them. My module creates clones of pages, so do I need to explicitly specify some permission for this to be possible? Obvioulsy it wouldn't be good to have people who aren't supposed to create/edit pages being able to create clones and then publish them.

I have just published my new module Page Draft Creator to the modules section of the site: http://modules.processwire.com/modules/process-page-draft/ The basic principle is that you can, with a single click, create draft copies of pages that are hidden (from search, API searches/listing etc) and have a unique, almost-impossible-to-guess URL and can therefore be sent to clients so they can sign-off on changes before you make them to the live, published page. It does this by cloning the page and adding an MD5 hash to the URL. The draft page is technically live and publically available, but in reality only those who you share the gibberish URL with will ever see it. It's a small, simple bit of code but hopefully it goes some way towards the draft->preview->publish workflow that is often required by site builders, editors etc. Consider it beta although it is, I believe, incapable of doing any harm. It could do with testing on various versions of ProcessWire so if anyone has feedback it is welcome. In the future the intention is to be able to "publish" these draft pages by copying the content back over the live page, but at present there are issues with repeaters that mean that it is a work-in-progress. Enjoy!

My pleasure!

I have decided, for the moment, to remove the "publish" funcionality from this module and publish it for general use with the "draft" functionality alone. 90% of the purpose was to enable users to provide safe and private preview links to clients so they can see changes and sign them off. As it stands, changes targetted at live, published pages will have to be repeated on the "live" page but untiI I can figure out how to correctly clone and replace entire pages including repeaters, this version will suffice. I'll add this to the official modules section shortly.

Ryan - I'm poking through the core PW code and I have discovered, as yu no doubt are aware, that Repeater fields are not cloneable and the clone() methods simply throws and exception with relevant message. I have been testing the pages->clone() method today as part of trying to develop this page draft module and when I copy a page within the page listing interface in the CMS, I can successfully copy a page, alter values in repeater fields in the new page copy, and save them without altering the original page. So, as far as I can tell, it is possible to clone repeater fields! I am also trying to work out what my options are for trying to overwrite existing repeater fields, as mentioned above in this thread, for the purpose of overwriting a page with values from a draft/duplicate. Do you have any more insight into how I might be able to achieve this or if there is any development on the roadmap that will help? I was also wondering if there is any documentation on the way repeaters work under the hood at the DB level? Or if not, could you try to lay it out for me so I can have a crack at writing some code to clone them? I've been examining the DB but I'm just getting a headache! A nutshell explanation would be really helpful! I'm determined to get this thing working!

Thanks for the help. I've done some testing and fiddling and it looks like, for best performance, I can execute an SQL query directly against wire('db') to check modification date of a page row and then either utilise the cache or fetch entire fresh page from DB. It gave a performance gain of around 20%, nothing earth-shattering. I won't know for sure until it's tested in a live environment with real traffic (rather than on my local machine), but good to know what's possible.

The site I'm working on is built using a separate framework and purely fetch page data via the ProcessWire API. I'm using a cache component and testing the modified date of a page to test whether a fresh page needs to be rendered or the cache copy is OK. The issue I have is that I don't know whether the entire page data is being fetched at the point at which I call the API $pages->get() method, or whether each field is fetched on-the-fly as it is referenced. There is more than likely a performance increase by the time saved NOT injecting page data into a template, but what I'd really like is to be able to ONLY fetch the modified field from the page so the cache code is as optimised as possible. Can anyone shed any light on this, or advise how I can just fetch the page->modified field using the PW API? I could sidestep the API but this is a bit kludgey and I'd rather keep things clean. Thanks!

Thanks for the kind words gentlemen, but I've been a bit busy (and on holiday in the caribbean) and haven't worked on this for a while. I am definitely going to pursue it, but I'll need a bit of help because the repeater issue has me stumped!

Apologies if this isn't the right forum section, I wasn't sure where to stick a bug report. I've been toying with the development of a page draft module - http://processwire.c...ease-feed-back/ - and in the process I think I've stumbled upon a bug with repeater fields and page cloning/deleting. If I create a new page, or clone an existing one with an API function call, that has a repeater field then the number of rows in the relevant DB table increases by 1 as might be expected. However when I delete that page the DB table row count does not drop by one, it stays the same. If this is indeed a bug and not some intentional behaviour that I'm not understanding, then there is the potential for "orphan" data in that table. Ryan - does this sound correct to you? This is only based on a few brief tests so it may be worth some other users doing some tests to see if this is repeatable.

I've started updating the code to make things more simple and elegant but I've run into a problem with Repeater fields. Basically, I am now creating a cloned page (the draft) and when the user hits "publish draft" the code iterates every field on the draft page and sets the corresponding value in the original, thus copying over the data and retaining the original page ID so it doesn't mess with any linked fields etc. It's attempting a true "update" of the original page rather than a new copy being made and replacing the old. Unfortunately the following code does not appear to work with repeater fields: foreach($page->template->fields->getArray() as $field) { if($field->name != 'title') $originalpage->set($field->name, $page->get($field->name)); } What this code is trying to do is grab the data from the draft page field and update it into the original page field. This works, but not for repeaters, where the original data stays in place. Ryan / anyone - any thoughts on what the problem might be? Is this a bug or do I need to tackle repeaters in a specifically different way?