Leaderboard

This is an excerpt from an ongoing larger work that I am playing with so has a couple of references to things you haven't read - but it might be useful anyway. I notice that some new PW users are a bit confused about how they should structure their site within the /site/templates/ directory, so this is just some general waffle addressing that confusion rather than telling you what to do. Structuring Your SiteHere is a question that comes up in the forum more times than just about anything else: “I need to build a site that will have this bit as part of that bit and will need to have something over there while the bit under here relates to the image that isn't there and the entire lot needs to be static html….” What underlies the question and all its variant cousins is: “Is there a set way to structure the files for my site?” No. To be honest I am pretty tempted to finish this chapter here because that one little word really does sum up the entire point about ProcessWire, PHP, MySQL, Apache, JQuery and anything else that makes this system tick. None of it, including ProcessWire, is about how you want to structurally create your website; they are all tools that enable you to construct your site how you wish. Part of the problem, it seems, lies in the various demos and profiles that sdemonstrate how ProcessWire works and what it does. The very fact that they exist at all means that someone had to build them, and to do that, they had to structure them ... obviously. Developers and designers that have come to PW from other content management systems and who are used to having to follow fairly limiting guidelines automatically assume that the demo they are looking at represents how they MUST put the site together. Then they look at a different demo by another plonker and it is built in a completely different way. Bugger. The PW Templating System Most content management systems have a templating system of some sort or another. Sometimes it is based on a third party markup system, sometimes it is based around the idea of a huge amount of files that if you want to change you have to build overrides and put them in certain directories and then work out how to strip out all the ccs that is still in there. Some of them, particularly the ones that go on about CCK (Content Construction Kit, whoever that is) allow you a ton of versatility as long as you don’t mind that all the fields come complete with huge amounts of pointless nested DIVs and CSS referenced from one of the moons of Mars. Some have had this amazing idea that it is somehow really clever to separate the idea of an overall theme from the way components are laid out and therefore put them in completely unrelated parts of the file structure (some in the core that will be rendered useless at the next update). Anyone used Magento? The joke here is, of course, that none of this is about what a CMS is meant to do, it is about how to display the OUTPUT of a CMS, but somewhere down the line the two have got confused and the Content Management part of the system is now telling the public website part of the system how to do its job. And that brings me neatly to the ProcessWire Templating System. Which doesn’t exist. PW is a true CMS in that it gives you two layers of tools: Firstly it provides a way of storing, managing and processing data. Secondly, it provides an API that allows you to retrieve and manipulate that data. The bit it doesn't do is build your website for your – you are the designer or developer, you are probably the best tool for that job! There are a few rules … well, there is one rule actually, which we covered earlier: template files must have a php suffix and be kept in the templates directory. So, whether you construct your site using header and footer files included into your main templates, or whether you use a delegated approach or just one core template that you use to drag in markup from other files, or whether you use the API directly into a template, or as part of a php function or stored in a separate file, or whether you use jquery, ajax, JavaScript or anything else, this is all up to you and is NOT part of the PW system. It is back to how we started (in the main tutorial) with just one line of PW markup in an empty PHP file. <?php echo $page->title; ?> Now throughout this tutorial I will probably stick to some pretty basic construction – I will tend to use the API and PHP directly into a template file and possibly use an included header and footer just to reduce the amount of markup kicking around. However, this is not necessarily the best way of creating a website in PHP and PW, it is just a nice clear way; that is all. The PW forums have all kinds of discussions on different approaches for using PW and PHP and files and so do forums and blogs all over the web. The very fact that PW does not rely on one particular way to construct a website means that all those ideas from all over the place are perfectly valid and can probably be used in PW. Freedom is a wonderful thing, and so is a proper CMS. Joss

