Leaderboard

Hi, it would be lovely if this forum would have a "Mark as solved" button so user could see which questions are still unsolved more easily. / Nico

Another one finally online: http://pwpromotion.de A site for a recruitment agency, specialized in the beauty sector. No fancy PW features here although the application form built with the incredible Form Builder is quite complex (choose one "Fachrichtung" to open even more fields) ;-)

hi all, online since today, a new site for a big doctor's practice specialized in prenatal diagnosis: praenatalmedizin-koeln.de the site replaces an old outdated site and i put special effort to maintain the very good serp ranking of the old site. that's why there is an exhaustive faq page, an additional glossary page, and the tagline on top of each page. the calendar of recommended examinations (see bottom of page /untersuchungen) was done with the page field type. the editor may allocate any page from the /untersuchungen section to the calendar with the help of page field type. once allocated, the page qualifies for the calendar if there is an entry in the respective field SSW (saying for which week the examination is recommended). if this field is filled, the information is automatically added to the calendar and sorted. if no "ssw" is given, the page doesn't show up in the table. your comments are welcome. please let me know if you find any bugs. modules: redirects, email obfuscator, after save actions

one important key to professionalism is to take professional rates. 15/20 euros is not enough to make a living from. this is, why you attract clients who doesn't take you for serious. they simply doesn't consider you as an professional. however, if you feel you are not market ready do a regular job and in you off-time work on a really good project you love to work on. do this for a person/client you like and who doesn't set you under pressure. use it for learning and improvement. once ready, you have something to showcase. than go to the market and tell prospects: this is what i can and i'll do it for you for a professional rate.

That solution doesn't scale, if client adds new page each day... I would add new image field called background image, set it to have only one image and then add this to template file: <style> body { background: url(<?= $page->background_image->url ?>; } </style> (written in mobile)

You mean like this? I just enabled it in this forum for a test, as well as Getting Started, General Support and Modules & Plugins. I can see it needs some styling though so it stands out a bit more.

i don't know very much about india (you are based there, right?) and the market there. but what i see from your portfolio website you are a professional. so my advise would be to take at a minimum the average rate that good professionals get in india and to stand it if clients refuse to pay this rate. of course, this requires a second income as long as your client base isn't strong enough. if you have no other choice than accept lower rates for low-level jobs but never advertise that you've worked on this projects and never tell everybody. they simply doesn't exist. if everything you do in public is focused on professional rates you WILL get better clients.

to pw or not to wp - ha ha

I already edited the title. But found the 1.9 funny so have kept it. Heh

@Pete: any chance that solved-button could be added to "New content" view also? Just noticed that it doesn't show up there -- which would be pretty sweet, considering that it's pretty much the only view some of us (well, at least me..) ever use

Beyond being a CMF/CMS, the goal of ProcessWire has also been to provide utility to PHP like jQuery does to Javascript. That means we accept PHP best practices as our best practices, rather than inventing proprietary, usually more complex and short lived alternates that do the same thing. It also means using very simple, yet tried and true PHP like functions and includes for code reuse rather than snippets, blocks, chunkers, snaggers, widgets, tagalongs, bangers or whatever concepts are being pushed out there. ProcessWire provides tons of structure when you want it to, and gets out of your way when you want it to as well. For me it means template files that rarely have much code in them (occasionally none), unless the output need is different from the rest of the site. Most of the site's markup gets generated either from a "main" output file, or from shared render functions. As a result, most template files tend to have limited or no markup and look like the example at the bottom of this post. It also means that I don't usually have more than 2-3 other PHP files, beyond the template files. See the template file structure section of this post for details on how I structure my template files–I've found this method to work best for me through several sites. The delegate approach and some of the others I've seen don't suit my needs as well, but seem to work very well for others. The Blog profile uses an MVC style approach that may appeal to those looking for lots of predefined structure, though I still prefer approaches that involve fewer files. For small stuff, the approach taken in the default profile (included with ProcessWire) is about as simple as it gets, even if it's not as elegant. But when it suits the need, I don't see any reason to shy away from it. Regardless of how you structure your site, the important thing is to aim for DRY (don't repeater yourself). home.php $body = renderSlideshow($page->features) . $page->body; $side = renderNews($pages->find("template=news, sort=-created, limit=5")); The example above uses the /site/config.php 'prependTemplateFile' and 'appendTemplateFile' options to include an _init.php (prepend) file that initializes variables like $body and $side with defaults, and a _main.php (append) file that outputs them in the predefined places within the context of an entire HTML file. The template files get executed in between those two and modify $body and $side as needed specific to the data and needs of the template and page.

I needed a field that would allow me to select one or more templates, very much like the Page Select. So I created a module that does just that! I based it off of Ryan's FieldtypeModules because the functionality is quite similar. You can also define which templates are selectable by the asmselect field. Hope this helps someone that wants to do the same thing! FieldtypeTemplates.module

