Leaderboard

Greetings, Just wanted to say thanks for this discussion. I'm still new to ProcessWire, and I had a similar question. The fact that such a discussion can take place here so naturally is one of the many reasons I find ProcessWire so good. What you are all discussing here is what one could call "good general practices" for deploying any site. However, in other CMSs, when you ask such a question, you get the general information then you have to go further and say, "OK, now how do I do this in [name] CMS?" With ProcessWire, what I really like is that the answer is simply the answer, and not "Here's how you need to do it in ProcessWire." This principle seems to extend all the way through ProcessWire -- from templates to JQuery, and more. It's one of the principles that I find very appealing about the system Thanks, Matthew

First of all, don't worry too much, you will normally find all the problems after launching Here are some of the things I try to do before launch : - Check the page titles and meta descriptions. Install the Google webmaster tools to get more useful advice on how to optimise the site for search engines https://www.google.c...ebmasters/tools - Create an xml site map and submit to Google (via Webmaster tools) and Bing (http://www.bing.com/toolbox/webmaster) - If this is the an update of an existing site, setup redirects for old pages to new pages - you can check what old links are currently indexed by Google and start with the top ones. The redirect plugin is great for managing this (http://modules.proce...cess-redirects/). - Check and update the 404 error page - Check that all your forms are working and being delivered to email recipients (not stuck in spam). - Change the admin url from /processwire/ to something more secure - Turn off any debug modes - Disable any test accounts and put an extra secure password on the master account. - Check what print layout looks like (or make print style sheet) - Browser testing - this is tough one to summarise - there are some sites that let you take screenshots, but the best way I have found is to have multiple virtual machines with IE7, IE8 and IE9 which can be used for more detailed testing and debugging. Then there is mobile device testing! - Check for broken links and correct redirects. http://validator.w3.org/checklink - Performance testing - you might want to check for any big performance issues. ySlow is a nice tool for checking and provides some good tips that might be useful for speeding up the site. Don't be too disheartened by the results, not even the big sites get top marks. http://developer.yahoo.com/yslow/ - Setup analytics to track usage - Google analytics - Setup monitoring so you know the site is up and running - I really like pingdom.com - https://www.pingdom.com/ - Backup the site files and database! Then I like to say a little website launch prayer… "dear internet gods, I know things will go wrong but please let the issues be small and easy to fix. amen."

Greetings gentle folk of processwire. I wanted to add an insight I had when porting the blog to an existing website. Everything went great with the addition of the blog fields and templates and works like a charm. Once the blog author is logged in he/she can go to the home page and a new contextual menu displays with options to edit a post, add new post, edit profile and such. That menu resides in the "markup" directory within the site templates directory with the name admin.php. The one and only issue I had is with the link to add new post as it's coded with the page id of the posts parent. 1006. When you add the blog to an existing site you can't guarantee the parent page will have the id 1006 though and in fact for me the correct id is 1080. I fixed the link and everything is groovy. I'm only posting this as a head's up to anyone else that might try adding the blog functionality to an existing site. The features are impressive and using it is far easier than building your own from scratch.

This module -- actually pair of modules -- keeps track of login attempts to your site, both successful and unsuccessful. The point of this is to give you better understanding about users' activity and environments they use and favor; browsers, browser features such as Flash and Javascript, devices, screen and window sizes. Based on my experience it could also prove out to be rather helpful when debugging error reports by users. Since most of this module was written during one weekend (short time for someone like me who way too often gets stuck trying to make meaningless little details "perfect") I'm very much aware that there are still quirks and even missing features I'd consider "very important." If anyone finds this module interesting enough to give it a try, any and all ideas, comments and problem reports would be very much appreciated! http://modules.proce...-login-history/ https://github.com/t...essLoginHistory How does it work? Process Login History itself is pretty simple and focuses on showing logged data. Probably only thing worth mentioning is that user agent strings are saved to database in their original format and converted here run-time into human readable values. Currently this is done with a private function that tries to identify most common platforms, device types and browsers, but I've planned to add support to either phpbrowscap and/or PHP's native get_browser(). Login tracking is achieved by hooking after Session::login and ProcessLogin::buildLoginForm, though latter is only used to add some extra fields to login form in order to collect slightly more information about user agent. Hooks are added by separate autoload module Process Login History Hooks to avoid loading unnecessary stuff all the time. I'm not sure if this naming convention is correct though.. it's not a process module but still very much related to one -- ideas, anyone? How do you use it? When installed this module adds new database table (process_login_history) for storing data and new page called Login History under Admin > Setup. What this page should look after couple of logins / login attempts is visible in the screenshot below. For more information and some ideas I've planned for later revisions, see README.md.

