Leaderboard

Hey, after some days of work I finished my new admin theme called "Dark Business". Just try it out: https://github.com/NicoKnoll/Dark-Business---Admin-Theme

What you see on modules.processwire.com is part of a new Fieldtype module I've been developing on and off to support "like" buttons or star ratings by users. The implementation you see on the modules site enables anyone to anonymously "recommend" (like) a module, though the module itself does support limiting access to roles. When it comes to anonymous voting, the system prevents duplicates by both cookies and IP addresses, which isn't foolproof, but it's the best you can do short of having an authenticated user. It also requires Javascript and uses some cookie tricks, to keep the crawlers from voting. I put it up there a few days ago without mentioning it, and am surprised already at how much "recommending" has been going on, good to see. I'm also glad to hear there is interest in a module like this. I will keep working on it! It will also come with a Process module (under Setup) that lets you browse the liked pages in your admin For the star ratings part, I feel like this really is best kept to authenticated users (since one can also down-vote), so am looking into ways to limiting rating to those with PW user accounts and/or Twitter/Facebook/Linkedin accounts. I might ultimately just make the star ratings one a separate module, but still dwelling on it. Good idea, I will add this to the core.

Greetings, When it comes to flexibility in layout, I can't think of a system that is better than ProcessWire. Let me describe an example of what I had to do for a project I just completed for an arts organization with variations in their "event" pages. Sometimes, these events had multiple images, sometimes only one. Same for text: sometimes the event had text and other times it did not. Then there are combinations of these. (I'll be posting this as a case study soon). Using the same template, I had to shift the layout depending on which combination is true for that event: - Multiple images and text: I display text to the left and a lightbox gallery to the right of the text. - Single image and text: I display text to the left and display a static, full-size image to the right of the text with no lightbox. - Multiple images and no text: I display a lightbox gallery on the left (where the text woukd normally go). - Single image and no text: I display a static, full-size image on the left (where the text would normally go) with no lightbox. Because of the design freedom of ProcessWire, I was able to build some logic into my templates to detect what is going on and render different outcomes. Of course, in my examples above I have coded these variations. I have not allowed the client (for example) to decide randomly where to insert text and/or galleries or single images. In my opinion, I would advise any client against this kind of strategy, as it actually ends up limiting -- not expanding -- each element, and I think it leads to messy sites. As diogo said, there is value in explaining the need to constrain in some ways. Thanks, Matthew

Please don't pay any attention to systemVersion. I was just trying to explain what it was for those interested, but it's not something anyone but core devs need to think about. The dev branch is not an official release and I want to be careful about anything that might present it that way. People don't even need to know about the dev branch unless they are interested in helping to test or develop ProcessWire, or (in this case) take advantage of the multi-language updates before they appear in PW 2.4. It's a branch that gets updated a few times a week, sometimes even daily or more. For a dev branch like this, the commit ID is the version, and the commit log is the README. Everything on dev is basically "being prepared" for an official release, so you wouldn't typically have separate README files for master vs. dev, etc., because dev is not a release, it's a branch working to eventually become a release. It's best to follow the commit log of the dev branch to see what's happening. It's also best to use the dev branch with Git (git checkout dev), and not by downloading a ZIP file. Typing "git status" will tell you what branch you are on (master or dev), and "git pull" will pull in the latest version instantly. I understand that Git can be confusing and a whole lot to figure out (I'm still learning it myself), but we are getting into the nature of how Git and software development work. The audience here is intended to be developers and testers, where Git is the standard. It's not supposed to be neatly packaged, versioned and ready for the consumer, and will always take more time investment on the part of anyone using it. We want users to have some experience with Git when using the dev branch because we are asking them to help test, report, and potentially fix issues through the GitHub system. I think part of the confusion here is just that we are getting very close to a 2.4 official version release and the dev branch is quite stable. So the distinction between official release and dev is probably more blurry than usual. Without thinking much about it, I've been casually telling people to use dev when it seems to make sense. But that will change as we hopefully release version 2.4 soon.

Thanks guys, and sorry about the bug there. The problem was actually not what was highlighted above, but this line: public function render($value) { $value = $this->formatValue(new NullPage(), new Field(), $value); // this line return $value; } ...is supposed to be this: public function render($value) { $this->formatValue(new NullPage(), new Field(), $value); // this line return $value; } The formatValue function accepts $value as reference, not a separate copy (i.e. &$value rather than $value). So the line that blanks out $this->value is intentional. The point of that is to clear the memory, ensuring the module doesn't keep a separate copy of the text, since it no longer is working with it. So if you commented that line, I would uncomment it again. Actually I'm updating the source to fix the issue now, so you can also just grab the latest version.

I've never come across a client that didn't prefer a rich text editor to the alternatives. The reality is, they like RTEs because it's something they are already familiar with and it's easy for them to use. So I think a better goal is to give them what they want, but place limits upon it so that it can't produce a mess. Just because RTEs+clients can create a mess doesn't mean we have to let them do it. Both our TinyMCE and CKEditor rich text inputfields come very much restrained and prevent the client from creating a mess. CKEditor4 and it's ACF (advanced content filter) seem particularly adept at solving this problem. If you can convince a client to use an LML (Markdown, etc.) or some method of creating content in blocks, then that's fine. But once the next guy comes around showing them "look what you can do in my CMS–it's like using Word", you may be at a disadvantage. Other factors to consider: 1) content maintained by blocks may be significantly less portable through future CMS changes, web service/syndication feeds and such; 2) it may be more difficult to maintain site-wide consistency with the designer's original vision if a site's main content area is a mashup of content blocks. Personally, I would avoid trying to pursue a blocks strategy for most content editors, whether in a CMS that is built around the concept, or via trying to build everything around Hanna Codes. Instead, let the designer do their job and determine consistent and well thought placements for photo galleries, navigation, etc. I see Hanna Code as being better for the exceptions of needing something somewhere, and not something that editors should have to keep as part of their vocabulary.