Did some digging about css frameworks in google. Found some links that might be usefull to read. 2 good articles about css frameworks http://coding.smashingmagazine.com/2007/09/21/css-frameworks-css-reset-design-from-scratch/ http://www.gridsystemgenerator.com/ do it yourself css layout http://designshack.net/articles/css/rolling-your-own-grid-layouts-on-the-fly-without-a-framework/ interesting css frameworks http://www.bluetrip.org/ http://www.devarticles.com/c/a/Web-Style-Sheets/Introducing-the-BlueTrip-CSS-Framework/ http://daneden.me/toast/ https://github.com/coyr/nivelstyle https://code.google.com/p/logicss/ http://toddmotto.com/introducing-superbox-the-reimagined-lightbox-gallery/

You've been using MODX but now you've found ProcessWire. It’s totally amazed you and you can’t wait to get started. But…you are wondering where everything is. If this is you, read on… This guide is primarily aimed at those who are coming in from MODX and wish to know how to accomplish “MODX things” the “ProcessWire (PW) way”. This is not meant to be a full blown PW tutorial. It will focus on some key MODX concepts/tasks and how to accomplish those in PW. It will cover, whenever possible, both versions of MODX - Evolution and Revolution. The guide assumes that you’ve at least logged into a PW site and/or viewed a demo. The Table of Contents mostly reflects MODX terminology. Table of Contents 1. Manager 2. File System 3. Resources 4. Templates 5. Template Variables (TVs) 6. Template Files 7. Snippets 8. Modules 9. Plugins 10. Chunks 11. Miscellaneous 12. Examples - the PW way… a. Template Variables b. Snippets c. Modules d. Plugins e. Chunks 1. Manager In PW, the “manager” is referred to as the “Admin”. The default location of the Admin is www.yoursite.com/processwire. As of PW 2.3, you can rename the Admin to anything you wish during install. Just be careful to remember the name you use or you will be locked out! (If that happens, there are ways to get around it though). Logging into Admin, you will notice a tree just like in MODX. The Admin runs on jQuery UI and as you’ve seen, it is insanely fast! Don’t be fooled by its simple facade. PW is a really powerful CMS, highly extensible and very easy to use. Customising the PW admin is very easy. There are a number of custom themes available. It is also trivial to make yours. Custom Admin themes go into the folder site/templates-admin/. You can have only one theme at a time. On a related matter, if you wish to create a custom Admin page, it is easy to do so. See this thread for more info. 2. File System After installing PW, you will see two main folders; “site” and “wire” in your file system. Site is where all things related to your site reside. This is your playground and will survive an upgrade. Wire houses the Core. You will never have to go into that folder. 3. Resources In MODX, Resources can be many things (documents, etc.). There is no such term in PW. However, the most important “resources” you need to know about in PW are page and pages. Pages are a very powerful concept in PW. Page can refer to your website’s frontend pages, i.e. what can be viewable by your website users. I say can be for a reason. There are many uses for Pages in PW. This can be confusing to newbies but once you get the concept, you will appreciate the power of the system. Just because something is a Page does not mean it has to be viewable. It can have other uses such as a container that holds data for use by other Pages - in this case the Pages do not have to be displayed on the frontend. In fact, everything you see on the PW tree is a Page. That’s right; even the Admin and its components (Users, Roles, etc.) are all Pages! Still confused by Pages? Have a read here. Pages reside in the PW tree - you may have noticed . You can drag and drop pages to move them around. If drag and drop doesn’t work you probably have MySQL 5.0.5.1 installed. Upgrade your MySQL and you are sorted. The root of your site is the uppermost Page in the tree. In the default PW install this is called Home. You can change the name to something else. The default PW install comes with a number of Pages pre-installed. Try editing a Page. All those Fields you see on that Page when under the “CONTENT” tab? They are not default Fields. They are all Custom Fields! Yes, not even the Title! The only required Field for a Page is “name”. You find this under the “SETTINGS” tab on the page edit screen. More about Fields below… Other related stuff: Menuindex: As an aside, if outputting something like a menu, unless you state otherwise, it will reflect the tree hierarchy. Show in Menu: This functionality is covered by the Page status, whether hidden or not. Hidden pages do not get output on menus (more about menus later) unless explicitly stated so using PW API selectors (see below). Menu Title: No such term in PW. You can name your menu items what you wish to name them. Very important: All Pages must be assigned a Template. 4. Templates In PW, Templates mean something slightly different compared to MODX and many other CMS. MODX describes templates as: That is not entirely true of PW Templates. In PW, the term Template is used in the sense of the English definition of the term: PW Templates serve as a pattern for the foundation of your Pages. By foundation, I do not mean the HTML or CSS. Rather, the Template servers as blueprint for your Pages. What is available to the Template is available to the Page that uses it. Templates establish a pattern for the Pages by the inclusion of Fields to the Template. A Template can have as many or as few Fields as you wish. You can create as many or as few Templates as you wish. You can easily change the Template a Page uses when editing the Page. See under SETTINGS. Note that if you have Fields on that Page that are not in the Template you are switching to, those Page Fields will be lost! PW will warn you about this when switching Templates though. OK, so how do you show “Resources to the world”? That will be the work of Template Files which we’ll look at in section 6. 5. Template Variables A powerful feature of MODX is Template Variables (TVs). If you loved MODX TVs you will absolutely adore the PW equivalent. In PW, TVs are known as Fields. You can define your own Custom Fields. In fact, you will need to create your own in most cases. This is because PW does not have any required Field except for “name”. It is perfectly reasonable to have a Page with only the name Field! Many people do add at least a Title Field for such Pages. In the default PW install, the reason you see the Title Field in all Templates is because it has been set as a “Global” Field under the ADVANCED settings of the Field (edit the Field to see this setting). There are many types of Fields to hold all sorts of data - images, texts, urls, passwords, reference to Pages, etc. You can call your Fields anything you wish. You can call the Field for your main content “body”, or “stuff”, or “content” or whatever you wish as long as you follow the naming convention, i.e. “[a-z], numbers [0-9], or underscores (no dashes or spaces)”. Fields are reusable across different Templates. The order in which they appear on your Page follows the order in which they are arranged on your Template. However, it is important to note that: The order in which Fields appear on your page and/or the inclusion of a Field on your Page does not mean that: The Field will be output on the Frontend. The inclusion of a Field on a Page does not automatically mean it will be output; PW does not make that decision for you. It only makes the Field available to you to use as you require. You can output all or none or few of the Fields on your Page. The order in which Fields appear on a Page does not mean the same order will be reflected when you output the Page. You make that decision. Also note that you are able to arrange Fields side-by-side on your Page (via settings on the Page’s Template) to mimic your site’s layout or for other visual/ease-of-use purposes as you edit the Page in the Admin. You can also give each Field a label and a description. These will appear above each Field when editing a Page. In most cases, the content of Fields will be saved directly to the database. In the case of file related Fields, the path to the file will be stored in the database. There are no direct equivalents of MODX TVs “@Bindings” (data sources). These are inherently built into the different types of Fields. Note that you cannot run PHP code within Fields (so no @Eval). This is by design. Fields are a very powerful and much loved concept in PW. Just Google "custom fields cms" and you’ll see what comes up tops. 6. Template Files So far, we've seen that you create Fields, add them to a Template you've created and edit a Page using that Template to input your content into that Page’s Fields. So far so good but how do you output the content to the world? You do this via Template Files. Template Files live in /site/templates/. You have to create your own Template Files. In MODX, a Template will have both system fields, e.g. body, title, etc. and custom fields (TVs). Rendering a Template is achieved by adding MODX tags to your Template. In PW, in order for the content of your Page to be seen by the world, its Template must have a Template File (or there must be some other Template File associated with a different Template that is dynamically pulling and outputting elsewhere the content of a Page whose Template does not have a Template File). This does not mean that all content within a Page will be automatically output by the Template File. No; in the Template File you can choose to render all or some Fields present in the Pages using that Template or none at all! You tell the Template about the associated Template File when you create/edit the Template. PW assumes that there is a Template File with the same name as the Template in /site/templates/ and will tell you if it does not find one. However, you have two other choices. You can either enter an alternative name for your Template File or tell PW you do not wish to have a Template File for that Template. This means that a Template does not require a Template File. Obviously, in such a case, you will not be able to directly output the content of the Pages using that Template. In some cases, that is exactly what you want . As you get to know more about the system, you will find out how powerful and flexible the PW Template system can be. For instance, you can use your Template as a controller. That’s beyond this guide but feel free to search the forums for more info. Template Files are typically PHP files with logic to dynamically output your content. In most cases, Template Files are HTML with PHP tags inserted to output your content. The PHP in the Template File will in most cases be PW API. Hence, you will see things like $page and $pages in Template Files. The former always refers to the current Page and the latter to any other Pages in the system. These are very powerful variables in PW and give you access to ALL information about ALL pages including their Fields and whether those are empty or not, etc. See below for more info about these variables and have a look the docs too. Note that Templates do not care about what’s in your Template Files. In fact, they won’t even check. All they want is for you to tell them if and how you wish your Pages' contents to be rendered. Your Template Files can even contain pure HTML (although that won’t be dynamic!)! Your Template Files can have references to other things related (or not related!) to the Page using that Template File. For instance, within your Template File, you can pull in the 10 latest “posts” from your Blog or the Children Pages of that Page. There are just too many possibilities to list them all here. Don’t let the PHP in Template Files scare you if you are no coder. I am no coder but I am able to use PW. You will only need to know at least some very basic PHP to use PW. The most important are: echo; foreach; and if… Anything else is a bonus in most cases. In addition, you will need to know how to use the two most important PW variables - $page and $pages. With these two, most of what you would have done in vanilla PHP is covered. They are easy to use and to understand and very much follow the jQuery concept. Check out the docs to learn more. 7. Snippets In MODX, Snippets are the method by which MODX allows you to run dynamic PHP code in any of your pages. In PW, the term Snippets does not exist. What!?! Not to worry; in PW MODX-like Snippet functionality can be achieved in two ways: Template Files: Most PW Template Files are essentially dynamic PHP code. That’s Snippets for you right there. PW Modules: PW Modules do what MODX Snippets do and more (see below). It’s just an issue of terminology. For instance, the popular MODX Snippet WayFinder has a Module counterpart in PW. This is the Module Markup Simple Navigation. However, you do not need to use the Module to create a menu in PW. You can do the same thing using PHP in your Template File. See the default PW install for a simple example. Check out section 12 of this guide for example “popular-MODX-Snippets-to-PW-how-tos”. 8. Modules MODX Evolution defines Modules as “a program that can only be executed from within the manager.” There are PW Modules that fit this definition, for instance, the Module Batcher which is equivalent to the MODX Revolution add-on Batcher. However, there are other PW Modules that are executed in the frontend, e.g. Markup Simple Navigation previously mentioned. In fact, in PW, a Module is PHP that extends the functionality of PW. Modules contain PHP classes that adhere to PW’s Module interface. 9. Plugins In MODX Plugins are PHP code that are set to execute during certain system events. In PW, although the term Plugin does not exist (except maybe in reference to Modules), MODX Plugin functionality is easily doable in PW. This is achieved via Hooks. There is one difference though. In MODX, Plugins are standalone code you can download and install. You cannot download and install PW Hooks. Instead, PW contains many methods that you may hook into in order to modify the behaviour of the method. In other words, PW offers the ability to hook into its processes/events and manipulate them before or after the event or even replace them, etc. Hooks are usually invoked inside Modules. However, Hooks may be attached from anywhere that you use PW's API, for instance in Template Files. The average PW user will not need to use Hooks. For more info about Hooks check the documentation. 10. Chunks MODX defines Chunks as “bits of static text which you can reuse across your site”. There is no equivalent term in PW. You can, however, easily create Chunks in PW. You can create Chunks as a Page that contains various Fields each of which can act as a Chunk. This means you can have Chunks of all sorts of data. You can then set the Page you create to hold your Chunks as hidden (not available to searches). The Page can also be assigned a Template without a Template File to further limit frontend access. It can also be created as a child/grandchild of the page Admin. That will limit access by User (e.g. login required to view it in Admin). Accessing the Fields of that Page as your Chunks using PW API is quite trivial really. Since you can use labels and descriptions to further define each of your Pages’ Fields, this makes it quite easy to describe what each Chunk is for and/or give instructions on how to use the Chunks. See this example for more info. You can also simply use text files to pull into your content as Chunks. Personally I prefer using Pages as Chunks when I need to. In MODX, it is usual for many Snippets to use Chunks (HTML + placeholders) to structure their output (i.e. tpl Chunks). You do not need to do this in PW. Code output can be wrapped in HTML right within the Template File. The important thing to remember is that any Field in any PW Page is available to any other Page and any Template File. Cross-referencing Fields and Pages is child’s play. Seriously; it is that easy. 11. Miscellaneous Tag Syntax: PW does not use a templating language (tagging syntax) like MODX does. See this article why this decision was taken. I agree 100% with the approach and have come to realise its many benefits over using a templating language. However, there are two Modules that allow you to use template language tags in PW. I have never used them so cannot comment further. They are here and here. Settings Page: PW has no settings page like MODX. Many settings are set in the /site/config.php. Other MODX settings equivalents are interspersed in various places including caching content on a Template by Template basis and in Modules. You can also store custom settings needed for your site in the /site/config.php. You can even use Pages to store your settings as mentioned in section 10 (Chunks). Modularity: PW is a very modular system. The whole of PW is made up of Modules (Core Modules) that accomplish different tasks. 12. Examples - the PW way… In this section I will show you equivalent MODX versus PW add-ons as well as how to accomplish various task using PW “Snippets” equivalent. a. Template Variables As previously mentioned, MODX TVs are PW Fields (although PW Fields are more versatile). Outputting the contents of your Fields is very simple. echo $page->name_of_your_field; This gives you the contents of the Field in the current page. Works slightly different for image fields though. For other pages echo: One page $pages->get(ID or PATH or NAME, etc.)->name_of_your_field; //note replace ID with ID of the Page you want, etc. Many pages $pages->find("selectors"); //this will return an array. You can then go through the array using foreach as shown in the examples below to output the field(s) contents MODX - output main content of Page //MODX Evolution[*content*] //MODX Revolution[[*content]] ProcessWire - output main content of Page //ProcessWire echo $page->content;//note; this assumes you have a Field called content in the Template of the current page. In ProcessWire you can find Fields of other pages like so $fruits = $pages->find("template=yumyum, limit=10"); foreach($fruits as $fruit) { echo "<li><a href='{$fruit->url}'>{$fruit->title}</a></li>"; } //find 10 Pages that use the Template yumyum and echo their url and titles in a list. From these examples, you can see the elegance and flexibility of TVs done the PW way. Since there is separation between a Template and a Template File, you can conditionally echo out the contents of Fields found in Pages. b. Snippets Common MODX Snippets and PW equivalent Modules 1. WayFinder: Markup Simple Navigation or code in Template File (see head.inc in default PW installation for a simple menu). 2. Ditto (Evolution) and getResources (Revolution): Functionality inbuilt in PW. Use $page and $pages variables + selectors to find anything, anywhere. 3. Jot (Evolution) and Quip (Revolution): Comments Module is part of the PW Core. It is not enabled by default. You will have to enable it in the Admin. See also the related Comments Manager Module. 4. eForm (Evolution) and FormIt and FormItBuilder (Revolution): There are various Form parser codes in the Forums. There is also a commercial Form Builder Module. It’s not expensive, is developed by PW’s lead developer and proceeds support the PW project. 5. MaxiGallery (Evolution) and Gallery (Revolution): Presently, there is no equivalent. However, it is quite easy to build a photo album. See this tutorial in the wiki. There is also an Images Manager Module (still in alpha though). 6. AjaxSearch: Ajax Page Search Module. 7. Breadcrumbs: Quite easy to accomplish using PW API. See default PW install for an example. 8. FirstChildRedirect: Very easy to do using PW API like this: $session->redirect($page->children->first()->url); in a Template File. 9. getField (Evolution) and getResourceField (Revolution): Inbuilt in PW $page and $pages variables as shown above. 10. GetParent: Inbuilt in PW $page and $pages variables. E.g. $page->parent. 11. getPage: PW has inbuilt pagination as part of the Core (Pagination Markup Module). See this article for a quick tutorial. 12. UltimateParent: Inbuilt in PW API as rootParent. 13. if (Revolution): Use vanilla PHP with PW variable and selectors in Template Files. 14. VersionX (Revolution): Versioning for text-based fields is coming in PW 2.4 (release date summer 2013). Support for maintaining separate draft and live versions coming in PW 2.5 (Winter 2013/2014). Currently, there is also the Module Version Control for Text Fields. 15. getRelated (Revolution): No out-of-the-box Module for this. Has been previously accomplished using PW API in various ways. Have a look in the forums. 16. importX (Revolution): Import Pages CSV Module. 17. phpThumbOf: Thumbnail functionality is inbuilt in PW. There is also the Module Thumbnails that further extends this functionality. 18. getValue and getValues (Revolution): Inbuilt in PW. You can get the value of any Page using PW API - $page and $pages. 19. getFeed (Revolution): RSS Feed Loader Module. 20. MIGX (Revolution): Repeater Module which is part of the PW Core. It is not installed by default. You will need to do that yourself. For more info see this tutorial. 21. Articles (Revolution): See the Blog Profile Module. 22. NewsPublisher (Revolution): See below under Plugins. Examples MODX Ditto [!Ditto? &parents=`5`&extenders=`summary` &tpl=`tplBlog` &orderBy=`createdon ASC`&display=`6` &truncText=`Continue Reading This Article` !] PW equivalent $items = $pages->get(5)->children("sort=date,limit=6"); foreach ($items as $item) { echo $item->title; echo $item->summary;//etc. } //this assumes you have a Field called summary on that Page The first line in the above gives you all information about the 6 child Pages of the Page with ID #5. It returns an array. In other words, a basket of various documents containing all the info about those documents. Next, you traverse the array using foreach. In layman terms, you rummage through the basket picking goodies! In order to wrap HTML around the code output, we do it like this instead (there’s other ways to do it as well!) echo "<ul class='articles'>"; foreach($pages->get(5)->children("sort=date,limit=6") as $item) { echo "<li><p><a href='{$item->url}'>{$item->title}</a><br /> <span class='summary'>{$item->summary}</span></p></li>"; } echo "</ul>"; In this example, we have asked PW to grab the child Pages directly within the foreach rather than creating a variable $items first. MODX getResources // Output a list of child Resources of the current Resource, using the 'myRowTpl' chunk: [[!getResources? &parents=`[[*id]]` &tpl=`myRowTpl`]] PW equivalent echo "<ul>"; foreach ($page->children as $child) { echo "<li><a href='{$child->url}'>{$child->title}</a></li>"; } echo "</ul>"; //You might want to limit the number of child Pages you are getting if they are many! MODX getResources // Output the top 5 latest published Resources beneath the Resource with ID '5', with tpl 'blogPost': [[!getResources? &parents=`5` &limit=`5` &tpl=`blogPost` &includeContent=`1`]] PW equivalent echo "<h3>Latest Posts</h3>"; $posts = $pages->get(5)->children("limit=5"); foreach ($posts as $post) { echo $post->body; } c. Modules 1. Batcher and Docmanager (Revolution): Batcher Module (covers most equivalent functions). 2. DocFinder (Evolution): Inbuilt in PW default install. d. Plugins 1. QuickManager (Evolution): Several Modules can do this, i.e., Fredi, Page Frontend Edit and Inline Editor Modules. 2. ManagerManager (Evolution): Same functionality can be achieved using Templates, Access Control and the Modules Page Edit Field Permission, Page Edit Per User and Page Edit Per Role. e. Chunks See this example. Btw, the PW Cheat Sheet is you best friend... Hope this has been helpful! /kongondo