Well said Matthew, the end result of PW website is really up to you, not what the system comes up with. That being said, I have been thinking a lot about building our own "starting profile" (we kind of have one already, but that is not well build). Something more "out of the box" for our clients. That thinking also has some merits - especially if there are lots of sites and multiple people working (also on different areas, like customer support, developing, sales etc). More feature packed default site is easier to demo and sell, easier to maintain if there is lots of similar sites, easier to provide support (technical and helpdesk), easier to write instructions etc... What I am doing (hopefully this year) is to build site profile where would be the most common needs baked in already. What that would mean in our case (we build websites for Finnish associations) are: News section Events section Contact section Few different "basic-page" layouts Blog (maybe) FAQ-section (maybe) Tiny "intranet" section (maybe) Frontpage highlights Few editor roles Some useful modules already installed (redirects, adminbar, link helpers, admin helpers) Using more robust template approach Responsive by default I hope that it won't take too long that we start to see more and more community driven "starting profiles" like Ryan's Blog profile. There could be things like General CMS profile (kind of what I am doing - although not sure if it will be general enough to share it) and E-commerce site (kind of what here is coming) etc..

I tend to leave the PW config as-is, unless there are good reasons to change anything or add variables. ( I have a textformatter module that takes its config from config.php, for example.) SEO is always important , so I always install Pete's XML Sitemap module (http://modules.proce...up-sitemap-xml/) and, if it's a port of an existing site to PW then Antti's Redirect Module (http://modules.proce...cess-redirects/) saves loads of time. Then it's a matter of checking that all your <title> and meta description are all populated with appropriate info, and I also make sure that the html validates. A few small things add up to a significant advantage. Don't forget the Google Analytics code and to register your sitemap in Webmaster Tools. And, if you're in any doubt, a bit of user testing. A handful of users is enough to make a significant difference - http://www.useit.com...x/20000319.html.

Folks, I've been working on an experimental re-write of the link & image handling code in textile as I've become increasingly annoyed with the existing code. If you don't know what textile is then pass this over but if you do know what I'm talking about could you try out the code from the link-detection-rewrite branch and see if it improves or breaks anything for you? Thanks in advance!

