Leaderboard

Hi everyone, I just want to share the good news, we launched a new website for a cafe in Melbourne, LuxBite. This is my first processwire website after years of experience using joomla and wordpress, this is by far one of the cms I enjoyed working with. Please visit the site http://Luxbite.com.au and leave your feedback! In short, I would like to thank all the community here - the forum is extremely useful and has a lot of information. This site is built on top of The amazing SimpleNavigationMarkup module by Soma - to be honest I am lazy to do foreach to output everything so utilizing this module is the way to go there are couple of outstanding issues and design changes that I need to work on but so far so good Extras: http://www.news.com.au/lifestyle/food/masterchef-cake-challenge-helps-revive-a-taste-for-flavours-of-the-past/story-fneuz8wn-1226666481357

If you don't need the page to be saved when the button is clicked, then I think the route you are taking is fine. If you did need the page to be saved, then you'd want your button to be a submit button, and a second (save) hook to be called after the ProcessPageEdit::processInput and to silently do its thing (no redirect). Another route you could take is to setup a separate page with a template that does what you want, and then have your button link to that instead. But the way you've done it is already more compartmentalized (less parts to consider) so I wouldn't change it unless it creates issues with other modules hooking into ProcessPageEdit at some point down the road (which is possible). One issue you probably want to fix here though is the potential for XSS: $href = $this->config->urls->admin.'page/edit/?id='.$this->input->get->id.'&e=1'; Taking a variable directly from $_GET or $input->get and putting it in output (unsanitized) is always dangerous. You'd want to do this: $id = (int) $this->input->get->id; $href = $this->config->urls->admin."page/edit/?id=$id&e=1"; or better, yet this: $id = (int) $event->object->getPage()->id; $href = $this->config->urls->admin."page/edit/?id=$id&e=1";

This is a good way to go, and exactly what I do for predefined settings like required image dimensions and such. What you set in _init.php is for runtime use of your site's template files, and probably nothing beyond that. These variables are good for initializing placeholders that you'll be outputting in your _main.php (or whatever your appendTemplateFIle is called). This sounds like overkill to me, though of course use what works best for you. But you have a couple more options to consider: Use session variables, especially when you want the value to still be present and available on not just the current request, but subsequent ones (from the same user) too: // do this $session->set('my_variable', 'my_value'); // then retrieve it from anywhere (and at any later request) like this: $my_value = $session->get('my_variable'); Set an API variable: // do this wire('my_variable', 'my_value'); // then retrieve it from anywhere like this: $my_value = wire('my_variable'); Whichever route you take there, if you've got a lot of related values to set you might want to bundle them all into an array, so that you only need to set 1 session, API or config variable.

The export profile module is 2.3 compatible, but not when it comes to multi-language sites using the core LanguageSupport modules. That's something that's been on my to-do list for awhile. I just don't use the Profile Export module often enough, but hope to update that a little after 2.4 is released.

No the syntax is right, just the logic is wrong and will never be both "false" it's a double or false trap. Just use PW way if (!$page->is("id=1001|1003")){ echo "block"; }

These should also work (on dev): // save directly from page object $page->save(array('quiet' => true)); // save just 1 field from page object $page->save('myfield', array('quiet' => true)); When quiet mode is set, the modified date is set to whatever is specified in the page. Meaning, the modified date is not updated unless you change it yourself. Quiet mode also lets you modify the modifedUser and createdUser for the page, if you want to. These are two properties you can't usually modify, but quiet mode lets you do it.

Hi! Here is my second work on PW: one page promo site for super mega cool strut mounts (some car stuff). www.ss20gold.com - ProcessWire 2.3.7 - multilingual; // pm me, if there are funny/wierd mistakes, please - scroll-scroll; - animated gif reincarnation; - about 50 times of Massive Attack - Heligoland in process. Thanks all of you, you guys are rock!