A little something I've been working on for a while now. I decided I wanted to created a theme that felt like a natural fit for ProcessWire; light, clean, efficient and straight forward. So I took to using what I had learned from the themes I had created in the past, took some vigorous inspiration from the new website and got to work. And this is what I've created... so far of course Unify Admin Theme DOWNLOAD ***** Updated for compatibility with current dev 2.3.5. ***** Login Page --------------------------------- PageList ---------------------------------------- PageEdit ------------------------------------- Image Insert Dialog ----------------------------- Subnav Dropdown ------------------------------------ Features subnav dropdown menu gravatar user profile images CollagePlus image insert layout customized CKeditor theme (minor tweaks, but it really fits in nicer) Enjoy! I will continue to tweak and perfect this theme so be sure to let me know if you have any issues or suggestions. I would consider this a beta for now as I've done little to no cross browser testing. Thanks!

Try $child->logo instead of $pages->logo

Glad you got it sorted...

can't you offer to work from spain over the internet and keep your day time job at the car rent? at least for a testing period.

Well I hope you get that job, wish you good luck.

@Macrura Thanks a lot, those look very useful. Mainly my focus is on correctly estimating the time & efforts required to do a task, which I almost always fail to do, it results in non-profitable projects. Time tracking seems very helpful. @pwired Some part of your answer wasn't visible untill I quoted it. Nevermind, I really like your answer for the honest experience you've shared with us. I agree to most of your points and your suggestions are what every beginner in this field must need to know. Get paid in advance, this lesson I learnt the hard way. I've delivered websites and haven't got paid at all. Even I've put a big bold bright text on the client's website saying the site is down due to due payments, but still haven't got paid. Many of my clients, like the one I'm dealing with now, haven't paid a dime & have been demanding to deliver site first and get paid later as it's their "Company Rule" to pay only after the work is done. Since I work in a highly competitive and extremely cheap market, and being a fresher in the field, for the fear of not missing out a good client, I've been working for them. All this affects productivity when delayed payments make it hard for you to do what you love, designing sites or developing new things. It's a big problem I'm facing now when paying bills on time is a challenge due to indefinitely delayed payments. p.s: When I say extremely cheap, I mean people make Wordpress website for under $90/website. Of course they use the same theme for each site with colors changed a bit and also there's no way client can do modifications, SEO/UX/Code Quality do not exist but who cares? People here judge things on price basis not the quality.

