Rob

I'd like to integrate an existing database, so basically it'd be nice if I could use the DatabaseQuerySelect and other classes but pointing to another non-PW database. I tried just using $this->fuel('db')->select_db('my_db_name'); and then using DatabseQuerySelect but it's clearly then trying to look at the PW database and it gives me an error 'Exception: Table 'web_v2.modules' doesn't exist...'. From the code it looks like the DB classes all refer to fuel('db') so perhaps I can temporarily change that or create a seondary db fuel object and somehow use that? I'd welcome suggestions just so that I can keep things consistent and not have to use one set of DB code for PW and another for our custom work.

Having just discussed this with a colleague, there does seem to be an agreement that a complete page "history" of every save is overkill. We would be happy to have a system where you could "preview" a page at any given point and I think there must be simpler ways to do this, perhaps using page cloning as Ryan has mentioned. The serialisation of data idea is intriguing, but of course once it is serialised you can't query it in the same way as a regular DB table. In the meantime I'm going to keep thinking about options to allow previewing or a single draft version of any page. Conceptually I can't figure out how I would allow a user to save+preview a page they are editing and not touch the current "live" page data. I understand that I can clone pages, but I need to keep the cloned pages tucked out of harms way, have the system ignore them for searching/filtering, and give the user a way to then "publish" this cloned "draft" data by copying it into the "live" page. No doubt these are all relatively straightforward tasks but I just don't yet have the requisite knowledge of PW.

Hi Ryan, thanks for the swift reply. Basically I've been trying to trace through the code and establish which bits I'd need to hook into in order to work out how I might add page versioning. WHat I had in mind was to make the page saving function save a new copy into the 'Pages' DB table each time (on the understanding that each unique page is based on a set of page name, parent and template which I think won't be duped between pages) and then have a separate table that jsut stores which version of each page that is live. As a newbie to PW I'm probably overshootig myself a bit but I thought it'd be a good learning experience to get to grips with module development and learning the inner workings. With that in mid, I'd have to write a module thyat hooked into many parts of the system to make this idea work, as every page save would need to work in a new way, page load/filtering would need to take into account the new system etc so it's quite a big undertaking. Just to be clear, I'm not just talking about a temporary page to be able to preview edits, I'm talking about every page save being a new version, and being able to preview any version and then publish any version as the current 'live' version. Another concern is that your code treats lots of elements in the system as "pages" including users, roles etc so I don't know if this adds complexity. You wouldn't want to be able to version-control things like users, roles, admin pages etc. It's just standard pages that need to be version controlled. It ultimately may not be worth the grief of the development complexity against the benefits gained.

Thanks for pointing that out. It's not necessarily a deal-breaker for us, but if we do need the functionality, May 2012 is a bit of a wait so we may try to do something ourselves. I suppose it wouldn't hurt to see if Ryan needs help to speed up that part of the development, seems it might be a waste to have simultaneous develoopment of the same set of features.

We're teetering on the brink of choosing PW for rebuilding a moderately complex site, and as part of that decision-making we're assessing how easy it is to develop modules for custom behaviour, add admin pages for our own bespoke needs etc. One thing we may want is a version history for pages, whcih in turns feeds into the ability to have an edit->preview->publish workflow. I think the module/hook system is excellent by comparison to most CMS', but I am a little unsure of how to handle the cases where I find parts of the core code (in this case, PageFinder class) that don't seem to be hookable by virtue of not having the three underscores in the method names. Is it as simple as me adding these three underscores, and the rest of the system knows how to then make this hookable, or is there deeper work that needs to be done to make methods hookable? Thanks in advance.

I'm actually genuinely embarassed that I didn't know that, or at least had forgotten!! I'm allegedly a "professional" PHP developer for about 5 years. Oh well, we all have bad days! The makes sense with that in mind.. Cheers Ryan.

I'm tying to understand the codebase of PW, as best I can, as part of my decision-making process regarding whether to use it for a new project. I'm delving into the autojoin functionality, primarily becasue I couldn't understand why I couldn't autojoin image fields. It turns out I just had to do a one-line tweak and the autojoin checkbox appeared in the setup, but I haven't actually tested it and it made me curious about the deeper workings. It looks to me that the "getLoadQueryAutojoin" method i key here, but what surprised me is that when I searched for that method name in my IDE, it is only defined in a handful of classes and only called twice by the "Pages" class and the "FieldType" class and it's subclasses. In both cases the call does not appear to use the return value (an instance of "DatabaseQuerySelect" or NULL) and nor are the parameters references so it doesn't appear to be making any changes to and dat "in situ" as it were. This leaves me very baffled as to how this works, what pitfalls I might need to lok out for (for example is there a good reason that autojoin was disabled for images) and how it all holds together!! I appreciate this is a pretty techie question so I hope it is in the right forum, but I need to have a reasonable understanding (and therefore some faith) in a codebase before I use it for a major project. Thanks!

I think there may be a misunderstanding (and please, call me Rob!). As far as I can tell there is already fields, like Image, where I can add multiples. I jsut want to know how I can mimic this behaviour, and indeed how I can create my own custom field types. I'll try again: - At the moment, I can add an image field type, and when I am editing my page, I can add multiple sets of images each of which consists of both an image and a description. So in essence this is a multi-part field as there are two elements - image and description. I can add multiple "sets " of these two bits of data to my page. Does this make more sense?

Hi all, new to the community but a CMS old hand!! We're seriously considering PW for building a new site as it covers the 90% of scenarios pretty well, and the API hopefully gives enough freedom for the remaining 10%. One thing I am a little unsure about (although I've only been looking at PW for a few days) is how I might go about creating new field types. For example, I have been looking at the code trying to work out how the Image field works as this is a multi-part field with both an image and a description. So lets say, for example, that I wanted to create a field type that had 3 simple text fields (and I could add multiples like the image field) - how would I go about doing that? The documentation is strong in some areas but lacking in others, and I have yet to be able to find any tutorials for developing new field types. The code strikes me as being well-architected and intelligent (the hooks are far more flexible than most other CMS') but still complex enough to be tricky for a newcomer to the CMS. Thanks in advance, looking forward to getting stuck in!