Joss

A short tutorial/help package aimed at new users (Note, a more step by step version of this tutorial is now available on the Wiki as a follow on to the Basic Website Tutorial - http://wiki.processwire.com/index.php/Simple_News_System ) - BE CAREFUL - don't mix the two. Either use the wiki or my files, not both at the same time. To be honest, you will learn more using the wiki version. This is an example script showing how to create a very basic news system with categories in PW. It includes templates and functions and full instructions of how to use it, which fields to create and so on. This is NOT a module or an instant solution, but it will help get you going faster if you have not done this sort of thing before. This example is for when you have a site carefully constructed round the page hierarchy, but want to add a basic news or blog that sits at least partly outside that tree. The system helps you to create a single news page that lists articles that are stored under a hidden parent. The articles are sorted by category - categories are created under another hidden parent and are selected with a page field. Full instructions are in the main newsfunctions.inc script and everything is commented. You can find it all here: https://github.com/jsanglier/Pw-News Joss PS: This is just one way to do a news system and should be taken as an example, not as the best way.

Absolutely, and it is not designed to compete with WordPress either. Having said that, you can create incredible blog applications with ProcessWire - just for fun!

Please do. I had to make some odd changes to it because, of course, I created it with one of my installs which has things in strange places! I think I changed it to fit a standard install, however.

@ Aren One thing you need to remember is that ProcessWire is designed to allow you to develop any sort of website - so doing some sort of a blog is only one of thousands of things you might do. Also, a blog you might want may well be completely different to what another developer wants. However, it is not that complicated - the news system I have just posted for you took me an hour or so from scratch, including writing all the instructions. And I am not a developer! So, while there is no blogging setup in ProcessWire to simplify, little bits of code that can speed up development is never a bad things to have kicking around.

"So someone in your team should be the gatekeeper for these administration resources." Yep, always keep someone around who can take all the blame. My dog has a very rough time in that regard.

I have sort of started the process by accident in answering a different post https://github.com/jsanglier/Pw-News The way I have done these (because it is the way I now tend to work) is to do them as functions that can just be rendered on whatever page.

Right, here you go! This is three files complete with instructions for creating news. You need to do some work, but a lot of it is done already. Full instructions are in the newsfunctions.inc file. Just copy the three files to /site/templates/ and then change as you wish. This does not NOW includes categories - just a simple news posting. But it is enough to get you started. It is for a main news page that lists news articles and links them through to their own template. The news articles are all pages created under a hidden page. The main news index page includes pagination. https://github.com/jsanglier/Pw-News Joss

Okay, I am sort of working on both - give me a day or two.

Interesting review, and I have sympathy with his confusion about pages - which is why I wrote my tongue in cheek post about pages ages ago. However, he has missed the point that pages are a versatile tool and not just lump of text. He also seems to have misunderstood about the relationship between the page list and the site and that you are not limited to the page list structure if you dont want to be. I think he sees it as something that is great for a handful of pages and does not realise that it can be used for vast, resource driven sites and solutions. But that is probably not the reviewers fault, but maybe something that we can all sell better from this end.

I tend to make sure that the parent is Hidden, then there is no automatic link to the kids (whatever state they are in) unless you create one. That way they don't accidentally become visible because someone did the wrong setting. If you want a catch all, you could always give them a template file but don't render any of the fields. You can then redirect that anywhere you wanted. I would think just keeping the parent Hidden will be easier though and means that the children (if published) are still accessible by page fields, if you need that later.

Mine do! If possible I like to surround it with bouncing ball, flashing arrows and a horde of Angels singing "We'll meet again" Oh, and I tend not to have it linked .... This is one for Bootstrap classes. (I have left off the dancing chihuahuas) <ul class='breadcrumb'> <?php echo "<li><a href='{$pages->get("/")->url}'><i class='icon-home'></i></a> </li>"; foreach($page->parents as $parent) { echo "<li><a href='{$parent->url}'>{$parent->title}</a> <span class='divider'>/</span></li>"; } echo "<li class='active'>{$page->title}</li>"; ?> </ul>

Hmmm.. Might be exactly what I need for something

Planning! Hi Luke I am a great believer that what ever system you are working on you should only be creating the fields and so on once you have already decided exactly what is needed. With ProcessWire, since you create the templates and fields directly in the back end (as opposed to the template file which you will use for all your presentation work), this is particularly important, since you will want to make sure that you are not duplicating fields unnecessarily. For instance, if you create a particular textarea/tinymce field, you may want to re-use that on several templates across your site. Once that work is done, then the people involved have a much better idea what template files they will be creating and what they will need them to do, and that work can then be delegated to team members. Joss

I would guess that since you are not doing a specific action of removing the images field, then there is no command to delete the actual files.

I was just messing around with something else, and I realised the term "CMS Framework" as a phrase is a nice compromise.

Sounds like you have a password incompatibility problem - there is a different character length between versions. Have a search on Stack Overflow - there are a lot of posts about this - maybe one will help you.

Part of the trick is defining the target market segment. There is an industry wide problem at the moment where market segments are very poorly defined. There are two reasons for this: Firstly, the majority of marketing is done by non marketing people, and secondly this is all very new and shiny and no one is totally sure what to do with it yet. This even shows with companies like MicroGoopple - with the lack of strict market segments, they have all tended to go for scatter gun marketing in every area all at once. With ProcessWire, the issue is "Is it a CMS or not?" Well, that runs into a problem almost immediately - what on earth is a CMS? Or, more precisely, who is a CMS for? Blogger is a CMS. It is a straightforward system that allows people to manage content in a very precise and defined way. Wordpress is a CMS. It works like blogger, except you can host it locally and make it work not like blogger at all. Joomla is a CMS, except they would like to point out that it is a Framework with a CMS on top of it. Drupal is definitely a CMS - it allows you to manage anything, but it is a hell of a long way off from Blogger where we started. ProcessWire is a CMS - except it is a CMS that allows you to imagine and build your own CMS on top of it. So, it is not a CMS then? Certainly, if all the other CMSs are defined by the fact that they are a central system where you can "theme" and build modularly using modules/plugins/whatever, then ProcessWire is possibly not a CMS - it is too flexible and does not have that same central construction mantra. To a certain extent, it is a misuse of the term CMS that is causing all the problems. Out of the box, Blogger, Wordpress and Joomla are probably not CMSs, but AMS - article management systems. Since, unless you stick all kinds of third party additions to them, managing articles is all they do. Drupal is a bit more flexible out of the box. So, it would help marketing if all those others would go off and re-brand themselves as AMSs and leave the more versatile offerings to use the term CMS a little more correctly. Well, that is not going to happen - and in addition, there is quite a gap between what Drupal and Liferay do on one side and what EE, ModX and PW do on another. We have seen in these forums a couple of newer people posting, with quite genuine reasons, that they are confused that PW does not have a theming system like Wordpress has. It doesn't, of course, because it is not doing what Wordpress does - at least not out of the box. You can build a Wordpress out of it (I am having fun doing one at the moment) and you could even build a theming system to go with that - but that would be what you can DO with ProcessWire, not what it is. To my mind, ProcessWire is, at the end of the day, not a CMS as such, or an AMS, possibly more of a CMF, but not even that totally. ProcessWIre is really, a very strong starting point. If you want to develop a web tool of some description, PW is where you start. It allows you to get your visual interface and core data together very quickly and tidily and then gives you enough tools to develop a fine-grained approach to what you actually want to do with that data. In a funny sort of way, it is, for the new browser orientated development world, what Desktop development tools were to users back in the late nineties. It does a lot of the heavy lifting for you while you get on with the presentation and fabrication. So, back to the market - PW is a professional's tool. It can be used by amateurs like me and even quite effectively, but those with better knowledge are always going to be able to take development with PW far further and faster. As such, I think it should be marketed in the first instance as a tool for developers/designers (I really do not like splitting those groups), while making sure it is accessible for those with less knowledge, but like to learn. In practice this means presenting it to the development community through seminars and user-group meets, as well as making sure that each geographical market area has a common focus point (like the German website this thread is meant to be about) that can be used to gather in and grow local communities. Now, this is where I lift the lid on what the marketing industry really thinks of this sort of product. Basically, promoting open source systems is no different to promoting a rock band - you need fansites, reviews, groupies, and everything that goes with it! I am sorry, but I would be hard pressed to put a Rizzla paper between the marketing brief for a highly regarded Open Source system and one for the newest boy band. And having seen the behaviour of some developers on "other" open source projects, there is little difference there either! Joss

Oh, I love keeping you on your toes! Yeah, I think with these Framework Profiles, there should always be two - one which is basically just the framework ready to go with maybe some helper functions to be used as snippets, and a second (based on the first) which actually gives a starting point. I am putting an identical one together based on Foundation 4, by the way, though I am not going to attempt a Foundation admin!!!

Okay, sort of worked this out. Just had a look at the tinyMCE iframe inside one of my Joomla sites and in the head section of the TinyMCE content inside the iFrame is has: <base href="http://www.dancingbear.co.uk/"> Now, that is missing in the PW TinyMCE iframe. I assume it is getting it because in the JS for the TinyMCE in the head of the whole page my domain is set up as the base_url parameter. If I go to the php script that is initiallising the editor, it has this: document_base_url : \"". JURI::root() ."\" JURI::root() being the defined root of the installation. So, that is being set up explicitly for TinyMCE (and whatever else needs that value) What I don't know, is how the constant is being defined - or rather, how it is working out what the root is. It might be something to do with this: http://api.joomla.org/__filesource/fsource_Joomla-Platform_Environment_librariesjoomlaenvironmenturi.php.html#a273 Anyway, so possibly with PW, it is a case of creating a constant for the root of the installation that can be used anywhere that is required. Modules, Editors, Templates - whatever. Then everything can be treated as if it is in the root directory and have relative paths or direct paths without suddenly leaping out of the installation, however htaccess or other things are set.

No, in the "source" of the editor it shows the relative one - the same as will be used when the data is used on the front page of the site. So if you move your site, none of the internal links to images, media, etc break. Not opening slash. You have to remember that with Joomla, the admin is in a fixed directory "administration" Joomla uses a variable that defines the base url - JURI::base() - not sure if that comes into play somewhere so that it away knows where it is. This is not something you have to set up at installation or change when moving the site from root to sub or whatever. When you move a Joomla installation, the only thing you have to change is in the config which is the ab path to the logs and tmp folders - they are outside of the Joomla ecosystem as such. Unlike Wordpress, where you need to change values in the database itself, which is a right pain! This also applies to any other components - for instance a slideshow that uses images from a directory - it only needs the relative path entered: images/slideshow/ It does make things pretty consistent and you never have a problem finding stuff at least. Pity the rest of the beast is such a Dinosaur!

Hey, thanks SiNNut! That gives ms a big leap in the right direction!

Hi Ryan The one on profiles is the starter one and is up to date with this one. The reason the other one is so minimal is that I am assuming that once people know what they want to achieve, they will want to start with a blank canvas - so that is blank canvas with Bootstrap attached, but a few bits in there just as helpers This demo one is more aimed at someone who is less familiar with the entire setup, but is possibly a little bit familiar with Bootstrap, so is more of a demonstration than anything else. You can use it and get on with site design, but I was thinking that most people probably wouldn't want to ... may be that is just me! Yep, I can change the Content Management bits to tools. I tend to call it Content Management in my own setups basically because I have things like Blocks, News Ariticles and everything else that is not directly being displayed in the main menu. So it is not just tools in my case. But I agree, possibly confusing in this context. I forgot about the edit link! I will look at the indentation.

Thanks onjegolders! It was the "littered" that has been giving me a problem. If I can sort this out, this is probably a better candidate than most for writing up properly! Joss

Well, ProcessWire is far more flexible than that! Starting at a very basic level, you could create fields in your main template that you would then use in a sidebar for instance: sidebar_title sidebar_text sidebar_image or whatever you wanted. If those are included in the templates you are using, then those fields are available for all the pages that use those template - if you don't use them, they wont display anything. Next level up! You can pull content from any page. So, you could create a specific page with a specific template (but no associated template file) and use it for some global fields. For instance it could have a textarea called "extra_info" into which you add something you want to appear on many pages. In the template file for those pages you would call that field in this way: echo $pages->get("/my-global-page/")->extra_info; Getting more complicated Next up, you can use a Page field to drag in an entire page, or series of pages. For instance, you create a block template (complete with file) and give it a handful of fields. In the associated template file, you would only put in the mark-up needed to render that particular block - no header or footer or anything like that. You can use that template to create a series of blocks. You now create a page field which you will use to select one or more of those blocks. You can set up the page field to look for pages under one particular parent, or by one particular template - so you can restrict what is selected. Add that field to the template for your normal pages. Edit one of those pages and you can select a block. In the template file for your normal pages, you can now grab the contents of that field as normal, but then render the output: echo $page->mypagefield->render(); That will output the selected page, rendered in its own template. From that point you can get really imaginative. You can use the page field to select multiple pages and then use a foreach loop to render them all out. You can set up your normal page templates so that you can choose blocks for individual pages, or by perhaps putting the page field in a central source (like I did at the head of this answer), maybe make it a global block system You really can do anything you want, render things as complete pages or just pull particular fields out ... and so on. This demo site I did is done completely with blocks that are then selected from a central source: http://pwdemo3.stonywebsites.co.uk/ So, yes - it is all possible, and without having to go near a plugin. Joss

Thanks Thomas