i would die and get nothing done without my awesome timetracking software mite by berlin based company yolk: http://mite.yo.lk/en/ i can't recommend enough these guys who made one of the best tools on the internet and are extremely responsive to their users. mite is worth every penny you spend on it. if it comes to getting-things-done tools i'm finally back to outlook after producteev, wunderlist and remember the milk which all didn't fill the bill for me. outlook does it neither but at the end it integrates best with email. last but not least i use for billing and accounting monkey office which is very specific to germany and austria unfortunately. i'm afraid it won't help you in the uk or us or india. but for germany/austria it's very good. that's pretty much my setup. the key to it all is to-do-lists and mite.

worked perfectly. I'll share the final result when i get it wrapped up.

I like it - very much! Great type contrast, great use of white space beneath the headline. And I really like the way you placed the image and the text part! Wow! I usually hate these "scrolling text on the left, fixed image in the background" stuff - but this one really works well!

Very good topic Vineet Sawant !! Not only discuss with each other coding pw websites but also about marketing websites. My experience is that many website builders consider this a private part of their work and so discussions and answers about this topic stay for the most part private. Of course I can understand that, it would be like asking someone how much money he or she is earning every month, for how many hours and what kind of work and many people would like to keep that private. But it would help a lot of newbies if they could learn something from the pro's about making, negotiating, planning, selling and getting payed for websites. I for example made only 8 or 9 websites that I actually sold. None of them was done with pw that came later on. I charged between 300 and 800 euros because they were simple websites with still a lot of work and I got payed when the website was finished and delivered. Sometimes I got not payed as promised or not payed at all and had to shut down the website. Then on the first page of the website I put in big letters : "This website is for sale - contact me at - - - - - " The next day they called me where to meet and pay me ! Because I am not a pro website developer and know little php (but I am good with html/css/api and photoshop) my rate is 15 euro/hour for html-css-photoshop work and 20 euro/hour for simple php work. I have studied coding rates per hour with google from many internet entrepreneurs and I know my rates are cheap but hey I am not a pro. I am learning everyday and my dream is to become a pro website developer and coder with pw and make a living with websites. That would be a dream come true for me and say goodbye to my work at a rent a car company. And I am sure I am not the only one on this forum with this dream. So people - please reply on this topic. My own experience with selling websites so far: 1. Only give FTP - Admin - Database - CPanel passwords to the client when he has fully payed you !! 2. Don't let your self get payed the total sum at the end but get payed each time you finished a part of the website, lets say in 3 or 4 parts. 3. Make it absolute clear from the very beginning that changes and edits on the website afterwards are going to be charged and for how much. Just too many clients take it for granted that doing changes and edits on their website afterwards are included with the end price they payed you. 4. Offer them from the very beginning a payed course if the client wants to edit the website for him self. By the way - this is also and exactly the reason why it is so important that a cms has an easy front-end for the client so he can edit his website in an easy way. 5. Informing your client about points 3 and 4 at the end makes them angry. Tell them at the very beginning. What I and many others, would like to read from you people is how to find new projects or new clients ? At what point do you hand over the ftp - admin - database and cpanel passwords ? How do you let your self getting payed for your work ? - at the beginning - in parts - at the end And where do you consider risks in the payment ? How many people here do actually make a living with websites and how many do it as a second income ? Ok thanks in advance for your replies.