I've recently updated my website. This is the first site I've made in it – although I have one other that's in progress (which unfortunately may never be used) – and compared to the process of making a site in something like Wordpress it was far simpler and quicker, and is much cleaner, easier and streamlined for updating, etc. It's a fairly simple site made with Twitter Bootstrap, Masonry.js and making use of the Dribbble API, with the aim of letting the images do the talking.

More and more, processwire has become my personal haven... I do almost no commercial work with it (I work as a dev, and for payed side-projects I suffer the dread of joomla droppings ) Made this "thing": - http://www.lisboncorrespondent.com/ This is a blog (of sorts) for my father, with make-pretend postcards sent from Portugal. It is essentially a way for me to experiment with and learn a few techs/tools: css 3d transforms (and respective headaches, cross-browser issues, etc) The wonderful angularJS framework Yeoman (build system for js apps, with grunt + bower) Processwire, of course Processwire is amazing for every crazy thing I may ever think up, and using it as a simple RESTy service provider is incredibly simple. Gotchas: This will most likely be a perma-beta site - it is for trying stuff No history back/forward or direct urls - angularJS makes it easy, but it wasn't really my concern. Will have to happen someday, though No SEO whatsoever - I'm perfectly aware that a "blog" in a one page app is a no-no, but again, just toying around Tested with Chrome, Firefox and IE 10, OSX and Win - further compatibility (and mobile) to come Hope you enjoy. And thank you, Ryan, for the wonderful gift of processwire