ProcessWire modules are by nature meant to save time. There are 3 modules that I think can be big time savers on almost every project: The MarkupPagerNav module included with ProcessWire is hard to imagine being without. Yet, I was doing pagination without this for a long time before making it, and... things get done a lot quicker now. The MarkupSimpleNavigation module can be a big time saver when it comes to many common navigation scenarios. The FormBuilder module is a big time saver when it comes to creating forms. It's turned the most annoying and consuming part of development (for me at least) into one of the quickest and easiest. When it comes to front-end development, I'll admit that I've always preferred starting from scratch. But lately I've been enjoying what some of the CSS frameworks like Skeleton, Foundation and HTML Kickstart bring to the plate (and Twitter Bootstrap I'm guessing, but have not used it). With the appropriate project, these are huge time savers. The project I'm working on now (for a boarding school) needed to be responsive and very unique in design, and I found Skeleton to be the perfect balance there. It provides just enough to make things responsive, and very little else. That left little room for the design to be influenced by the framework (which was desirable in this case). If I didn't need responsive on a particular project, and could let the design benefit from some framework influence, I'd go straight to HTML Kickstart as the biggest time saving framework. Lastly, I'd say that using the Basic Profile as a starting point has always been a big time saver for me. Almost every site I build needs the core framework of fields and templates included with the basic profile. While all the markup and CSS ultimately get replaced, it saves a lot of time having these things there ready to implement.

I wanted to give you a little preview of a new module I've been working on recently: the Form Builder module. This module lets you create simple-to-complex forms and place them in your site without any need for development. In this video we show how we can create, publish and test a simple contact form in less than 5 minutes. Then we take a quick look at a more complex form (already produced). I recommend viewing the full screen + HD 720p version so that you can see it more clearly than in this small forum embed. (note: there's no sound, so no need to adjust your volume) More about the Form Builder The Form Builder has many options for the developer to customize output and create their own themes, markup, etc. But the goal here was to build something that could enable you (or your client) to publish a form in less than 5 minutes, so that's the focus of this video. This tool is literally easy enough for your clients to create and manage their own forms. Or from a developers perspective, it takes something that used to consume hours and makes it happen in minutes. Form results save in the database and optionally can be CC'd to you by email. Result entries and be viewed, filtered by date, and even edited in the admin. You can export results to a spreadsheet as well. I'm working on the ability to export to pages, though that isn't quite ready yet. How the Form Builder will be licensed This module will be individually licensed on a per-site basis for a small license fee. It will also be available for free personal use to established forum members. Basically, I want to see if I can substitute some of my client work to focus on ProcessWire instead. And in order to do that, I need to have an income (I have a family to support). So I thought that building a special tool like this would be a way to make a go of it. A lot of you have asked to make donations to the ProcessWire project, and while we still won't be able to take donations, you will be able to support the ProcessWire project by purchasing and using the Form Builder in your own client projects. So a lot of motivation for this module came from wanting to provide something really special for all that had wanted to support ProcessWire. After a few months of work, I'm pretty happy with how this module has turned out -- it's already saved me tons of time in my client projects. So I'm thinking and hoping you guys will really like it too. I look forward to your feedback.

Thanks to Processwire, I've gotten the confidence to start charging people for my web development and have recently started a web dev business. Although I'm not too artistic, the flexibility of PW allows me to accomodate the design of any artist I am working with and the API gives me to power to do the fun backend stuff. Anyways, before I deploy some sites for production, I wanted to ask the more experienced developers out there what kind of steps they take at the end of a project to make their sites 'production ready'. For example, do you guys combine all your js and css files? do you change any Processwire configurations? Hearing any tips from you all would be of great help to me. Thanks in advance

Ryan, I'm happy to take over maintenance of those two modules once the next version of textile is released. Lets stick with the status quo until then.

I didn't realize you were a VIM user too. That makes at least two of us here. I need to get setup with this debugger plugin too.