@Vineet - Here's what I use: Online Project Management (for team projects): feng office http://www.fengoffice.com/web/community/downloads.php The latest version is quite good. Has tasks, time tracking, conversations, documents, calendar, reminders etc.. Time Tracking/Invoicing: Billings http://www.marketcircle.com/billings/ Non Time Based Invoicing: Totals http://www.kedisoft.com/totals/ The document customization and client management are a bit more advanced than Billings I also sometimes use Letter Me Later, good for when you need to send an invoice or message at some point in the future http://www.lettermelater.com/

Edited. Good luck with your restoration. Adam

You could add fieldsets to your templates, then let the content related stuff on the left and the storage & settings related stuff on the right side This way you could save some space. Template fields: fieldset_content (set to 60% width) title headline summary body fieldset_content_end fieldset_storage_settings (set to 40% width) images files amazing_checkbox etc... fieldset_storage_settings_end

I don't find it "scary", but I have been building web sites for long enough to know that many clients will reject the idea of having to type in codes, out right. It doesn't matter how "easy" or "clever" your codes are - code is code, and many clients want WYSIWYG and simply will not accept that. For myself, personally, it would work great - probably much better than a WYSIWYG. But you and I are programmers. A lot of non-programmers will throw their arms up in despair at the sight of an angle bracket. And I get that. We should be able to come up with something better for those people. Something that is as easy and as visual as a WYSIWYG, without sacrificing ease of use or introducing codes. I say we should be. I don't think it has been done yet - if it has, I still haven't found it...