Hi All, First of all a big "THANK YOU!" to the community of ProcessWire and its founding father! It has been a great adventure developing this site with ProcessWire, allowing me to focus on getting things done! http://www.goaroundeurope.com On thing that was great, for me and for the site owners is the widget system I created. I used Pagefields for including a multitude of widgets that the site-owners place on pages in the site. They can create their own widget too and reuse them throughout the site. ProcessWire not only helped me during development, but the backend is very user friendly for the site owners. This was one of the major factors I considered when choosing the platform to build this site on. I only have to develop it once (and maintain/extend it ofcourse), but they have to use it day in day out....

I wished unpublished users are visualized with a strikethrough in the admin. The reason: this topic

There are a couple of ways to accomplish this from creating your own inputfield to using templates. This is how I would do this. You create a template called 'donations' (/donations/) and a template called 'donation' (/donations/donation). You create a called 'donations'. You add the donations fieldtype to the user template - be sure to enable "Show system templates" in the filter option above the templates in the admin. Now you can create a donation through the API: // Create a new donation page $donation = new Page(); $donation->parent = $pages->get("/donations/"); $donation->title = "Some random title"; $donation->amount = 10; // Or any number $donation->save(); // Assuming the right user is logged in $user->donations->add($donation); $user->save(); And it is saved in the Page fieldtype with the users. As a reference see the excellent cheatsheet by Soma and Ryan. You sure need some code for a user to login, to process the donation itself, bit this gives a basic example of how to save through the API. Note: this is all written in the browser so it might generate some error.

You obviously don't know owlcarousel then

Part of the goal with rich text editors (and LMLs even more) is to place limitations upon the input in order to maintain quality and consistency. ProcessWire's TinyMCE and CKEditor come configured to focus purely on portable and semantic markup. Once you start introducing non-semantic things in the markup like inline styles, colors, arbitrary font sizes, etc., then your content is no longer semantic or portable. It becomes essentially anchored to your current site design (if you are even that lucky with the client). You'd likely have to go back and make edits to all those fields the next time the site is redesigned. An even bigger problem is that when you give clients the tools to do these kinds of things, they start to get creative and think of it as an art project. But they blame you 1-2 years later when their site no longer looks professional. CMS control of style in text output ensures degradation of consistency and quality of output over time. For these reasons, you usually want to keep your content management tools (and especially rich text editors) focused purely on semantics of content, and as far from style as possible. This is one reason why I think front-end inline editors are a bad practice, as they keep the focus off the semantics of the content and on the subjective aspects of how it fits the area. Let all the style aspects be handled the site designers, in your front-end CSS stylesheets that accompany the site's design. If you still want to inject style, Hanna code is not a bad way to go because it does at least introduce some separation of concerns. It still leaves the content semantic, even if the underlying Hanna code isn't. If the site is for your own use and you are okay with the compromises, then both TinyMCE and CKEditor can be configured to let you do nearly anything you want. I'm not an expert on how to configure them that way, but if you look at the demos at either site, they have "all options enabled" configurations you can see and these configuration options can be duplicated in PW. Lastly, a plain textarea field (no rich text editor) on it's own also works well for just regular HTML input. This is what I use when I do need something that lets me copy and paste HTML directly, though it's something I'd only do on a site where I'm the only admin/editor (at least for that particular field).

When the need is there for separate DB configurations and something more than config-dev.php, I've done it like this in my /site/config.php file: switch($_SERVER['SERVER_NAME']) { case 'localhost': // set database settings for localhost break; case 'dev.domain.com': // set database settings for staging server break; default: // set database settings for production server } You should give preference to SERVER_NAME in this case (over HTTP_HOST) just because HTTP_HOST is coming from the client rather than the server (open to tampering). Though it doesn't really matter as long as your last "default" condition assumes the production server.

Ben, in the same github page there is a select where "master" is selected. Select "dev" instead and download.

On the home page and footer menu both pointing "Exclusives" to the incorrect page which gives internal server error. Other thing I have noticed is that your menu doesn't have proper link setup, what I mean is that when you hover over on the menu item you will notice only upper part of the menu each item is working as hyperlink but from middle to bottom part of the menu item doesn't have any hyperlink just link half text and half hyperlink. Other than that looking good.

