Joss

Its just a page tree with the various documents in it - just like the rest of the PW page tree. Just not available on the front end of the site. Probably under admin somewhere, I would think.

If you want a quick way of creating loads of selectors, then try this http://modules.processwire.com/modules/process-page-field-select-creator/ It creates the templates, the relationship and even the fields. You might be interested in a Villa site that Ryan did with processwire that used pagefields for criteria: http://www.villasofdistinction.com/ And if you need, you can also look at the Page Table field where you not only establish the relationships and can create new variations from the field, but those variations can be complex pages in their own right. There is no problem in ProcessWire with using lots of templates to create familial relationships. You are not going to stuff the system and you can tie down what can be added at any fixed place. I must have missed something, but I am struggling to work out what you need to achieve that the existing powerful system does not already do.

You need to read my earlier posts!

Templates are there to give the very functions you want - that is what their job is

The idea is that initially, on module installation (or something like that) it imports the associated docs into the document page tree. That tree can be edited, added to and so on as normal. When it comes down to viewing, this is permission based, but essentially it is like a very simple baby doc site. One thought I had is that with various editor permissions on a page by page basis you could allow users to view a doc, or add notes to a doc or edit a doc. The middle one is particularly useful if users want to add little reminders or explanations without being able to edit the core page.

It makes a lot of sense for the menu to reflect the page tree - your site map makes sense, pages are easy to locate in the back end because they follow the identical structure to the front end and so on. I think there is an inherent danger if a client pushes and pulls their menu around too much - you can get a lot of broken links and illogical cross linking after a while. So a system where they have to work logically can be a life saver.

Martijn is absolutely right here. There are two sides of any website - how it looks and how it is managed. Processwire, unusually, actually has a really logical separation - the /site/templates/ directory is how it looks and the admin is how you manage it. And, as you know, joining the two together is very, very simple. So, probably your starting point, with that pencil and paper, is to forget it is a CMS at all and work it out as if it were a static site. Once that is done, you can then allocate the various parts of your theoretical site to the two sides - the html to the templates directory and the content to the admin. From that, your structure will probably become clear very quickly.

Cloudflare, in its most basic free version, which is what I am using, simply caches any assets, So you do not need to do any synchronising in that sense. during development you can simply bypass the caching or you can go to dev mode which does the same thing, but turns the caching back on after three hours. To a greater extent Cloudflare just works out of the box. The only thing I tend to change is 404 - Cloudflare has its own 404 system that brings up a site search, but that is branded as cloudflare unless you use one of the paid plans. However, you can just turn that bit off. The best thing is to read through all their docs - they have a huge amount of things you can play with, even on the free version, including caching javascript, handing google analytics and so on.

I suggest that whatever you do you stay away from any fixed scaffolding framework. The point of ProcessWire is that people can use whatever layout structure they want. For instance, many like Bootstrap and Foundation as complete solutions, but many others find them large and cumbersome and too limited. If you have a large framework with lots of JS and CSS and then people want different JS for different slideshows or product display and so on, you can end up with an inflated beast. So, I would suggest you stick to the functionality in a very agnostic way and make sure it is done in such a way that people can create the template files it as they wish.

Er ... not sure I totally follow this. Are you using CKeditor and if so, are you not using the image button to add images from an image upload field? If you do not want them to do this, but limit what they do with an image, you can use a bit of hanna code that takes an image from a single image field on the page and inserts it wherever they put in the code in their text.

On the custom post issue - in ProcessWire there is no need since EVERYTHING is a custom something. Unlike Wordpress there is no default type of template like an "article." For a better understanding, I suggest doing a test install with the Blank Profile which is what most use once they get their head round PW. You will see there is only one field created and only a couple of templates. You create your own content types. Try this tutorial: http://processwire.com/docs/tutorials/simple-website-tutorials/the-basic-website/

Okay, I will address the Pages issue - I am somewhat famous for it! To start: https://processwire.com/talk/topic/2296-confused-by-pages/ And once you have that out of your system, here is the real info. Basically, a page in Processwire is just a container for content - nothing more. So, it could be a: Web Page News Bullitin Block of info Some strange widget An option for a dropdown selector A gallery item A review Something that gets stuffed into something else! A parent of some other group of pages, A child of something Basically, it is just an item that is created using the criteria of a template. It does not need to have a template file associated with it - if you are using it as a simple option in a drop down, what would be the point? Fields from a particular page can be called into another template or page or anything else, either singularly or rendered as a group. The contents of a page need a template file to be displayed on the site as they are, but not if they are being displayed by something else. Confused? The bottom line is don't think of a page as a "page" that you would get in Wordpress - just think of it as a container for data that can be used for anything at all. This is why Processwire is a TRUE content management system - because all the elements are simply tools to help you manage content, they do not force you to make your content any particular shape.

