Leaderboard

The simplest solution I see: Create a template file content_block.php Create a folder in your /site/templates/ folder called content-blocks Put in all content blocks you want (can be just .text or .PHP, whatever you wish) Download and install: FieldtypeSelectFile, give it a name. Go to templates add new template with the field you just created, name it content_block. Set the setting of the field to the folder content-blocks Check the Change Page Template setting. Create for every content block a page with the content_block template. Select in every page the block you want to render. Then the magic: // name of the content block template. $blocks = $pages->find("template=content_block"); foreach ($blocks as $block) { echo $block->render(); } Or you can make a pagefield (multiple) allowing al pages with template content_block.

Hi kazu! Like with most thing ProcessWire, there are a couple of approaches to this. One thing I do often is to make a content block template, so they can be stored and edited in the CMS. Use the ProcessWire roles to restrict access if you need to. I then use a little helper function to call these, like so: function getContentBlock($param = '') { if (strpos($param, '/') === FALSE) { // $block is name $param = wire('sanitizer')->selectorValue($param); $block = wire('pages')->get("template=content-block, name=$param"); } else { $param = str_replace("//", "/", "/{$param}/"); $block = wire('pages')->get("/settings/content-blocks{$param}"); } if ($block->id) { return $block->body; } } As long as that function is included, I can do echo getContentBlock('/contact/address/'); // using path to page echo getContentBlock('opening-times'); // using page name If static files are more suitable, then you can do something more like this: echo wireRenderFile('blocks/opening-times'); Where the path to that file is site/templates/blocks/opening-times.php.

it's ->getRandom() with an a no e

Don't ba amberressad - it heppans to avaryona, avan us netiva Anglish spaekars

I had already reported this issue on Github, where I posted a problem-solution that works. Hope it helps. https://github.com/kongondo/MenuBuilder/issues/22 David

Template Cache and $page->render($options) If you ever use the $page->render() to render out partials (of another page using its template file) and use template cache for the pages you're going to render and the page where you render it, it will create a cachefile. So if you go to that previously rendered and cached page, it will render that partial. If the page is accessed before a cache is created, it will cache this one and render that in as the partial, so kinda turned around. Funny effect. And many mmms and oaaahhhs To get a better understanding what's happening read on. Simple example code from a list page to render partials of articles (likely) // from the list pages template $markup = ''; foreach($products as $key => $child) { $markup .= "<dl>"; $markup .= $child->render(array('isOverview' => true, 'class' => $class)); $markup .= "</dl>"; } echo $markup; And in the template of the article // in article template file if(isset($options['isOverview']) && $options['isOverview'] == true) { // render small partial $class = $options['class']; $markup = "<dd class='$class'> <h4>$page->title</h4> <p>$page->summary</p> <a href='$page->url'>details</a> </dd>"; } else { // render complete article $markup = "<div class='product-details'> <h1>$page->title</h1> $page->body </div>"; } // output echo $markup; So now the render call $markup .= $child->render( array('isOverview' => true, 'class' => $class) ); in the list template will cache the page it renders (the small view of it). Thus if you access the page directly it will serve the cached small view of it. Ups. Solutions This is without specifying a different template file in the first argument in the render(). The effect doesn't happen when you, let's say create a new template file (ie article-small.php) and use that to render the page. Since this new template file is not connected to the template in PW it also has no cache for that render. To show what I mean is the following with the first argument the file you want the view to render. $markup .= $child->render("product-small.php", array("isOverview" => true, "class" => $class)); Still following me? Ok there's also another method to not allow a cache file to be created. There's a default options set in the render() in PW. Bingo! allowCache is what we can also use. $markup .= $child->render("product-small.php", array( "allowCache" => false, "isOverview" => true, "class" => $class )); And everything's back to normal. Just wanted to write down a little thing, as I stumbled over this recently, to scatter some keywords about this here . I think this isn't really documented somewhere but I thought it was maybe mentioned by Ryan in a thread about when he added this feature: http://processwire.com/talk/topic/3145-multiple-views-for-templates/page-2?hl=%2Brender+%2Bcaller#entry32876. Edit: Zaaakkkk and it's in Google 9 minutes !

Wow, I see, there are many many possibilities. Because I just start to learn, I'll start with the easiest way, and perhaps it is then also the right ;-) Thank you for your tips to all of you!

yes - drop in for sure... maybe a module at some point could be convenient, since i'm predicting i'll need this a lot.

The cynic in me says it was just about getting publicity, customers and not about the actual cause at all, but maybe I'm just too negative nowadays.

I just saw this and think it's amazing. https://www.khanacademy.org/partner-content/pixar

It is the correct term and they are great! I'm using mine far to rarely in the standing mode. Besides being good for the back it also seems to keep me more focused on tasks to get done, as it's not comfortable enough to stand there just to read some random thing on the internet or other useless habits.

@ajben - let me know how it works; I'm on the road till next week, but when i get back i'll be testing it more as well as trying to get the default CSS a bit more consistent with PW inputfields; Main thing to watch out for are js errors, as i haven't done extensive testing, and if there ends up being a js error it could break other functionality on the page edit. also, i haven't extensively tested it with multiple image fields on 1 page, and multiple tags on each image - i'm not sure how this plugin saves the tags, they may be comma separated which might not work with PW image tags; some changes to the tag-it plugin may be necessary as i'm not seeing an option for the tag delimiter... edit: found the plugin setting for the stored delimiter and also tested on multiple image fields, multiple tags and all appears to work so far; $(".Inputfield_images input[name^='tags_images_']").each(function() { $(this).tagit({ availableTags: ["kenburns", "mytag2", "mytag3"], singleFieldDelimiter: ' ' }); }); (will update example code above as well)

wow! thanks for your help!!! It is working now

Have just pushed an update to the dev branch, but the feature is not yet complete.

This is what the editor looks like now. Just trying to figure out the above regarding the assignment of the selectors before I push to the dev branch - if anyone could help me out with that, I'd appreciate it.

Ah sorry, it seems I haven't commited it yet or forgot it... It's now updated.

@Christophe I think in your second menu you want $rootPage = $page->rootParent;

you have no issue here - you've just say the module what pages to show....so if you have a spitted menu with topmenu _______ | content | sidebarmenu | you could switch to show childpages to siblings so the submenu is there if you select a subpage of a mainmenu item. //sideBarMenuNav change items to view if($page->hasChildren) { //we are on a first level parent page so show sencond level $entries = $page->children; } else { //we are on second level so show siblings to actual page $entries = $page->siblings; }; using the menu i always show all options to easy change settings and/or see at first glance what is set... //just a example from one of my websites...see max_levels, show_root and other options here //markup is fitting for a bootstrap pill subnavigation... $sideBarMenu = $modules->get("MarkupSimpleNavigation"); // load the module $options = array( 'parent_class' => 'parent', // overwrite class name for current parent levels 'current_class' => 'active', // overwrite current class 'has_children_class' => 'has_children', // overwrite class name for entries with children 'levels' => true, // wether to output "level-1, level-2, ..." as css class in links 'levels_prefix' => 'level-', // prefix string that will be used for level class 'max_levels' => 2, // set the max level rendered 'firstlast' => false, // puts last,first class to link items 'collapsed' => false, // if you want to auto-collapse the tree you set this to true 'show_root' => false, // set this to true if you want to rootPage to get prepended to the menu 'selector' => 'template!=settings', // define custom PW selector, you may sanitize values from user input 'selector_field' => 'nav_selector', // string (default 'nav_selector') define custom PW selector by using a property or field on a page. Use this setting if you want to overwrite the default nav_selector 'outer_tpl' => '<ul class="nav nav-pills nav-stacked">||</ul>', // template string for the outer most wrapper. || will contain entries 'inner_tpl' => '<ul>||</ul>', // template string for inner wrappers. || will contain entries //'list_tpl' => '', // template string for the items. || will contain entries, %s will replaced with class="..." string 'list_field_class' => '', // string (default '') add custom classes to each list_tpl using tags like {field} i.e. {template} p_{id} 'item_tpl' => '<a href="{url}#start">{title}</a>', // template string for the inner items. Use {anyfield} and {url}, i.e. {headline|title}, if field is of type image it will return url to image (first image if multiple) 'item_current_tpl' => '<a href="{url}#start">{title}</a>', // template string for the active inner items. 'xtemplates' => '', // specify one or more templates separated with a pipe | to use the xitem_tpl and xitem_current_tpl markup 'xitem_tpl' => '', // same as 'item_tpl' but for xtemplates pages, can be used to define placholders 'xitem_current_tpl' => '', // same as 'item_current_tpl' but for xtemplates pages 'date_format' => 'Y/m/d', // default date formatting for Datetime fields and native created/modified 'code_formatting' => true, // enable or disable code indentations and newslines in markup output 'debug' => false, // show some inline information about rendertime and selectors used as html comments ); $sideBarNav = $sideBarMenu->render($options, null, $entries); regards mr-fan study all the options kindly (RTFM ) before getting into an issue - this module with all the options is very very powerfull!

soma's approach is one file/image == one page - this works great on central based assets like downloads (you could counting the downloads...) For images i used this approach in my first PW projects, too.....BUT i switched to the PW way of handling images. I've used some tools like: ChangeImageSelect - changes the $page of the image select dialog in PW Image Plugin for RTE's https://gist.github.com/mr-fan/4751ea179334139d1f76 AutoImagePages - to have a nice way to upload a buch of images and regardless get single images/pages from the uploaded files https://github.com/mr-fan/AutoImagePages but all this feels a little bit hackish and on the long run the users have to take different places while editing (1. upload images there 2. choose images here)...the Processwire appproach of taking files/images with the needed page (and for shure you have access to images from other pages if needed) is very straight and much easier for the enduser. (1. upload image 2. choose image - all in one place - the actual page) I was stamped by my former CMS to have a kind of media managment....but this is not really necessary on normal pages. And any kind of Overview (Files, Images) and Buchediting could be done with some modules like Lister Pro or BatchCildEditor. My current setup of using files/images: Setting for Content Images - images belong to the used page - images in the content right/left/something else - i use PageTableExtended to render different Typs of Contentblock like part_text, part_image_text_right....and so on (i don't images within RTE fields....so i strict provide my users given "minitemplates" to use - PageTableExtended rocks for such kind of contentblocks) - using CroppableImage or ImageExtra if needed - "cross assets" are under a special imagefield of the homepage (if there was less) and under a special gallery setup in the pagetree (if there was more)... - for special image things like sliders i use an extra PageTableExentended field that renders output in the backend and edit slides via PageTable Setting for Files - using a central hidden place in the pagetree - using one file == one page approach - counting download/access - with this i can provide clean urls like www.mywebsite.com/downloads/file.pdf - using PageTable field to build a User UI for adding new files easy (see screenshot in this topic) best regards mr-fan

i don't see any benefit to using a function, you could just output the list in the normal way: <ul class="oi_smalldev_categories_list"> <?php $count = 1; foreach($categories as $category) { echo "<li class='cat-item cat-item-{$count}'>"; echo "<a href='{$category->url}' title='{$category->summary}'>{$category->title}</a>"; echo '</li>'; $count++; } ?> </ul>

Thanks for all your thoughts about this (especially the beardman). Maybe my first post did not express what i wanted to say. Draft and versioning isn't a must for being in core, but a free available module with reduced functionality would be good. Sure, you could build that by yourself and PW makes it easy, but for one coming from an other CMS this is not the best answer for convincing to switch to PW. I agree that versioning is not needed in every situation, but a workflow or being able to preview a pagewihtout publishing are often demanded features also here in the forum. Everyone who is evaluating PW for using it for a larger scale website or working in a team asks for this.So telling them: "yes, it's available, but only if you pay something" (regardless how cheap it is), may they move along looking for others. It comes down to the question: what is the fundamental functionality a free CMS should offer. And here are the opinions different from one to another, so Ryan as the leader is settling the path where PW is heading.

Hey, a lot of times I create a role called "editor" and give all of the page-* permissions to it. No problems so far. But I normally forget to go to "home" template afterwards to set the permissions for the template, too. So my idea is to show a list of templates (maybe only the once you have selected as "Manage access individually") in a list like the following in the role edit screen: I think this would be a huge performance improvement and could save a lot of confusion and clicks.

∞Textformatter Normalize UTF8 uses a lightweight PHP class (Patchwork UTF-8) for UTF8 normalization. Use it if .. If you check the page with the W3C HTML5 validator, you'll maybe get the following warning: Text run is not in Unicode Normalization Form C. Or if you notice strange output in some browsers (bold letters, shifted characters, ..).What it does In Unicode it is possible to produce the same text with different sequences of characters. For example, take the Hungarian word világ. The fourth letter could be stored in memory as a precomposed U+00E1 LATIN SMALL LETTER A WITH ACUTE (a single character) or as a decomposed sequence of U+0061 LATIN SMALL LETTER A followed by U+0301 COMBINING ACUTE ACCENT (two characters). világ = világ The Unicode Standard allows either of these alternatives, but requires that both be treated as identical. To improve efficiency, an application will usually normalize text before performing searches or comparisons. Normalization, in this case, means converting the text to use all precomposed or all decomposed characters. There are four normalization forms specified by the Unicode Standard: NFC, NFD, NFKC and NFKD. The C stands for (pre-)composed, and the D for decomposed. The K stands for compatibility. To improve interoperability, the W3C recommends the use of NFC normalized text on the Web. -- W3C

Hi. I get this error when saving menu items. The problem only arises when language support installed. Error: Call to a member function getLanguageValue() on a non-object (line 1750 of /Users/vayu/Sites/processshop.dev/site/modules/ProcessMenuBuilder/ProcessMenuBuilder.module) This error message was shown because you are logged in as a Superuser. Error has been logged. I have tested this on a clean install of Processwire version 2.6.1.

Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.

Checkboxes like that a Page reference fields. Checkout this:

Hey all, I've converted the ProcessWire 2.3 rules to Nginx. Hope this will help some people Greetings, Niek server { listen 80; listen 443 ssl; root /var/www/example.com/public_html; server_name example.com www.example.com; ssl_certificate /etc/pki/tls/certs/example.com.crt; ssl_certificate_key /etc/pki/tls/private/example.com.key; client_max_body_size 50m; access_log /var/www/example.com/_logs/access.log; error_log /var/www/example.com/_logs/error.log; # ----------------------------------------------------------------------------------------------- # Set default directory index files # ----------------------------------------------------------------------------------------------- index index.php index.html index.htm; # ----------------------------------------------------------------------------------------------- # Optional: Redirect users to the 'www.' version of the site (uncomment to enable). # For example: http://processwire.com/ would be redirected to http://www.processwire.com/ # ----------------------------------------------------------------------------------------------- if ($host !~* ^www\.) { rewrite ^(.*)$ $scheme://www.$host$1 permanent; } # ----------------------------------------------------------------------------------------------- # Access Restrictions: Protect ProcessWire system files # ----------------------------------------------------------------------------------------------- # Block access to ProcessWire system files location ~ \.(inc|info|module|sh|sql)$ { deny all; } # Block access to any file or directory that begins with a period location ~ /\. { deny all; } # Block access to protected assets directories location ~ ^/(site|site-[^/]+)/assets/(cache|logs|backups|sessions|config|install|tmp)($|/.*$) { deny all; } # Block acceess to the /site/install/ directory location ~ ^/(site|site-[^/]+)/install($|/.*$) { deny all; } # Block dirs in /site/assets/ dirs that start with a hyphen location ~ ^/(site|site-[^/]+)/assets.*/-.+/.* { deny all; } # Block access to /wire/config.php, /site/config.php, /site/config-dev.php, and /wire/index.config.php location ~ ^/(wire|site|site-[^/]+)/(config|index\.config|config-dev)\.php$ { deny all; } # Block access to any PHP-based files in /templates-admin/ location ~ ^/(wire|site|site-[^/]+)/templates-admin($|/|/.*\.(php|html?|tpl|inc))$ { deny all; } # Block access to any PHP or markup files in /site/templates/ location ~ ^/(site|site-[^/]+)/templates($|/|/.*\.(php|html?|tpl|inc))$ { deny all; } # Block access to any PHP files in /site/assets/ location ~ ^/(site|site-[^/]+)/assets($|/|/.*\.php)$ { deny all; } # Block access to any PHP files in core or core module directories location ~ ^/wire/(core|modules)/.*\.(php|inc|tpl|module)$ { deny all; } # Block access to any PHP files in /site/modules/ location ~ ^/(site|site-[^/]+)/modules/.*\.(php|inc|tpl|module)$ { deny all; } # Block access to any software identifying txt files location ~ ^/(COPYRIGHT|INSTALL|README|htaccess)\.(txt|md)$ { deny all; } # Block all http access to the default/uninstalled site-default directory location ~ ^/site-default/ { deny all; } # ----------------------------------------------------------------------------------------------- # If the request is for a static file, then set expires header and disable logging. # Give control to ProcessWire if the requested file or directory is non-existing. # ----------------------------------------------------------------------------------------------- location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|eot|woff|ttf)$ { expires 24h; log_not_found off; access_log off; try_files $uri $uri/ /index.php?it=$uri&$args; } # ----------------------------------------------------------------------------------------------- # This location processes all other requests. If the request is for a file or directory that # physically exists on the server, then load the file. Else give control to ProcessWire. # ----------------------------------------------------------------------------------------------- location / { try_files $uri $uri/ /index.php?it=$uri&$args; } # ----------------------------------------------------------------------------------------------- # Pass .php requests to fastcgi socket # ----------------------------------------------------------------------------------------------- location ~ \.php$ { # Check if the requested PHP file actually exists for security try_files $uri =404; # Fix for server variables that behave differently under nginx/php-fpm than typically expected fastcgi_split_path_info ^(.+\.php)(/.+)$; # Set environment variables include fastcgi_params; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; # Pass request to php-fpm fastcgi socket fastcgi_pass unix:/var/run/example.com_fpm.sock; } }

Any modules that extend: Inputfield, Process or ModuleJS will auto-load their CSS/JS files if they have the same name as the module and appear in the same directory. However, in order for that to work, their init() method has to be called. So if your module extends one of those, and has an init() method, then make sure to call the parent init() method: public function init() { parent::init(); // ... then your code }