And further ___buildForm recieves and returns a $form (InputfieldForm) object and not a page. So you have to do like: $form = $event->return; to get the form To get the page ProcessPageEdit is currently editing, you can use the getPage() method that you find in ProcessPageEdit #1128 $page = $event->object->getPage(); $event->object in the hook represents the module you hook into, that would be the ProcessPageEdit.module. Hope that makes sense and helps. And not it's not that trivial even for long time users.

I finally tested the code again with multiple child pages and corrected what you mentioned, there was some logic error in there.

Thanks Ryan, seems that it is again that part of year where I have to revise what goes where in my PW installs

There's a more link at the bottom of the list. Usually not something you sort manually for such long list. Also you can set the limit in the page list module.

Hi Ben I've been using the same hosting for a couple of ProcessWire sites myself. The reason I found it fails is because PW is setting the session save path to a directory, but the servers are not configured to use files for sessions - they use a different method. So setting the directory does not make sense. The latest development version of PW has fixed this problem though - it does a check to ensure that the session storage method uses files, before trying to set the path. Another issue I had with this hosting was centred around the cache file that PW generates to keep a track of installed modules. I submitted a small fix for this to Ryan a while ago, which he merged into the development version.

uses : custom seleactor to find selactable pages >> `````` parent=page.id, sort=title `````` or all ins tree below `````` has_parent=page.id, sort=title ``````

To pick this up again, I'm using twitterfeed.com to get a feed from a Blogger page and then send it to Twitter and several Facebook pages. I also get the feed with mailchimp.com and send it out as a daily mail to subscribers. All automatically as soon as a new post is added to Blogger. The posts at Blogger are scheduled to publish every day between 1.00 and 2.00 am to make sure everybody wakes up with suggestions for some celebrations of the day. I'm hoping to do this from ProcessWire from 1 January 2014 onwards, if possible also send the feed to Blogger as well.

Tried all kinds of editors, settled with Vim for terminal and Gvim for Mac, Ubuntu and Windows about 4 years ago, never looked back. You just can't beat the Vim keys!

require_once isn't ideal for prepend/append template file settings. When you call $page->render(); you want to know that everything you expect to be included is included. A lot of us call render() methods on other pages, which a require_once() could break. If there are things that need to be require_once (like function or class definitions) you can always move those to another file and require_once them from your prependTemplateFile. My prependTemplateFile usually looks something like this: // initialize page regions with default values // this will be output eventually in _main.php $headline = $page->title; $browserTitle = $page->title; $body = $page->body; $sidebar = ''; // include shared function libraries require_once('./includes/finder.php'); require_once('./includes/render.php'); As for your particular case, it sounds like you've got some logic running after output has started. You want to move that logic to somewhere before output starts. Given that, prependTemplateFile is not an ideal place to output header markup. However, if you want to continue doing that, then you may be able to place this at the top of your prepend TemplateFile: if($page->name == 'http404') return;

@lundy: congratulations, you've nailed it. That's a very good way to describe it Of course it's not literally quite like that. Since you've mentioned that you're a beginner, it might be useful to know that there's a lot more happening behind the scenes: Each page is connected to a template, which is connected to a fieldgroup and each fieldgroup is connected to varying number of fields. Taking things even further, each page is represented as a row in pages table, each template as a row in templates table, each fieldgroup as a row in fieldgroups table, each field as a row in fields table and so on. Eventually each row of data you've filled on any of your pages inserts a row in that particular field's own database table, i.e. field_title, where column pages_id identifies the page this particular row is related to and column data contains actual title field content for that page. Field tables can have varying amount of different columns, but this is the basic setup anyway. Understanding how things are connected at database level IMHO makes them more obvious on the front end side, but for most use cases (and most users) knowing what you already know is quite enough. It's still good to realize that there's a lot more to a system like this than just simple database table with couple of columns and rows Each question as it's own page does seem the most obvious solution here. Of course this still depends a lot on your specific needs; are these questions just simple question-answer type of things, how much data is there going to be for each of them, do they have comments or votes etc. Ryan recently published an events field, which could also easily be modified to accommodate very simple question-answer-pairs.