Lets see if we can get a quick-start tutorial going here. We'll start with something really simple and then work up from there. Tell me when something makes sense and when it doesn't and we'll adjust as we go. My thought is that we'd make a tutorial that plays on the 'hello world' phrase and lists information about planets in the solar system, starting with Earth. To keep it simple, we'll assume that the basic site profile is installed, as that's what comes with ProcessWire (so there's no need to uninstall anything). But we won't start using any of it's files tat this stage. Instead, we'll start out by creating our own files. STEP 1 – Create a template file Create a new file called: /site/templates/planet.php, and copy+paste the following HTML into that file: <html> <head> <title>Earth</title> </head> <body> <h1>Earth</h1> <h2>Type: Happy planet, Age: Millions of years</h2> <p>Earth (or the Earth) is the third planet from the Sun, and the densest and fifth-largest of the eight planets in the Solar System. It is also the largest of the Solar System's four terrestrial planets. It is sometimes referred to as the World, the Blue Planet, or by its Latin name, Terra.</p> </body> </html> The above is just a plain HTML file with nothing specific to ProcessWire. We will use this as the starting point for our template, and we'll go back and modify it later. STEP 2 – Add a template to ProcessWire Login to ProcessWire admin and go to Setup > Templates. This page shows a list of templates currently in the system. Click the Add New Template button. On the next screen that appears, you'll see it found your "planet" template file. Check the box next to the planet template and click Add Template. You may ignore any other options that appear on this screen. STEP 3 – Creating a page using your template Your planet template is now in the system and ready to use, but it's not being used by any pages. So lets create a page that uses the planet template. In the ProcessWire admin, click Pages in the top navigation. This is a site map if your page structure. We want to create a new page under the homepage, so click the new link that appears to the right of the home page. The next screen has 3 inputs: title, name and template. Enter "Earth" for the title, and the name should populate automatically. For the template, select planet. Then click Save. Now you have created a new page using the template that you added. You are now in the page edit screen and you should see your title field populated with "Earth". Click the View link that appears on this page edit screen. You should see the output of the HTML from step 1. Click the back button in your browser to return to the edit screen. STEP 4 – Creating a new field Now you know how to create a template and a page using that template. You could create more pages using the same template if you wanted to. But that wouldn't be particularly useful – this template file is just a static HTML file. Lets make it dynamic by creating some fields and adding them to it. We are going to create 3 fields to represent the pieces of data that currently appear in our static template. These include the planet's type, age in years, and a brief summary. We will call these fields: planet_type, planet_age and planet_summary. In ProcessWire admin, click Setup > Fields. This screen shows a list of fields currently in the system, most of which are general purpose fields for the basic profile. For the purposes of this tutorial, we are going to ignore those and create our own. Click the Add New Field button. On the next screen, enter "planet_type" for the Name, select "text" as the Type, and enter "Planet Type" for the Label. Then click the Save Field button. Now that your field is saved, you are on the Field Edit screen. At this point, your field is created and ready to be added to your planet template. Optional: While editing your field, click the details tab where you'll see a select box for Text Formatters. Select "HTML Entity Encoder" – this ensures that characters like "<", ">" and "&" will be converted to HTML entities and not confused as HTML tags. While not required, it's a good practice for text fields like this. After you've done that, click the Save Field button. STEP 5 – Creating more new fields In step 4 we created the planet_type field. Now we want to create the planet_age and planet_summary fields. So in this step, you'll want to do the same thing for the remaining two fields: Create the planet_age field exactly like you created the planet_type field, but enter "Planet age in years" for the label. Create the planet_summary field exactly like you created the planet_type field, but chose "textarea" as the Type and enter "Planet summary" for the label. Note that a "textarea" field is just like a "text" field, except that it can contain multiple lines of text. STEP 6 – Adding new fields to your template Now that you've created 3 new fields, you need to add them to your planet template. In ProcessWire admin, click Setup > Templates > planet. You are now editing your planet template. In the Fields select box, choose planet_type, then planet_age, then planet_summary. You will see each added to the list. Cick the Save Template button. STEP 7 – Editing a page using your template Now that you have new fields added to your template, go back and edit the Earth page you created earlier and populate the new fields that are on it. In ProcessWire admin, click Pages at the top, then click the Earth page, and click the edit button that appears to the right of it. You are now editing the Earth page you created earlier. You should see the new fields you added, waiting for text. Enter "Terrestrial planet" for Planet Type Enter "4.54 billion" for Planet Age in Years Paste in the text below for Planet Summary and then click Save. STEP 8 – Outputting dynamic data in your template file While still in the page editor from step 7, click the "View" link to see your page. Note that it still says "Happy planet" for type (rather than "Terrestrial planet") and "Millions of years" rather than "4.54 billion years". That's because the page is still being rendered with just the static data in it. We need to update the template file so that it recognizes the fields we added and outputs the values of those fields. Edit /site/templates/planet.php and replace the static text in there with tags like this, replacing field_name with the name of the field: <?php echo $page->field_name; ?> If supported by your server, you may also use this shorter format which some people find easier to look at and faster to enter: <?=$page->field_name?> Here is the /site/templates/planet.php file updated to output the content of the page using tags like the above: <html> <head> <title><?php echo $page->title; ?></title> </head> <body> <h1><?php echo $page->title; ?></h1> <h2>Type: <?php echo $page->planet_type; ?>, Age: <?php echo $page->planet_age; ?> years</h2> <p><?php echo $page->planet_summary; ?></p> </body> </html> After making these changes, save your planet.php template file. Now view your Earth page again. You should see it properly outputting all of the content you entered on the page, including "Terrestrial planet" for Type and "4.54 billion years" for age. Any changes you make from this point forward should be reflected in the output. STEP 9 – Creating more pages, reusing your template For this last step, we'll create another page (for Jupiter) using the same template just to demonstrate how a template may be reused. In ProcessWire Admin, click Pages and then click the new link to the right of the home page. Enter "Jupiter" as the Title and select "planet" for the Template. Click Save. Now that you are editing the Jupiter page, enter "Gas giant" for Type, enter "4.5 billion" for Age in Years, and copy+paste the following for Planet Summary: Click the Publish button and then View the page. You should now see your planet template being used to output the information for Jupiter rather than Earth. CONCLUSION In the above, we covered the basics of how to develop in ProcessWire, including the following: Creating templates and their associated template files Creating basic text fields and adding them to templates Creating and editing pages that use your templates Outputting the values of fields in template files If all of this makes sense so far, I thought we'd follow up next with a tutorial to take this further: Adding and outputting photos for each planet Creating navigation that lists all the other planets that have pages in the system …and we'd keep building upon the tutorial from there. If you all think this tutorial is helpful, then perhaps this can be a draft for a real tutorial we'll put on the site, so all of your help is appreciated in making this as good as it can be.

Hello, I need something that is probably quite simple for anyone that is familiar with developing modules in PW. I need to augment the FieldtypeComments module with a 5-star rating field. That's all. The user would see an additional drop-down field when they post the comment that allows them to select a value from 1 to 5 stars. I intend to make the resulting module available publicly for the community after it is developed, as i think it is an essential part of the module collection that is sorely missing at the moment. Please contact me on Skype ( my ID is ovidiu.savescu ) with offers on how much this would cost. Thanks!

Great theme Nico! I really like where you are going with this, and the tree of pages in the sidebar is a nice feature for sure. This is a very innovative theme and nicely designed as with all of your work. I understand where Diogo is coming from in that it might be nice if nothing was cut off from the content column (i.e. it had a max-width: 100%; or something, so the fields would scale for the space). After playing with the theme for awhile, I think this is primarily an issue in this scenario: after clicking "edit" on a page, it opens the page to edit, then pops open the sidebar and page tree again, making it necessary to close those two sidebars before I can start editing. Unless I'm missing something, it appears one has to close the sidebars before every page edit (a lot of extra clicks). If it simply didn't open those two sidebars when I was going to edit a page, there might not be an issue with the way it truncates the main column. I like this theme a lot, so want to point out some very minor details of items that looked like they might still need styling: Appears to be extra indentation on the pagination links. Plus I was guessing the links aren't supposed to be underlined? Note the blue "more" link: Getting this notice on a log of pages: Unexpected indentation? Unexpected space before the change link? Unstyled button? Unexpected indentation? Some unexpected styling here Lastly, the "show actions on hover" in the page list was tricky to navigate in the admin, just because the narrow column always meant the actions fell to the nextline, making the pagelist jump all over the place on hover. I guess my personal preference would be to not have it show the actions on hover but on click instead (like the default admin theme), but this is just personal preference. I'm only nitpicking here because I really like what you've done, and would like to use it. Great work!

In my experience, clients understand and accept very well when you tell them that you created some constrains on purpose. The important is that they look at their website and their friend's website and see why theirs looks much better.

Install MAMP and you'll be happy. I don't even bother experimenting with the AMP stuff that comes bundled with OS X.

You guys got me curious about PBCKCode, so I tried to install it here. Seems to work nicely. Not sure if this helps, but here's how I installed it. I downloaded the ZIP from here then extracted the contents to /site/modules/InputfieldCKEditor/ckeditor-4.1.2/plugins/pbckcode/. Then I went and edited my 'body' field and added a line for "pbckeditor" to the toolbar, and another for the "extra plugins". Then in "Extra Allowed Content", I added: "pre[class](*)". See the attached screenshot of my config screen for CKEditor. I opted not to keep the "data-pbcklang" attribute that it adds to the <pre> tag. Though I'm sure HTMLPurifier would strip that one out anyway. I figured that wasn't necessary since I already had a class tag identifying the language.

Andrew, That's obviously MODX syntax. Before I answer your question, I have two things to say: 1. Please, if you have a question, post in either the General Support or the Getting Started or the API & Templates sections of these forums according the the relevance of the question.. This is the Tutorials Section of the Board where your posts/threads should be teaching something rather than asking questions, thanks. 2. Have you read this guide to PW for those familiar with MODX? If not, please do. It will answer questions such as above. As you'll see from that guide, apart from the name of a page, all other fields on a page are custom fields. There is no default title, keywords, description, etc fields. You will have to create those fields and add them to your template. Then, create a page and make it use that template. If you want your keywords to be unique to each page, then do it this way (illustrated below). If you want your keywords to be the same across the whole site, then you can create a page that will act as a settings page. For now, I'am not going to go into details about such a setup but will let you explore the system more. OK, so, 1. Create the following fields types a. Name: keywords; Type: text or text area (depending on how much space you want) b. Name: description; Type: text area Make sure to give the fields labels and a "description" if you want to. Your PW install should already come with the title field (if you installed the default PW profile) 2. Add the fields to your template. Order the fields in the template as you wish 3. Create a page and make it use the template in #2 4. You will see the keywords, description and title fields on that page. Enter your keywords and description in the fields and edit the page as you wish. Hit save. 5. In your template file <meta name="keywords" content="<?php echo $page->keywords;?>"/> <meta name="description" content="<?php echo $page->description;?>"/> <meta name="robots" content="All"/> <title><?php echo $page->title;?></title> You don't need the <base> tag in ProcessWire. You can get fancy and only echo out the keywords and description if they are actually present on your page. How to do that? That'll be your homework

Hey Ryan, Some feedback from the dev on these issues: https://github.com/ed-lea/jquery-collagePlus/issues/6#issuecomment-22058143 https://github.com/ed-lea/jquery-collagePlus/issues/5

Just curious - you say that you want to make the title field unique, but in your code you are trying to set the value of the invoice_number field. This should do what you want, assuming you actually want to set the title field. <?php class MarkupTitleField extends WireData implements Module { /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * * @return array * */ public static function getModuleInfo() { return array( 'title' => 'Markup Title Field', 'version' => 100, 'summary' => 'Set the title field to predefined value', 'singular' => true, 'autoload' => true, ); } public function init() { // add before-hook to the inputfield render method $this->addHookBefore("Inputfield::render", $this, "renderField"); } public function renderField(HookEvent $event) { // // get the current field $field = $event->object; if(($field->name == 'title' || $field->name == '_pw_page_name') && $field->value == '' ) { $last_page_id = wire('pages')->get("include=all,sort=-id")->id; $id = date("Y") . "/" . ($last_page_id+1); // example for a possible id value $field->set('value', $id); } } } Edited code to get the id of the page that is about to be created. Not sure if this is completely robust. You might want to consider a different unique identifier.

Glad you got it working. Have you seen the API cheatsheet? http://cheatsheet.processwire.com/ path vs url is explained there for use in both $page-> and also $file-> Your best way to really figure some of this stuff out is to echo the results to the page. echo 'url: ' . $child->webfont_archive->url . '<br />path: ' . $child->webfont_archive->path; That way you can see exactly what is being returned.

Thanks for the kind answer Ryan! it's really simple...

Lots of third party libraries, modules, apis, etc, out there. http://www.phmagick.org/examples/examples/convert http://www.phpclasses.org/package/2073-PHP-Convert-images-between-several-formats.html http://www.developphp.com/view.php?tid=1146 http://stackoverflow.com/questions/5060835/how-to-convert-all-images-to-jpg-format-in-php http://java.dzone.com/announcements/java-library-images-conversion

I try and back it all up to Brain 1.0, but I think Brain needs an upgrade

It's interesting to read other people's perspectives on this. Although I am in Europe (UK), we are not part of mainland Europe, so I think that makes a big difference, not only to the practicalities of seeing the rest of Europe, but of attitudes towards the rest of the continent. While someone living in Spain could easily drive to Portugal or France, we have that annoying and expensive 22 miles of water to cross (the English Channel/La Manche). It doesn't make any difference to aeroplanes, but to everything else it does. As far as duration and timing of holidays goes, I come from a part of England (the North West - Liverpool, Manchester, the Beatles, the Mersey sound, Factory Records, the seat of the Industrial Revolution, the world's first passenger railway etc are all within 30 miles of my home town), where traditional Wakes Weeks still play a significant part in people's holiday schedules. That said, the ubiquity of cheap air travel has made the rest of Europe much more accessible. I know, for example, many people who have held their stag party (bachelor party) in Amsterdam in Holland, Bruges in Belgium and even Prague in the Czech Republic. If I were to make suggestions to anyone from outside Europe of where to go in Europe, some of my favourite places would, of course, be 'my' bit of England, but also London, Scotland, Normandy in France, some of the less developed parts of Spain, and just outside Europe, but not until things there settle down (if they ever do), Egypt is extraordinary.

I visited the United States twice: the first time I went to New Jersey and New York. The second time to Washington. Next time I want to go to California (San Francisco) or Louisiana (New Orleans).

Ryan if you would ever come to Spain we got place four you four at home, Valencia.

No good news from spain. Haven't had vacation since 10 years. Portugal, Greece and Spain suffer the most from the economic crisis compared to all the other european countries. 30 percent unemployed and many jobs are payed now without social security, take it or leave it. The government does only little control and doesn't care much. So it's surviving here. Except if you find a job in a hotel or in a bank. They still pay you all the social security and holiday money. But since I am originally from the Netherlands I can tell you how dutch people take there holidays. Usually 2 to 3 weeks in July, August or September, this is high season. First the north, then the middle and last the south of the Netherlands. You have to use up all your 5 weeks holidays before the end of the year so the rest is taken during the year and in december with santa claus 6 december and with christmass 25 december. In the summer most of the dutch go to the south on a camping in Italy and France or the touristic south coast of Spain or the fantastic climate on the canary islands (only 4 hours flying). Almost all hotels on the canary islands offer an all-in package, that is flight ticket, bus transport, hotel room, breakfast and dinner all included for 1 cheap price. However this hotel formula has destroyed many local restaurants and bungalow parks on the canary islands. The last 10 years the east became popular too like thailand. Very friendly and hospital people (thanks to buddhism), cheap hotels, bungalow parks, beautiful nature, fantastic kitchen and climate. Many real estate companies in spain and on the canary islands are looking now for housing to rent in thailand and do good business.

Hi Ryan, I assume you are self employed, so you could go for a couple of weeks with you family to various places in Europe (or somewhere else) and stay in appartments via https://www.airbnb.com or http://www.9flats.com and work from there ...no? been to the east coast of the US when I was 14 Boston (went to school there for a couple of days), New Yourk & Florida. California and the rest of the US west would probably my no1 choice for an US trip. Usually I go on ~ 4 week trips, but stay around one area and make sure I can work from there.

There was a study done here (Australia) recently about why so few Americans visit: mainly because, as you mentioned, you get short holidays and secondly, Australia is a *really* lengthy plane journey from the States, especially the east coast. The other problem with coming here is it's such a huge place and to get around you have to fly everywhere. So y'all use up your precious relaxing/sightseeing time with more flights. Pffff. And that's not so good with kids either. If I was taking the fam to Europe for two or three weeks I'd most likely pick three cities and stay at each one for a week. My choice would be perhaps: Paris, Prague and Berlin.

Hi nfil, Don't know whether I've said welcome to PW or not. If not, welcome . Are you allowing multiple or single file uploads on that field? If single... if ($page->pdf_docs_insert){ $myfile = $page->pdf_docs_insert; echo "<a href='{$myfile->url}' target='_blank'>$myfile->description</a>"; } else { // ... } If multiple files, the field returns an array, hence you need to loop through it... if ($page->pdf_docs_insert){ $myfiles = $page->pdf_docs_insert; foreach ($myfiles as $myfile) { echo "<a href='{$myfile->url}' target='_blank'>$myfile->description</a>"; } } else { // ...please give me some files mate! } Check out the cheatsheet for more info

@John: it's possible that you'll have to add both pre and code to your field settings. When you edit that particular field, see Input > TinyMCE Advanced Configuration Options > valid_elements. If these tags are not included there, you'll have to add them first (simply append ,code,pre to existing content there.) When replying, you can attach an image by hitting "More Reply Options". This way you should get the full editor view and at the bottom there should be file upload options. Edit: taking another look at your screenshot, I don't think those fenced code blocks even should work. Currently you've probably got a paragraph containing "~~~~", another containing your code and then third paragraph containing again "~~~~" when you view the resulting markup, right? TinyMCE starts a new paragraph each time you hit enter, which might cause an issue here. You could try adding forced line breaks (shift+enter) after (and most likely before) your fences, to separate fences and code (and each line of code from eachother.) This could work better, but I'm not 100% sure about that either. Ultimately I don't think that Markdown extra will work nicely together with TinyMCE, so you'll probably be better off with simply using pre or code blocks created by the editor itself. I'm not sure why TinyMCE would strip <pre>, unless it's not include in the valid_elements setting, though. You could also try dropping TinyMCE and going with CKEditor. I find it more suitable for the kind of stuff I write, including code blocks within text (I use pbckcode plugin for actual code editing.)

Images are stored in /site/assets/files/1234/ where 1234 = id of the page containing that/those image(s) .. The reference to the image (the image name, e.g. myimage.png) is stored in the database in a table which bears the image field name. E.g. if you created an image field in PW called photos, in the DB it will be named field_photos. That is where the image(s) name will be stored...The names and other data are stored as rows in that table. Hence, if you created an image field that can only hold 1 image, you will only see I row in the respective table. If you have an image field for multiple images, you will see multiple rows. The columns in the table help identify what image belongs to what page. The columns are: pages_id: (whose image is this column . This will be equivalent to the name of the folder in /site/assets/files/1234. In this case pages_id=1234) data: name of the image sort: sort order of the images; only useful when there's multiple images of course description: self explanatory modified: ditto created: ditto So how does PW know what type a field is? That information is stored in the table fields for each and every field in your site. If this sort of thing interests you, have a look in the PW database using phpMyAdmin or similar... . It will help you better understand the PW DB schema and the genius that it is..simple but effective. As for image compression, I only have limited knowledge about that at present so can't answer definitively...

Hi hafa and owzim I haven't been on here in a while as my work commitments were with things other than web development. I have been asked to once again look into migrating our company's old site to something new (which will very likely be ProcessWire with the Twig templates) so I will be looking at this again. I haven't yet tried the module with the latest build of ProcessWire but unless Ryan has made some major changes to things I can't imagine there being an issue. I will of course test it properly when I get to working on the site and make any updates if necessary. As for it's interaction with the cache I admit I am not sure. Twig caches itself to "raw" PHP code, which I believe has quite good performance, but beyond that I have not tried anything. Let me know if there is anything more you'd like to know and assuming my work priorities don't get shifted on me again I will hopefully be able to look into it

I agree, I think export/import methods like this on Fields and templates would be nice. There's a lot of considerations though, especially on import. Like whether individual fields already exist or not, whether those field definitions reference external things (like page IDs). That's not to say it isn't doable, but just that there is potential for it to get quite a bit more complex than it first appears. But I would like to implement some API level expor/import functions for this soon, to at least get things moving forward. I've already been working on similar export/import functions for Page objects (which you see in the latest dev branch, though they aren't yet active).

I build this yesterday and Ovi sponsored it for open source. Little tweaks and testing before release.

Would really like to know if any was able to get option 1 here working with hostgator? I have set up everything perfectly, but for some reason it does not want to point the sub-domain. Update! After banging my head for a few days. To "point" a domain in most shared hosting accounts is to "park" a domain. Now that I feel dumber , I hope someone else will find this useful. It works perfectly!

Thanks Ryan for that beautifully succinct summary of what I was struggling to work out(!). I have almost bitten the bullet that is upgrading my hosting (by migrating to an uprated product that has PHP 5.4.x) and until I do I will just continue to use that simple work-around. Thanks for the clarification Ryan

It's correct that passwords can't be retained if you are developing a site in > 5.3.7 and migrating to a server running < 5.3.8. Best bet is to avoid any web server running an old version of PHP. But if you can't do that, then you'll want to reset your password at the live server after migrating the site to it. I usually paste this into my site/templates/admin.php, open the /processwire/ URL (to run it), and then remove it. $u = $users->get('ryan'); $u->of(false); $u->pass = 'mypass'; $u->save();

Thanks for the suggestion Dave, I may try this if I have time OK: The result is as follows (my hosting is stuck at PHP 5.3.5): ## Test 1 1. with MAMP PHP ver 5.4.10 install PW 2.3 locally 1. copy files and db export to hosting 1. go to login at hosting results in `Unable to generate password hash` ## Test 2 1. with MAMP PHP ver 5.3.20 install PW 2.3 locally 1. copy files and db export to hosting 1. go to login at hosting results in `Unable to generate password hash` see update 2013-05-13-1310 Conclusion: If I am correct then (since PW 2.3?—I've never seen this before so I am wondering if this came with v 2.3 of PW) if your hosting env is below 5.3.7 and you export/import a db from a local copy of a site to the hosting env then logging in won't work and will require the password being reset with a combination of Ryan's tactic and the edited Password.php file noted by Radek. NOTE: This conclusion may well be incorrect but I've run out of 'clever' and need some confirmations from those much cleverer than I on PHP/security/PW. Bottom line it's making me think I ought to upgrade my hosting past PHP 5.3.7; only trouble is it seems it's NOT easy to do this with an (mt) dv setup unless you are more of a sysadmin than I am :/ Crap. UPDATE 2013-05-13-1310: if my local env is set to PHP 5.3.20 (so like my hosting which is at 5.3.5 they are both below 5.3.7) then as long as I reset the local password as explained in 'Conclusion' above then I can now export a local db and import it over at hosting and login OK.

Hmm, this process did not directly work for me, I followed the steps but kept being denied access at the remote site. I then managed to lock myself out of my local site! So I used this Ryan tactic to get back into my local site, all good. Then I decided to try it at the remote site, so I uploaded a template with the password reset code and visited the page to make it run, returned to the admin login and WAS able to login. It now seems that if I change password locally and export the db to the remote site I kill the ability to login remotely but once I've fixed that with Ryan's tactic and am able to login at both ends I am now able to export the db locally and import it at the remote end (so able to move edits about if I need to) then login does not get broken and only re-breaks if I change the password locally. I am going to setup a vanilla clean install of 2.3 locally and then try to see if get the same (inability to login at the remote end without hacking about) or if I am able to login AOK. I hope it will be the latter (if it is then all I need to do is understand what is special about this install that it has this fragility). Will update this thread when test complete. Thanks again to Radek, Ryan et al.

OK, it's been a while since I looked at this, and much of it was inspired or guided by Ryan. I had to boil it down a little to make it generic enough to make sense, so this exact code hasn't been tested, but it should get you started. Here's a proof of concept that works. Template for your calendar page <?php function pagesToJSON(PageArray $events) { $json = array(); foreach($events as $event) { $json[] = pageToArray($event); } return json_encode($json); } function pageToArray(Page $event) { $data = array( 'id' => $event->id, 'title' => $event->title, 'start' => date("Y-m-d H:i:s",$event->start_date), 'end' => date("Y-m-d H:i:s",$event->end_date), 'url' => "./$event->id", // event ID is the url segment ); return $data; } if($input->urlSegment1) { // event ID provided as a URL segment to this page $event = $pages->get("id=$input->urlSegment1"); include("./includes/head.inc"); echo $event->title; echo $event->body; include("./includes/footer.inc"); } else if($config->ajax && $input->get->start && $input->get->end) { // fullCalendar making an ajax request of events $start = (int) $input->get->start; $end = (int) $input->get->end; $events = $pages->get("/calendar/")->children("sort=start_date"); $events = pagesToJSON($events); echo $events; } else { //display the calendar $config->scripts->add('/site/templates/assets/js/fullcalendar.min.js'); $config->styles->add('/site/templates/assets/css/fullcalendar.css'); $config->styles->add('/site/templates/assets/css/calendar.css'); $config->scripts->add('/site/templates/assets/js/cal.js'); include("./includes/head.inc");?> <div id="calendar"></div> <? include("./includes/footer.inc"); } // end else ?> head.inc <!DOCTYPE HTML> <html> <head> <title><?=$page->title?></title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <!-- CSS includes defined via $config->styles->add --> <?php foreach($config->styles as $url) echo "<link rel='stylesheet' type='text/css' href='$url' />";?> <!-- include jQuery --> <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.6.3/jquery.min.js" type="text/javascript"></script> <script>!window.jQuery && document.write(unescape('%3Cscript src="/site/templates/assets/js/jquery-1.6.3.min.js"%3E%3C/script%3E'))</script> <!--js includes defined via $config->scripts->add --> <?php foreach($config->scripts as $url) echo "<script type='text/javascript' src='$url'></script>";?> </head> <body> footer.inc </body> </html>

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.

I recently had to setup front-end system to handle logins, password resets and changing passwords, so here's about how it was done. This should be functional code, but consider it pseudocode as you may need to make minor adjustments here and there. Please let me know if anything that doesn't compile and I'll correct it here. The template approach used here is the one I most often use, which is that the templates may generate output, but not echo it. Instead, they stuff any generated output into a variable ($page->body in this case). Then the main.php template is included at the end, and it handles sending the output. This 'main' template approach is preferable to separate head/foot includes when dealing with login stuff, because we can start sessions and do redirects before any output is actually sent. For a simple example of a main template, see the end of this post. 1. In Admin > Setup > Fields, create a new text field called 'tmp_pass' and add it to the 'user' template. This will enable us to keep track of a temporary, randomly generated password for the user, when they request a password reset. 2a. Create a new template file called reset-pass.php that has the following: /site/templates/reset-pass.php $showForm = true; $email = $sanitizer->email($input->post->email); if($email) { $u = $users->get("email=$email"); if($u->id) { // generate a random, temporary password $pass = ''; $chars = 'abcdefghjkmnopqrstuvwxyz23456789'; // add more as you see fit $length = mt_rand(9,12); // password between 9 and 12 characters for($n = 0; $n < $length; $n++) $pass .= $chars[mt_rand(0, strlen($chars)-1)]; $u->of(false); $u->tmp_pass = $pass; // populate a temporary pass to their profile $u->save(); $u->of(true); $message = "Your temporary password on our web site is: $pass\n"; $message .= "Please change it after you login."; mail($u->email, "Password reset", $message, "From: noreply@{$config->httpHost}"); $page->body = "<p>An email has been dispatched to you with further instructions.</p>"; $showForm = false; } else { $page->body = "<p>Sorry, account doesn't exist or doesn't have an email.</p>"; } } if($showForm) $page->body .= " <h2>Reset your password</h2> <form action='./' method='post'> <label>E-Mail <input type='email' name='email'></label> <input type='submit'> </form> "; // include the main HTML/markup template that outputs at least $page->body in an HTML document include('./main.php'); 2b. Create a page called /reset-pass/ that uses the above template. 3a. Create a login.php template. This is identical to other examples you may have seen, but with one major difference: it supports our password reset capability, where the user may login with a temporary password, when present. When successfully logging in with tmp_pass, the real password is changed to tmp_pass. Upon any successful authentication tmp_pass is cleared out for security. /site/templates/login.php if($user->isLoggedin()) $session->redirect('/profile/'); if($input->post->username && $input->post->pass) { $username = $sanitizer->username($input->post->username); $pass = $input->post->pass; $u = $users->get($username); if($u->id && $u->tmp_pass && $u->tmp_pass === $pass) { // user logging in with tmp_pass, so change it to be their real pass $u->of(false); $u->pass = $u->tmp_pass; $u->save(); $u->of(true); } $u = $session->login($username, $pass); if($u) { // user is logged in, get rid of tmp_pass $u->of(false); $u->tmp_pass = ''; $u->save(); // now redirect to the profile edit page $session->redirect('/profile/'); } } // present the login form $headline = $input->post->username ? "Login failed" : "Please login"; $page->body = " <h2>$headline</h2> <form action='./' method='post'> <p> <label>Username <input type='text' name='username'></label> <label>Password <input type='password' name='pass'></label> </p> <input type='submit'> </form> <p><a href='/reset-pass/'>Forgot your password?</a></p> "; include("./main.php"); // main markup template 3b. Create a /login/ page that uses the above template. 4a. Build a profile editing template that at least lets them change their password (but take it further if you want): /site/templates/profile.php // if user isn't logged in, then we pretend this page doesn't exist if(!$user->isLoggedin()) throw new Wire404Exception(); // check if they submitted a password change $pass = $input->post->pass; if($pass) { if(strlen($pass) < 6) { $page->body .= "<p>New password must be 6+ characters</p>"; } else if($pass !== $input->post->pass_confirm) { $page->body .= "<p>Passwords do not match</p>"; } else { $user->of(false); $user->pass = $pass; $user->save(); $user->of(true); $page->body .= "<p>Your password has been changed.</p>"; } } // display a password change form $page->body .= " <h2>Change password</h2> <form action='./' method='post'> <p> <label>New Password <input type='password' name='pass'></label><br> <label>New Password (confirm) <input type='password' name='pass_confirm'></label> </p> <input type='submit'> </form> <p><a href='/logout/'>Logout</a></p> "; include("./main.php"); 4b. Create a page called /profile/ that uses the template above. 5. Just to be complete, make a logout.php template and create a page called /logout/ that uses it. /site/templates/logout.php if($user->isLoggedin()) $session->logout(); $session->redirect('/'); 6. The above templates include main.php at the end. This should just be an HTML document that outputs your site's markup, like a separate head.inc or foot.inc would do, except that it's all in one file and called after the output is generated, and we leave the job of sending the output to main.php. An example of the simplest possible main.php would be: /site/templates/main.php <html> <head> <title><?=$page->title?></title> </head> <body> <?=$page->body?> </body> </html>

Great solution, thanks for posting this Pete. I figure I should follow-up and post the route that I use too, though this one depends on the server running unix. It creates rotating backups off your non-web-accessible home directory with a cron job, and then a cron job on your machine (or another server) copies the backups over every day. 1. Login to your unix-based web account (SSH or FTPS/SFTP) and create a directory off your non-web-accessible home directory where the backups will be stored. I call mine /db-backups/: mkdir /home/your-account/db-backups 2. Create a file in your home directory called .my.cnf (starting with a period). This holds your DB connection information. Place the following into that file, replacing "mysql_username" with your database username, and "mysql_password" with your database password: /home/your-account/.my.cnf [client] user=mysql_username pass=mysql_password If working on a shared server or some environment where other accounts can get into your files, make sure that .my.cnf file isn't readable by anyone else. i.e. type "chmod og-rwx .my.cnf" to remove (o)ther and (g)roup read/write/execute access to it. 3. Create another file in your non-web-accessible home directory called db-backup and paste the following in there. Update the first two lines in the script to point to the directory you created in step 1 (DB_BACKUP) and the name of the database you want to backup (DB_NAME). /home/your-account/db-backup #!/bin/bash # modify the following to suit your environment DB_BACKUP="/home/your-account/db-backups" DB_NAME="your-db-name" # title and version echo "" echo $DB_NAME echo "----------------------" echo "* Rotating backups..." rm $DB_BACKUP/$DB_NAME.5.sql mv $DB_BACKUP/$DB_NAME.4.sql $DB_BACKUP/$DB_NAME.5.sql mv $DB_BACKUP/$DB_NAME.3.sql $DB_BACKUP/$DB_NAME.4.sql mv $DB_BACKUP/$DB_NAME.2.sql $DB_BACKUP/$DB_NAME.3.sql mv $DB_BACKUP/$DB_NAME.1.sql $DB_BACKUP/$DB_NAME.2.sql echo "* Creating new backup..." mysqldump $DB_NAME > $DB_BACKUP/$DB_NAME.1.sql echo "----------------------" echo "Done" Note: I found this code somewhere else online a couple years ago and don't remember where to properly credit it. 4. Save the above and make it executable: chmod u+x db-backup If you are connected via SSH, test it out to make sure it's working by typing: ./db-backup It should create the first backup in your ./db-backups/ directory. 5. Setup a daily cron job to execute that file: /home/your-account/db-backup … most web hosting accounts have some ability to setup cron jobs in the control panel. 6. Now your server is keeping rotating backups in your account. Next I'd recommend going further and copying them to another machine, automatically every day. How you do this depends on whether you are going to use SFTP/FTPS or SSH (with rsync). Its preferable not to use regular FTP since it's not secure. In my case, I've setup a cron job on my OS X desktop to copy over the files to my computer every day. It executes a file that looks like this: #!/bin/bash /usr/bin/rsync --archive --rsh=/usr/bin/ssh --verbose user@domain.com:db-backups/* /Users/ryan/Backups/db/ That copies those rotating backups to a /Users/ryan/Backups/db/ directory on my computer. In order for the above to work, you'd have to already be using SSH with your account and have your SSH keys assigned so that you can connect without typing your login/password. If anyone is running a similar setup, I'll be glad to tell you how to do that. But I know there are other ways to automate this task and the approach you use here kind of depends on the platform and whether you have SSH access on the server. This setup is pretty bulletproof, but I'd like to have some module in PW in the future that will let it do all of this for you – Automatic backups from one server to another.