Leaderboard

Hi Guys, So we have been working with ProcessWire for sometime now. We absolutely love ProcessWire so much that we have changed our site from a custom build on a custom CMS to WordPress and now ProcessWire and will never go back to anything else. We launched a small version of our site to test the migration from WordPress a couple months ago and now have finalized a new look and feel. We are a small team based out of the Chicagoland area that is eager to grow. Our go to CMS is ProcessWire for our clients. Please take a peak at: QuickToImpress.com We are currently running the latest version of ProcessWire with Template Editor Module. We are looking to start building some of our own modules in the near future. Ryan Cramer, thank you for such an incredible CMS. ProcessWire community, thank you for such an amazing group of fellow developers, designers and SEOS. You guys are all great and have helped us grow so much with answers to API questions, suggestions and advice.

Pierre-Luc: on the product catalog side: everything you have in your PW arsenal, will be in your PadLoper shop also. So multi-language. image galleries etc.. all that kind of things will be done how you like to do them with ProcessWire. So multi-language products are definitely easy thing. Your idea about multilang emails is interesting - and I have it already covered. I actually don't store any templates in text files (I dislike any templates in text areas). What I have setup is very simple (but may I say clever!) thing. All the default templates are stored in /site/modules/PadLoper/templates/*.*. Those are normal PW template files. so you have all the template variables and multilang stuff available there. But I don't want anyone to edit those files directly, so you can add same templates into /site/templates/padloper/*.* and PadLoper will use those instead. So let's say we have email-order-confirmation.php template file. It's by default multilang ready, but if you want to customize it further, you simple copy the file into /site/templates/padloper/email-order-confirmation.php and edit it to your needs. And remember, you have all the template variables available, like $pages, $modules, $config etc.. Many of the templates also get $order variable, which has the current order and all it's information (customer, products, prices, taxes etc). If you want to use these templates in your own code, it's also simple: $t = $modules->get("PadRender")->getPadTemplate("email-order-confirmation.php"); $t->set("order", $order); // This template file requires $order variable echo $t->render(); That make's it sure that you always get the customized version, if you have one, and the default one for those that don't have. And then of course I have shortcuts for the most common templates, renderCart() etc - but customizing their markup is as simple as others (just creating copy of the file into site/templates/padloper/ folder.

Just wanted to let everyone know that thanks to @Sephiroth we now have support for comment migration - you'll need to grab the latest commits for both Migrator and MigratorWordpress! Next on my list is custom fields ...

I am, uh, impressed . Very nice and clean site (love the fonts and colours!). Loads quickly too. Nice showcase sites as well. Thanks for sharing Jeff

Have just done a big cleanup. Main things still to do: (also see the task list on GH) - History/hit counter (I think the latter would be adequate) - Import/export (doing that today) I'm also going to reverse a few things to make this compatible with 2.5.3.

Site profiles are definitely the way to go if it's something you can decide right from the start; "to begin with, this site will have these fields, these templates, ..." etc. Module would be more beneficial if it's a feature you may want to add later on. A blog or discussion module installing its own fields and templates, and so on. For the actual answer, you don't use hooks for this. Include install() method in your module, and create anything you need there -- and uninstall(), if you want to be able to clean up anything created by this module just by uninstalling it. These run automatically when ProcessWire installs or uninstalls a module. For examples, this is how ProcessVersionControl does it, and here's how it's handled in ProcessUserGroups.

Hi @paulbrause, Lots of great suggestions above regarding PageTable fields etc, but I just put together a quick module that I think does exactly what you are looking for. https://gist.github.com/adrianbj/2b3b6b40f64a816d397f To make it work as is, you will need these: Templates: album (for the album parent pages) image (used for the automatically created child pages) Fields: images (for the album template) image (for the image template)

I've been working on a module to make it really simple to upgrade ProcessWire from one version to another. Especially as a way to make it easy to upgrade from PW 2.4 to 2.5, or to upgrade from one dev version to another. This tool supports upgrading between any branches of ProcessWire (currently we only have master and dev on GitHub). It will also let you downgrade your ProcessWire version, though no reason to do that. The module keeps up-to-date directly with GitHub, so it works as a long-term tool for every upgrade if you want it to. It works best if your file system is writable. However, if it isn't, the tool can still be used. It will still download the upgrade files to the server and then tell you where to move them. I should also mention that this module is somewhat inspired by a similar module Nico built awhile back called AutoUpgrade. So far I've used this tool to upgrade this site (processwire.com), the skyscrapers site, and the modules site (modules.processwire.com). Before releasing this officially in the modules directory, or suggesting it for production use, I'd like to get some help testing. If anyone has availability to help test this on non-production sites, your help is appreciated. It can be downloaded from GitHub here. As a bonus, it will also be a good opportunity to help test PW 2.5! Thanks in advance. What I'd really like to do as the next step with this is make it support upgrade by FTP. That would provide a nicer and safer solution for those that don't have writable file systems on their servers. This tool should be compatible with ProcessWire versions as far back as 2.3.4. I will also update it to support older versions than that if there's demand for it.

I have been spending some long evenings building PadLoper. It is my personal project to challenge myself as a developer, but also something I believe ProcessWire really misses: a solid eCommerce platform. I am happy to announce, that I am not very far away from public release, so I did create a little teaser site and email list for all of you that are interested: https://www.padloper.pw/ As many of you now, I also have bunch of eCommerce modules called "shop for processwire". Those remain open source modules, but I am not actively maintaining them (like I really haven't since 2012). All the code in PadLoper is new and it's totally build from ground up. If someone wants to maintain or develop shop for processwire further, I am more than happy for that. There will be some open source components coming from PadLoper also: at least payment modules, but I might also open source the shopping cart module. Padloper released 4th October, 2015: https://www.padloper.pw/

On GitHub: https://github.com/plauclair/AutodetectLanguage PW's Modules repo: http://modules.processwire.com/modules/autodetect-language/ This ProcessWire 2.x module tries finds a best match between HTTP_ACCEPT_LANGUAGE and currently installed languages. If a match is found, the user will be redirected from the requested page to the same page in his preferred language. This match occurs only on the first page load, and will work with default caching on. If no match is found, the website will revert back to the "default" language. Installation info and more details on GitHub. Please submit any bug on the bug tracker, as it is easier to track different issues.

Very glad to hear you've made the switch - its really awesome to hear great feedback! Site looks very impressive (kongondo, you've started something here...) indeed. One thing to point out: under the "Stop trying to build your own website." block, there's a closing HTML comment tag. This is being shown because of the following: <!-- One --> <!--<section id="one" class="wrapper style1"> <div class="container"> <header class="major"> <h2>We design and develop websites that drive results.</h2> <p>Increase your customer base, build your business and remain competitive with our website design and development expertise.</p> </header> <!--<div class="slider"> <span class="nav-previous"></span> <div class="viewer"> <div class="reel"> </div> </div> <span class="nav-next"></span> </div> </div>--> </section>--> That last comment closer... Thanks for sharing your work

...and there is great migrator tool for up and running site to get some templates, fields and so on from one to another. https://processwire.com/talk/topic/8660-migrator/ have fun

This module displays tutorials according to the page where you are (based on intro.js). It also displays useful links. It is in process. Suggestions and reviews are welcome. To test the module go to modules or pagelist after install. Done: - PageList - Modules To Do: - Access -User, Roles, Permissions - Setup -Templates -Fields -Languages -PageEdit -Search Github

It's 2.5 only in the new release. You could use an older release which works with 2.4... (This one: https://github.com/NicoKnoll/ProcessTemplateEditor/tree/e7d27dbad6b38678137a023b26d8cca9f0d042c9)

I know there are mixed views on what should be core and what shouldn't, but I am thinking an option to install this during installation wouldn't be a terrible idea - you know, as long as the major pages are all covered with tutorials (And on that subject a few more things during install that could be optional too, but I digress). This is useful for everyone but definitely new PW users (admins) to get an idea of what things do.

Assuming I'm understanding the question: You can set a flag, for example on your page object. In the main template, don't render anything if the flag is set.

Looking forward to try it too. Will this support Language* fields? I am currently using Shopify (which we dislike) on the website of a non-profit I manage, and this would be amazing to have. We have roughly 50% French and 50% English people and there's no way to make this happen. One nice thing would be to be able to match output of emails for receipts to the user language (I suppose you store templates for those in text fields?).

Without looking too hard, I would suggest you upgrade the XAMPP (Current version is 5.6.3, so what you have is old and may not still be supported). The PHP minimum for PW is 5.3.8, however it wouldn't hurt to have a more recent version.

If it's log messages you want to catch, as long as they go consistently through the API (instead of creating separate FileLog objects, as we used to do it), there's no need to wait for anything; WireLog ___save method ($log->save()) is already hookable. Messages and errors are a different thing in ProcessWire, and catching those would probably happen using $notices. There are few things that aren't doable in ProcessWire as it is, and we've been adding new possibilities all the time. The value of aforementioned concepts and standards, as I see it, is framework interoperability (d'uh) much more than enabling something new in ProcessWire specifically Anyway, my first impression was that both PSR-3 and PSR-7 seem pretty solid, but we already have similar solutions in place, and whether those should be dumped in favour of PSR -- or altered to be more similar -- is a bigger question and depends on Ryan. PSR-2, on the other hand, has been discussed here a few times already, and currently it seems unlikely that we'd be adopting that for PW. The way Matthew's post explains middleware makes it sound like an interesting concept too, and certainly being able to switch components and even share them with different frameworks etc. is a neat idea, but other than that I can't really comment on this yet.

Am a bit familiar with the concept of MiddleWare in Node, so I don't have much to say in the context of PHP, however I do find it interesting as we can easily connect components to modify the response and request and simply trigger the next Middle-ware. But I will read more on that however it's the Logger interface am interested in, and would be really fun to use this in Processwire, where we can log and create Adapters e.g FirebugLog,SQLog,EMailLog something like Yii. However this means we will have to wait from 3.0 when processwire finally adopts Name-spacing and the PSR Autoloading.

@GuruMeditation if you are looking for the simplest possible solution, your best bet is to hide the fields you don't want displayed to users with CSS: .CommentFormCite, .CommentFormEmail { display: none; } If you want to go further than that, then you might be better off copying the comments modules to your /site/modules/ and modifying them as you see fit. The comments form is isolated to its own class, called CommentsForm, which you can extend or modify directly. In order to only display the comments form if the user is logged in, you would just wrap the renderForm() call around a conditional that checks if the user is logged in. // render comments list echo $page->comments->render(); // render comments form only if user is logged in if($user->isLoggedin()) echo $page->comments->renderForm();

Hi Lauren, I have thrown something together for you. It isn't well tested yet, but seems to be working fine. You can edit the StopWords.js file if you want to adjust the words that are removed. If there is general interest in this module, I might consider making it configurable. Let me know how it goes for you. PageNameRemoveStopwords.zip

Hi Lauren, You'll need to hook into ProcessPageAdd::buildForm and potentially ProcessPageEdit::buildForm if you also want to change the name when the title is changed during a later edit. You can get an idea of how to do this from my Page Rename Options module (https://github.com/adrianbj/PageRenameOptions/blob/master/PageRenameOptions.module#L65) You can see that I have added some JS to override the native functionality when it comes to naming the pages. You will be looking to add to/override the functionality in these files: https://github.com/ryancramerdesign/ProcessWire/blob/6cba9c7c34069325ee8bfc87e34e7f1b5005a18e/wire/modules/Inputfield/InputfieldPageName/InputfieldPageName.js https://github.com/ryancramerdesign/ProcessWire/blob/6cba9c7c34069325ee8bfc87e34e7f1b5005a18e/wire/modules/Inputfield/InputfieldPageTitle/InputfieldPageTitle.js Hope that helps to get you started. There is nothing wrong with messing with the page name - in fact it is possible to manually edit it by hand. The one thing that some don't agree on is whether it should ever be changed after it is originally created. I would personally rather the name matched the title, but others think it should never change due to SEO and broken links. I make use of the Page Path History module to deal with these - maybe not perfect, but typically the only time the titles will change is during development, so I am ok with it.

It's nice even if it is kind of the same I build. I think your solution is nice for guiding around clients and mine is better for new developers who are using pw for the first time (I explain more about how it works and helpful links, etc.). If you need help or want to reduce overlapping just contact me

Nobody? Ok, since the tags introduced to the image field is just a plain text field, there's no other way than to loop all pages that have images loop all images to grab all tags, parse them to array and merge them. This gets you there but doesn't scale well. (Would those tags be page relations it would make it very easy to output all tags. I'm more of a fan of using page fields for tagging, but there's no image field with page tags and I use different image system if there's a lot of images with tagging and galleries. My ImageManager is one of the tools to have a page as image and you can attach as many fields to the image template to get those things done.) I often thought about what would be the best ways, with words in text fields all over the site, to collect them and I think you have two possibilities. Raw SQL query, or the above loop all pages and make that a markup cached snippet, if the amount and time to generate the list takes long, that runs every other day or hour. Also have as many restrictions, for template or parent, as you can get to make the query a little more efficient. To show what would be the API way you already got a good start and intuition with 2 foreach. The following collects all tags and makes a unique array to create a link list. EDIT: You can use url segments or GET parameter for the links. Since PW urls doesn't allow special chars there's a workaround inside the code now. /** * collect all tags * ====================================== */ $alltags = array(); // container $use_urlsegments = false; // find all pages that have images with tags $parray = $pages->find("template=basic-page|gallery, images.tags!=''"); // loop pages found and collect tags from images foreach($parray as $p) { // find all images that have no empty tags, yeah you can // also use find on Pagefiles array! $images = $p->images->find("tags!=''"); // loop them and add tags to array foreach($images as $im) { $tags = $im->tags; // convert "," and "|" to space and create array using explode if(strpos($tags, ',') !== false) $tags = str_replace(',', ' ', $tags); if(strpos($tags, '|') !== false) $tags = str_replace('|', ' ', $tags); $tags = explode(' ', $tags); // convert tag value to a page name using beautifyer, ü => ue, ö => oe // since special chars are not allowed in PW urls foreach($tags as $tag) { $alltags[$sanitizer->pageName($tag, Sanitizer::translate)] = $tag; } } } /** * generate links with tags as urlsegment * ====================================== */ // make the array unique and create a tags nav from it // add tags to the url of the page to later read it and // render a list of pages echo "<ul>"; foreach(array_unique($alltags) as $key => $tag) { if($use_urlsegments) { echo "<li><a href='{$page->url}$key'>$tag</a></li>"; } else { echo "<li><a href='{$page->url}?tag=$tag'>$tag</a></li>"; } } echo "</ul>"; /** * find all pages with the supplied tag * ====================================== */ // enable url segments on the template if using url segments if($input->urlSegment1 || $input->get->tag){ if($input->urlSegment1) { $tagvalue = $input->urlSegment1; // get the original tag value text from the cached array $tagvalue = $alltags[$tagvalue]; } if($input->get->tag) { $tagvalue = $sanitizer->selectorValue($input->get->tag); } // find pages with images having the requested tag $pa = $pages->find("images.tags~='$tagvalue'"); if(count($pa)) { echo "<h2>Pages found</h2>"; echo "<ul>"; foreach($pa as $p) echo "<li><a href='$p->url'>$p->title</a></li>"; echo "</ul>"; } } What was the other question again? And of course also found in my ever growing gist archive https://gist.github.com/somatonic/5808897 I'm too lazy to brew a SQL that does the collecting part. But there's people more clever than me that can help.

Good ideas. I think this is definitely an option we'll want to have at some point soon. This is actually something the first iteration of ProcessWire (called Dictator) had back in 2004. If you removed 'guest' access from a page, then it would move its files directory to a non-web-accessible location and use a passthru script to deliver files so that they could only be accessed if the user was logged into an account with the appropriate access. The need hadn't come up since then, which is the only reason why it's not already in PW. But it's one of those things that's very important for private intranets and the like, so that you don't get confidential company PDFs floating around publicly or getting indexed by Google.