Thanks Ryan, just bought the module to try it out as I couldn't wait any longer. I just can't believe how much faster (and better-coded) it is than writing hundreds of lines of code myself! One concern/query: What effect does embedding them as iframes have on them? I can see they are created on their own pages (which users probably won't guess the url for), I just wasn't sure if there were any downsides to this long-term? Also is this the appropriate place to post questions about the form builder? Thanks Ryan and great work! EDIT: I'm a dummy, just noticed this page

Maybe looping over all items an then call the remove method for each item: $images = $page->image; foreach ($images as $img) { $page->image->remove($img); }

Turns out it was on a shared Windows server This link helped me get it running http://processwire.com/talk/topic/268-processwire-on-windows72008-server-with-iis-webserver/ Thanks to Nikola!

Replace the content of your classTextile.php by the code from this link https://raw.github.c...lassTextile.php In PW that class is inside /site/modules/TextformatterTextile/

Hey Antti, I also agree with you about the boxy feel. I have just been playing with the repeater element and tried to reduce the boxyness and make it similar to Renos style. Here is a screenshot This is not fully tested and will probably break other stuff, but here is the css I used so far .Inputfields > .InputfieldRepeater > .ui-widget-content { padding: 0; border:none; } .Inputfields > .InputfieldRepeater > .ui-widget-content .Inputfields > .Inputfield > .ui-widget-content { padding: 5px; border-color: #e6e6e6; } /*add a dropshadow to the repeater inputfields */ .Inputfields > .InputfieldRepeater > .ui-widget-content .Inputfields > .Inputfield > .ui-widget-content .Inputfield { -webkit-box-shadow: 1px 4px 5px -3px rgba(0, 0, 0, .1); box-shadow: 1px 4px 5px -3px rgba(0, 0, 0, .1); } .ui-widget-content { border-color: #e6e6e6; } .Inputfields .ui-widget-header { border-bottom:none; border-color: #e6e6e6; background: #ffffff; } .InputfieldStateCollapsed .ui-widget-header { border: 1px solid #e6e6e6; } /*this is the repeater element handle, changing it to a solid color */ .ui-state-default, .ui-widget-content .ui-state-default, .ui-widget-header .ui-state-default { border: none; background: #b3b3b3; }

I tested it in a local copy of this website http://www.max-cafe-bar.de/essen/, and everything seems to be working fine. All the menu tables in http://www.max-cafe-bar.de/essen/ and http://www.max-cafe-bar.de/trinken/ are built in textile.

Ryan is right, you build the html list with the name but that information will be exposed to the user before the post submission. Therefore it can be changed, and should be considered user input.

Great work Teppo, will test this soon. Based on the login times on the screenshot, this required some late night coding also BTW: Your link to modules directory is for edit view: http://modules.processwire.com/edit/process-login-history

Antti, Here is how I currently have them working (see additional dates is screenshot). I haven't given that scenario a lot of thought yet.

I sometimes use CSV import module to create lots of pages from one list or names or titles. It's very handy and even can import images or files from an old website.

I agree with SiNNuT on this one, though the likes of Symfony aren't a social platform out of the box either. I think that unless you use a pre-packaged setup like those mentioned (buddypress, etc.) you will be custom coding many of the features. And ProcessWire is a good place to do it. But you'd probably want to start from the vantage of a smaller project with ProcessWire to evaluate and determine if it's the right framework for your needs.

Thanks Ryan, I managed to sort this out by sticking with the repeater option, but instead of using a repeater as a singular method for date entry, I used it for "additional dates". That way, the majority of events are entered with a typical start/end date, but events with more complicated schedules can use the repeater. I set the ready fields to 2, that seems like a good place to start. I think this will be less confusing to the people entering events — at least I hope. See attached. (note: tweaked the admin via FieldSet to create 2 columns for calendar entry, I love how flexible PW is.)

Wow, this is absolutely incredible! One thing though (only minor and I may be in the minority): I have never really liked per-site licenses for things. I have no issue with people using them, I just prefer not to purchase them myself where there are other options. Would you consider a per developer license (for more than the per-site license obviously)? My biggest reason for this is that I make a lot of small sites for family friends etc on the side and whilst this functionality would be great I don't want to be thinking about purchasing components each and every time I make a site for someone like that. Of course this is far from a demand. I don't expect something for nothing nor do I think that my reasoning is the 'only right way'. All I am saying is that you will have a guaranteed customer here if you do a one-time-purchase type option Either way, it is really great to see some more advanced functionality being done with the ProcessWire functionality. I can think of at least two sites that I can likely make use of this module, regardless of the license setup you decide on.

Man, this HUGE in the history of big...

Hooray for our fearless leader!

I see what you mean. If you are okay with setting it in your /site/config.php file, I can make it happen. This doesn't involve adding any real overhead or complexity to the system, because these types of config options are optional.