yes, you could definitely use pages to store questions, pages are the 'cellular' object in PW, they can represent anything you want them to, folders, bits of data, chunks, whatever; you could create a template called questions and then another one called question, and then allow only pages with the question template as children of the questions template; then you could import your questions using the csv module or the api.

most editors I've ever seen use <strong> for bold and <em> for italics. it's perfectly fine and not outdated at all, in fact these are semantic http://html5doctor.com/i-b-em-strong-element/ edit: oh and stay away from inline styles if you can.

Little update 1.1.1 added live search filtering, fuzzy text search only on name, author, categories and action some minor refactoring

Oh, right. I didn't begin with customization of the back-end yet. Here are some screenshots: http://faysjoint.com/admin_1.png http://faysjoint.com/admin_2.png http://faysjoint.com/admin_3.png http://faysjoint.com/admin_4.png http://faysjoint.com/admin_5.png

Hey, Didn't realise anyone was actually using this, and tbh I've not had the chance to update it in months. Adding an option to remove CKEditor + dropzone is a very good idea and when I eventually get round to to it, I'll add it in. Glad you're finding it of use though Cheers.

Thinking of it now, it doesn't seem that difficult to do this with PW. Instead of thinking of different templates on each repeater we can just have a repeater with a field or more for each kind of content. If those fields are filed the code knows what to do with them: foreach($page->repeater as $r) { if($r->image->url) { // image block; } elseif ($r->text) { // text block; } } May sound confusing to have many fields on a repeater block and tell the client to fill only one or two, but now we have http://processwire.com/talk/topic/4323-field-dependencies/, so we just have to put a radio button with all our "templates" at the beggining and show the related field groups accordingly. This will make our guessing work even easier: foreach($page->repeater as $r) { switch ($r->radio->name) { case "image": // image block case "text": // text block case "quote": // quote block } }

Just wanted to chime in and mention what I've done. I've been working on a new version of this module to support language page names. (mainly speaking only if LanguageSupportPageNames is installed) - support Multilanguage - support for correct view Actions from admin - correct urls within admin - modified locaUrl() to work correctly, coming from LanguageSupportNames module I hope you guys don't mind. I forked the project and comited current version. As you can see there's not much left from the original, but the basic concept is the same. This work was supported and sponsored partly by http://dreikon.de/ with whom I've been doing some PW support work lately. Since it's already some time ago since I made it (meanwhile tons of other work in my head) I just tested again locally with and without LanguageSupportPageNames installed and corrected a little issue. I'd very appreciate if you guys help test this version. And any help or suggestions are welcome. It may not the best code ever written, especially since it's kinda complex I'd be very happy if more eyes take a look. Ideally it would replace the current multisite module and be backward compatible. Thanks You can grab the module here: https://github.com/somatonic/Multisite