I was reading the HTML5 Boilerplate .htaccess file (like you do), when I came to the bit about filename-based cache busting. TL;DR Resources used by a web page that will rarely change (js, css, images) should be given an 'expires' date well into the future to take advantage of browser (and possibly proxy) caching. However, when they do change, you need to tell the browser to load the new version instead of the cached version. Using query strings (eg styles.css?v=2) is not the best way. The html5bp htaccess references a blog post by Steve Souders on this topic. The 1st comment to this post references a way to include automatic versioning for these types of resources, based on the file date. (That last link pretty much summarises the whole deal, if you haven't time to read the other links.) The reasons why I mention this are It's an interesting subject. It seems to me to be something that could be implemented in PW for relatively little initial effort, but have significant benefits going forwards. Now my technical ability is limited as far as implementing this goes, but that's why I mention it here. I don't know if this should be a core feature request, or a module, or what, but I offer it for discussion. What do you think?

In which case developers should really be required to pick a license (and include it in their repo - you have to include the full text somewhere don't you?) before a module is approved. A bit of a pain for those already on there, but I'm sure we could check them all between us. That or a nice automated email from ryan to those who submitted the modules which lists their modules and asks them to include a license and update the module page, then perhaps go so far as to remind people who've not updated it within 60 days to do it again, then after another 60 days take them down? Then again I've not had my coffee this morning yet so that's probably far too severe. It would be fantastic for people to actively respond to such requests if we send them one - it would at least show who is looking after their own modules (though admittedly I can be slow with Github pull requests at times!).

that makes no sense. The original must be greater than the resized version. And even with jpeg format, the original source should be 100% quality (and therefor greater than resized versions) and only the outputted / resized versions should be degradated to lesser quality (70 - 90). If you use a lossy compressed source, you multiple times add artefacts to the outputs. And PNG can be compressed too. -------- Workflow 1 could be: local source format TIFF, 16bit colordepth (ECI-RGB_v2 or Adobe-RGB) (regardless of with or without lossless compression) convert to sRGB colorspace, optionally scale down to max 1600px, reduce colordepth to 8bit and save it as JPEG with quality 12 (photoshop) or 100% (other software) upload this JPEG as original source try resizing and sharpening with unsharpMask($amount, $radius, $threshold) from PageImageManipulator Workflow 2 could be: local source format TIFF, 16bit colordepth (ECI-RGB_v2 or Adobe-RGB) (regardless of with or without lossless compression) convert to sRGB colorspace, optionally scale down to max 1600px, reduce colordepth to 8bit and save it as PNG without compression upload this PNG as original source try resizing and sharpening with unsharpMask($amount, $radius, $threshold) from PageImageManipulator and test different quality settings for the output (results in smaller filesizes) And once the imagick-module is ready change to it but above workflows may be worth a try.

But as you saw in your other topic, title was what you were after as I said On the cheatsheet, you want to be looking at the variables under $page for the built-in fields like title etc. : http://cheatsheet.processwire.com/ When you edit a page in the admin on a default installation, the fields are usually labelled with the field name. If you go to Setup -> Templates in the admin and edit the basic-page template for example, it will list the fields you can use in your template file - $page->summary, $page->body etc. When you reference a page that is somehow linked to the current page as in your example (a Page field that's a select list) then you have access to all the fields in that page's template. For example, if your select_branche page template had a field called "something" then you could output its value like this: echo $page->select_branche->something

There is already a thread going for this, but here you go: 1. Create TWO templates. Create a template called select-parent and a template called select-option - For this example neither need a template file, though they would need one if you wanted to display these actual pages. Edit select-parent and under family click on Allowed Template for Children and choose select-option. You don't have to do this part, but it does make for neater management. 2. Add to the template select-option two fields Title - well it will have that one anyway Value - this can be any field type. Note: If your title and value are going to be the same, then don't bother with a second field. 3. Go to pages and create your parent page. For this example we will just make this a child of the home page, but it can be anywhere within your tree structure. Click on home and create a new child page. Choose select-parent as the template and call it My Select and save. Optionally, under settings, check the Hidden box to hide this page from the front end. (It will be anyway as it has no template file) Save and close this page. 4. Click on your new My Select page and Create a child page. Make whatever children you need. If you restricted the allowed templates for children, it will automatically use the select-option template, if not, you will need to choose that template. 5. Go to fields and create a new field of the type Page. Create the field, naming it as you need and save. Under the Details tab choose: Single page (Page) or empty page (NullPage) when none selected Under the input tab change the parent of selectable pages to My Select. Scroll down and change input field type to select. Save And that is it. You can now include this page field in whatever template you need. You can add options as you require, but I would be careful about deleting them!

Small(ish) request related to modules directory: could we get a field for selecting license used by the module? At the moment it's often very unclear what's the licensing policy for an individual module. I'm hoping that this would -- in addition to making this information more obvious when browsing modules -- also give module authors a slight (and much needed, I'm afraid) nudge towards actually defining which license the module is distributed under. A simple text field would be enough for the time being, but a list of possible / most common licenses like GitHub has implemented would, of course, be even better.

You are right, - like me - many have ask this. It takes us a long time to think 'out of the box' coming from joomla, wp or any other similar cms. But even if you mention, any site has a different structure, it still does not tell newbies where to start. In fact, I made the mistake starting from foundation site profile - which of course is good. But the logic that goes around in skyscrapers is more meant for me being a newbie. So, what I am doing now is write everything down in a tabel: Parent: Admin>template: name | label | field(s) - Admin>page: name - Server>templates: filename - and front-end menu item Children: Admin>template: name | label | field(s) - Admin>page: name - Server>templates: filename - and front-end menu item In this way I can see the connection what's going on and especially where it would be called and displayed. For instance, I renamed the field "architects" to "companies". I then had to resemble this change in setup>template>architects - and under input-tab, renamed the architects.php as well. The field also uses a selectable parent page named "Architects" I had to rename that through >pages to. Since my menu item was called "Architects" I had to search where this was taken from, it was in _out.php, so I changed that. Of course since some things change - especially in php, you need to open up all files to find reference to this fields - but long live sublime! So, practise is good for learning. And I think this is what people mean when they talk about structure: fields (back-end) are used on templates (back-end); pages (back-end) use templates (back-end), and contain content; templates (back-end) use most-of-the-time .php files on the server in templates folder - those on the server display content; and if you look at the back-end - setup>templates - advancedTAB - under 'rename' only then you will find out which actual .php file is used. from there you need to - kinda like - backtrace the steps. For me this works, but of course you would need a working example like skyscrapers - no disrespect to other site profiles. And by the way, I really had to think differently: processwire "site profile" - is called template/theme by other cms; processwire "templates" in topics/tutorials are usually those in the back-end - but many times it is not clear - and that is where confusius starts to fog our mind.... processwire "pages" - is just an entry in the DB.

That's why I like this forum so much, non coders are not left out but are also learned into pw to become part of the scene.

I don´t

@kongondo Thanks for this follow-up. Fredi doesn't reveal the link to Admin. You're right. I'm just imagining a case when a user would try to go through anyway. If it is default PW installation, he could try and type '/processwire/' in the URL and if Fredi is used, then the user has page-edit role, so he can see the whole website tree (he can't modify it). But he can see, for example, names of other members, totla number of members and so on... Which, in my opinion, he shouldn't. Anyway, I don't want to 'polllute' quickjeff's post If this discussion has sense, maybe it should continue in my previous post or in Fredi's module discussion. And I guess Ryan answered this as well :