One thing I will say, if there are not huge differences between the pages, don't lose a lot of sleep over ajax. When it comes into its own is where you have a lot of information and things like different sized images and so on and the list is very long - at that point you don't want to be loading up extra bits. But, as I say, if the differences are minimal, stick to css!

Sorry to cause confusion. Basically I was telling another member that the subject was closed, rather than I was going to technically close the thread - it does not really warrant closing the thread. A wonderful case of idiomatic British meets international forum speak. I am happy to continue chatting about the very basic and simple idea I first proposed, but I will not be discussing a long-winded, over complicated, over centralised system that no one has time or inclination to manage. That should be discussed in another thread should people be interested.

I think that should be a metaphor for life

You simply do not listen. NOTHING here is about the core. This is about a module idea. It is completely optional. It does not need to be part of any translation system if that is not wanted. It does not even need to be taken up by module developers if they do not have the time. So, will you stop hijacking my ideas my introducing things that I was not talking about. You simply bring discussions to a grinding halt. Consider this topic now closed

Yep, they are all there. You need to press the advanced tab to show the system ones.

To be honest, part of this is plain laziness - by all of us. What I keep trying to find time to do is to create a really good catalogue as a starting point - and that can be done in PW without any additional tools. And THEN look at what I need. I suspect that the hill will be less of a climb once the first bit is done. So, perhaps the REAL conversation should be: what is the ideal catalogue structure in PW? And then go and do it.

I certainly have no trouble with dealing with a company backed by private money - whether that is by a VC or private equity investment. The real issue is WHO is running the company and what their brand values are. Currently, Ello's values are about no advertising in your face and a more simplistic way of interacting. If that works as a business model, then that will be fine. If not, then it is a shame, but it will be an important lesson. The advantage of a VC is that they are looking for a bottom line - they are only interested in how you are running your business, what your ethics are and so on if you are not making profits. If you are chucking profits at you, then they are as happy as anything and will be able to line up a whole raft of buyers to choose from if that is the way to go. And that applies to any other sort of investment. Crowdfunding is not the answer in that respect - if the thousands of people that back your venture suddenly think their investment is going down the drain, they are going to complain and start pressurising you to run you business better and more profitibly.

Ha! If you want a really good reason, then look at your last line. "However I personally really like PW" There you go. All done and dusted. Now, onto the stuff about having lots of fun with ProcessWire.

I share your problem - I am great at coming up with the wish list, but useless at the ability to do something about it!

Thanks, LostKobrakai, and that is the difference. And the site specific use was the intention of my thread.

Part of the trick here is not loading too much that is, perhaps, unused. If the layout differences are minor and both have exactly the same content, then changing the outer class as mentioned above is fine. However, if the the change is major and perhaps does not include all the same information, then you may want to play with some Ajax. Obviously, this has issues with people without Javascript. So, in this case you need to call the information in as a page for the ajax to work. (I think). The template+page that you are calling would have two container divs (partials), each containing your different layouts, image sizes, data variations or whatever. Using the ajax .load() function, you would call in the page and also pass a parameter for the partial. How this would work into your system would take a bit of working out, but it does mean that you would reduce overhead on a very complex system.

Do a quick google on "Exception: Method Page::localUrl does not exist or is not callable in this context" It leads to a handful of PW threads that may give you some clues.

Thinking about things like opencart and so on, one thing I think could be very important with a PW cart is that it does not necessarily come with too many customisations via admin. So, in its basic form, you would customise the way it renders just as you would with any other processwire site, rather than have to create bits of layouts that then have to be chosen in the admin and so on. It is not that I think those are a bad thing in themselves, but that sort of customisation can make the file/template system a nightmare. One thing that I always like about the early paypal cart system was that you shoved one line of code where you wanted the button for each product in your static site. That made things pleasant! So, I think there could be two levels here: Apeisa's approach where the creation of the catalogue and how it works is down to you and the hard-core functionality is supplied by modules. A profile based on the above that has a prebuilt catalogue system and maybe more of the look and feel functionality of Opencart, Prestashop and so on. I think for a lot of people in here the first would be popular because we each have our own idea of how a catalogue should be structured