here's how i setup the custom datatable page: 1.) make a folder in site/templates called admin-custom; inside that i have a css and js folder; in those folders i put all the scripts and stylesheets for datatable (dataTable.css, jquerydataTables.min.js, jquery.uniform.min.js); 2.) make a template in the templates folder, i called it admin-product-table.php; with this code: <table class="table table-bordered" id="dyntable"> <colgroup> <col class="con0" style="align: center; width: 4%" /> <col class="con1" /> <col class="con0" /> <col class="con1" /> <col class="con0" /> <col class="con1" /> <col class="con0" /> <col class="con1" /> </colgroup> <thead> <tr> <th class="head0 nosort"><input type="checkbox" class="checkall" /></th> <th class="head1">Parent Product</th> <th class="head0">Series</th> <th class="head1">Part #</th> <th class="head0">Room Cu. Ft.</th> <th class="head1">Price Ea.</th> <th class="head0">Missing</th> </tr> </thead> <?php $products = $pages->find('template=product-child,sort=title|series'); foreach ($products as $product) { ?> <tr class="gradeX"> <td class="aligncenter"><span class="center"><input type="checkbox" /></span></td> <td> <a href="<?php echo $config->urls->admin; ?>page/edit/?id=<?php echo $product->parent->id ?>" target="_blank"> <?php echo $product->parent->title ?> </a> </td> <td><?php if($product->product_series) {echo $product->product_series;} else {echo 'n/a';} ?></td> <td> <a href="<?php echo $config->urls->admin; ?>page/edit/?id=<?php echo $product->id ?>" target="_blank"> <?php echo $product->title ?> </a> </td> <td> <?php if($product->roomsize_min && $product->roomsize_max) {echo $product->roomsize_min . '-' . $product->roomsize_max;} else echo 'n/a'; ?> </td> <td class="price">$<?php echo $product->product_price; ?></td> <td> <?php if(!$product->speaker_sensitivity) { echo '<span style="color:lime">Sensitivity</span>'; } ?> </td> </tr> <?php } ?> </tbody> </table> <script> $(document).ready(function(){ // dynamic table if(jQuery('#dyntable').length > 0) { jQuery('#dyntable').dataTable({ "sPaginationType": "full_numbers", "aaSortingFixed": [[0,'asc']], "fnDrawCallback": function(oSettings) { jQuery.uniform.update(); } }); } }); </script> 3.) under the Admin page, create a child page called Products, uses template "admin-products" (which will need the ACP_scripts_and_styles field), and uses alternate template filename of admin. Paste the links to the scripts and stylesheets into the ACP_scripts_and_styles field: site/templates/admin-custom/css/dataTables.css site/templates/admin-custom/js/jquery.dataTables.min.js site/templates/admin-custom/js/jquery.uniform.min.js some of how you set this up will depend on which version of PW you are on – see the ACP documentation about that; in my case i have a child page of Products called Products Table which uses the admin-product-table template; hope that's not too confusing; it's pretty simple, but tricky to explain; most of it you can figure out from the ACP documentation..

@Gabi: this sounded like an interesting idea, so I mocked up a proof-of-concept module (Page Render Relocate Assets) that dynamically alters asset requests to point to another location. This isn't, however, something you should yet consider production-ready. Idea is quite simple: the module just hooks after page render and alters generated markup, converting any requests to /site/assets/ to another URL specified via module settings. Just to be on the safe side this (at the moment) only alters requests that start with a double quote and /site/assets, ie. "... src="/site/assets/..." would get replaced, while "Look at my /site/assets/!" or "... src="http://example.com/site/assets/..." wouldn't. To test this I created a new subdomain and pointed it to my own sites /site/assets/. According to this blog post this should be enough, and so far things seem to work just fine. You can see it in action here: http://www.flamingruby.com/about/. Note that one of the images on that page is (for some CKEditor-related reason) embedded with full URL and thus doesn't get "relocated", but other one (the bike) should point to static.flamingruby.com instead. .. so to answer to your question here: changing assets location would require a lot of work at the moment, but this way you can serve them without useless cookies etc. as long as that's what you're after. If you're looking to share the load between multiple servers or something like that, this alone won't do the trick (though if combined with some kind of server-side replication that would be quite possible too.) I might have to take this module a bit further at some point, I'm kind of starting to like where this is going

To both of you: Grüezi from Vienna @Soma: Yes this is of course a better approach to set a score and then sort by it. Already have it up and running, works like a charm @Wanze: I'm sorry I haven't tried your method, because I was unsure if it really counted only the related categories or all of them. Glad to be on ProcessWire, will make a T-Shirt

We've got something on the roadmap for providing this alternate view into pages. I think there are a lot of situations where it will be helpful. For instance, seeing a list of the most recently updated pages, regardless of where they are in the site structure. Or viewing all unpublished pages (like you indicated), or viewing all pages that match a given selector, or have a specified field, etc. The list goes on. So just wanted to let you know this is part of the plan. It will be an alternate tab off of the Page List view, where you can choose that channel-type view when it suits your needs better than the map view.