For that to work, you would have to use some recursive function in order to go through every category and make a UL tree from them. My question to you is: why do you want to output a massive tree of categories and list all downloads under each of them like you're trying to do in your code? It would make more sense to me if, depending which category you're viewing, it just shows the child category titles so you can click through to them as well as the downloads for the current category.

EDIT: In fact I've just rolled it out across most forums where I think it made sense. The topic starter as well as moderators and admins can choose a best answer.

Just to defend again ImageManager... you can select and insert images in wysiwyg as usual.. just browse the pages and select the image. It's mentioned in the description. Also I don't think it's hard or complicated to copy a tag into the body.. and after saving you'll see the image and can threat it as with all image s in tinymce.. for example change the image or resize it in the editor. But I think people are too scared to even try it so it's a little hard without people testing and giving feedback to further develop it.

the selector should be on the page reference, like child('include=hidden')

Thanks Diogo...you've been quiet lately...summer break? Edit This throws up an error return $this->page->child->render('include=hidden'); Warning: array_merge() function.array-merge: Argument #2 is not an array in F:\xampp\htdocs\pwtests\wire\modules\PageRender.module on line 224 Can you supply arguments to render() like that?

Greetings, I like it! For this kind of client, I think the style you chose is just right. It's very professional, without appearing too "slick." The focus is on the information, with the right level of styling. Makes me trust them! And what a great coincidence on the "PW" thing! Thanks for sharing, Matthew