$user by default is always the user viewing the page. You should never overwrite that for stuff like this - instead use something like $myuser = $users->get(... and then you won't cross-contaminate your $user variables. I marked your workaround as "unsolved" purely because it's unwise and not an ideal solution - please don't be offended but we don't want people using this as a solution.

A very good idea. If it were baked into the information in the module file near Author etc then it could even pick it up automatically, but manually might be best as some people (my included) just don't even think to specify a license. What do you do in the event someone doesn't specify one by the way? Assume it inherits GPL from ProcessWire?

Just for interest, why do you go from Lightroom to PS rather than just export from LR? Or can't you do png from Lightroom and I never noticed... Horst, that add noise trick is really useful. I couldn't appreciate it on my desktop but it really shows up on my kindle - very neat.

Beware of that code Luis, You're overwriting the $user variable. ( could have some side efffects, but didn't read all the posts well enough)

just tried to ninja edit before u noticed my post my little workaround so far: $user = $users->get($user->id); on top

No problem. Please note that ProcessWire (PW) automatically creates the name from the title you enter. You can see this on the settings tab of a page. Where you can also edit the name should the need arise. PW pagename creation in the admin follows these rules: all characters except for these ASCII characters: "a-zA-Z0-9_." (not including the quotes) are removed. It also truncates the length to 128 characters. Spaces are turned into "-". Uppercase is getting lowercased and letters like "é" or "ô" are turned into "e" and "o", so: title:Great Pagé ! -> name:great-page

If you want to echo the title, just do $page->select_branche->title Without specifying a field on that page you only get the page ID. You can also get the name and any other fields in a similar way.

I must admit I have been fighting CKEditor a bit - I find it harder to customise, but that may just be because I know Tiny better. Also, Tiny 4 really should be evaluated first. It also has inline capability. http://www.tinymce.com/tryit/basic.php The other thing that should be looked at is some of the simpler HTML5/JQuery editors - very lightweight and probably all that is needed for many fields.

Put these lines in your htaccess: RewriteCond %{HTTP_HOST} !^sharespost.com$ [NC] RewriteRule ^(.*)$ http://sharespost.com/$1 [L,R=301]

I found this earlier today! https://sublime.wbond.net/packages/ProcessWire%20Snippets%20-%20Basic https://sublime.wbond.net/packages/ProcessWire%20Snippets%20-%20Advanced

Ha! A couple of years ago I got a call from a station saying a client had a jingle which needed an edit on it - some old thing they had used for years. So I said to send it over. When it arrived, not only was it some thing I had composed years before for a different client and so was not licenced for them to use, but it had never been licenced for any of the stations they had been on and the singer's licence had run out ten years before. I did quite well out of the ensuing letter from my lawyer...