I havent used this with cache but it should work. You might want to consider using the LanguagePageNames core module that add the loaclized url support more integrated as this module will not be developed further.

@kongondo - thanks and apologies for my verbosity.. so this can be fixed by changing line 72 and 75 like so: } elseif ($this->page->child('include=hidden')->id) { // for the current stable version use this method return $this->page->child('include=hidden')->render(); and then making the child page hidden.. well you beat me to it...but your code looks slightly different

OK...quick hack to set child page hidden (hide it from sub-menu) but be able to render it... change // for the current stable version use this method return $this->page->child->render(); to // for the current stable version use this method [Kongondo ugly hack; how dare you!?! Tsk tsk ] $k = $this->page->child("include=hidden"); return $k->render(); Works for me; tested with Teflon. Will try others... @Diogo: Is my Macrura's "hack" a solution/concept you could incorporate as we all wait to move to PW 2.3.x ? Edit: Macrura's solution requires less changes...see below

Greetings, I was just about to post about the same thing that mindplay.dk posted above. When I built my first site requiring image management, I worried about images being separated from the WYSIWYG field. I thought the client would be unhappy with it. But it turned out they actually like the idea of seeing a list of images associated with the page. This surprised me. But now I think it makes sense. Although the images are separated from the text field... 1. This helps users visualize the page better to know what's available 2. At a glance, users can get a sense of the photographic presentation of their blog post or other page 3. Users can upload all the needed images at once 4. After uploading images, it's then simple for users to include them (same process as if they had not done an upload first) 5. I find that users think "page" more often than "site assets" anyway This could be one of those cases where we assume one way is easier, until we actually let users try another way. This is just my experience. Thanks, Matthew

<not-serious>Good luck! </not-serious> Did you know Somas ImagesManager? It could be an option, I think.

I eat them.

Starting in on a new site tonight and realized I never posted the last site we finished in March. www.la2050.org This was a information frontend site for a campaign to get people submitting proposals for a community funding project. Client was able to edit a ton of the site and never had any issues dealing with the backend. I learned a ton about markup/template organization from the threads here which were unbelievably helpful. Thanks everyone! Thanks Ryan!!!

Hey Everyone, I had to stop laughing so I could post ths: http://techcrunch.com/2013/06/05/microsoft-internet-explorer-10-is-the-most-energy-efficient-browser-uses-up-to-18-less-power-than-chrome-and-firefox/ Thanks, Matthew

Well... That was good It looks logical that Microsoft appeals to such a criterion after they've made this promo:

Hey Mike, I'll do it. But I'm sure you are aware that a discussion like that is going to become rather messy pretty quickly! Thanks, Matthew EDIT: OK, I posted! It's actually easy for me to post strongly positive statements about ProcessWire, since everything that's great about it is on my mind almost every day...

Marty, that is good dream to have (it would be superb feature). Soma: you are a machine.

Bravo! This'll open the flood gates to folk who expect this functionality in whatever CMS they use. "Somehow connect the image manager to a standard image field" <- An uber image field I rarely stick images into a wysiwyg editor and I have dreams where the standard image field can either accept an upload or link to another image on another page.

Soma, this is awesome! One minor suggestion: Instead of copying the image code by hand perhaps it is possible to copy it on click with Javascript? One major improvement: Somehow connect the image manager to a standard image field, so you can also insert existing images to it and / or mix it with single ones. Like I suggested here: http://processwire.com/talk/topic/1188-image-inputfield-like-in-tinymce/#entry10701 I know that we would need a way of symlinking to other images than the ones in the assets/files folder. But you are creative ;-) Great work!

Thanks guys, you are too kind. That calendar was done with Textpattern, but I built a proof-of-concept of essentially the same thing using Processwire. Ryan gave me some huge clues on using JSON. I'll post it when I'm back at the office next week.

What you are referring to sounds like a type of page reference, and I think you could use the Page reference fieldtype to achieve this pretty easily. Let me know if I can provide additional detail. But if you've got an instance where repeating the same image(s) is expected, then my preference is usually to code the template to pull them from a common page. For instance, in the default site profile, all the site's photos are on the homepage, and the rest of the site's pages pull them from there (at least for pages that don't already have photos uploaded to them). This is a technique I use on almost every site I build. Every page has an dedicated field for interface images. If no images are assigned to it, then it pulls from a common page, or the closest populated parent.

While the data import may be the hardest part of this, it's probably also going to be a lot simpler than you think. If you can get the data you need to import into some standard format (like CSV, JSON, XML, etc.) then you'll have no problem getting it into PW. Here's a really simple example of importing a CSV that has has fields for 'title' and 'body': <?php $fp = fopen("data.csv", "r"); $parent = $pages->get("/path/to/parent/"); $template = $templates->get("some-template"); while(($data = fgetcsv($fp)) !== false) { $page = new Page(); $page->parent = $parent; $page->template = $template; $page->title = $data[0]; $page->name = $data[0]; $page->body = $data[1]; $page->save(); } When the time comes, just post some details about what you are doing and we can get you started.