Leaderboard

Everybody happy new year

AutoSave This module saves the page via ajax when editing in the admin. The interval for saving the page is configurable in the AutoSave module settings. By default it will only be enabled for unpublished pages. So far it seems to work fine for all fields and supports multilanguage. There's a message dialog show on top of page when saving happened with either a success or error. Requirements ProcessWire 2.3+. Haven't really tested with 2.3. Known Issues Nothing really obvious so far. Note that when you have multiple editors editing pages, it would be possible 2 persons editing the same page would overwrite each other, since the page is autosaved! The only solution for this would be to have my PageEditSoftLock module enabled with the complete "Lock" option active, so the page would be locked for editing. Todo Add some checks, if connection is lost. To be defined This module is currently a proof of concept. This module may not be suitable for all instances, but for personal use it may help preventing loss of long edits, most likely blog posts. Not sure this should be used for regular sites with clients editing. Most likely there's some more issues that interferer with what a CMS "page save" has to deal with. So you might find some ugly stuff happening. Thanks to Apeisa and his great Fredi font-end module, from where some logic is borrowed to save the page via ajax. Download https://github.com/somatonic/AutoSave So, that would be my last stroke for this year! Have a great silvester party and a happy new 2014!

Happy New Year to all Saturday 1st of January 2000 The first sunrise of the New Millenium as seen from my quarters in Taling Chan, Central Thailand, Thailand

I finally caught up with those 9 pages of posts and am down to 0 posts in my "new content" list. Sometimes things escape my new content list, so if anyone is waiting on me for anything or aware of something that I might have missed, please let me know. Happy New Year to everyone! Hope that you all have a great New Years day today.

Most of the instances I've heard of where people lost their work had to do with creating new pages that weren't yet published. For unpublished pages, the issue Pete mentioned is really not an issue at all. Perhaps a setting to limit the auto-saving to unpublished pages would be all that's needed, since that is the time when this module is likely most valuable. I'd suggest this might even be a good default setting. The 3 instances I'm aware of–Mike (cmscritic), Teppo, and Peter–would have all been for an unpublished page (I think) and would have been saved by this module. Nice job btw!

Welcome to the forums Marek! This knowledge: http://processwire.com/api/ + the basics of this http://www.php.net I am feeling too lazy to write...here's some light reading to help you get started http://processwire.com/talk/topic/2396-tips-on-getting-started-how-you-got-started/ http://processwire.com/talk/topic/1555-learning-oop/ http://processwire.com/talk/topic/2994-learning-php/ http://processwire.com/talk/topic/1927-php-the-right-way/ http://processwire.com/talk/topic/3518-what-ide-do-you-utilize/ http://processwire.com/talk/topic/2124-interactive-tutorial-knockoutjs/ http://processwire.com/talk/topic/4550-debugging-tips/ http://processwire.com/talk/topic/3115-javascript-resources/ http://processwire.com/talk/topic/2076-time-saving-tips/ http://processwire.com/talk/topic/1029-php-54/ http://processwire.com/talk/topic/2492-book-recommendations/ http://processwire.com/talk/topic/3925-project-management-for-developers-how-you-do-it/ http://processwire.com/talk/topic/4164-what-useful-freecheap-toolssoftware-for-freelancerssolopreneurs-do-you-use/ http://processwire.com/talk/topic/4250-whats-your-development-process/ http://processwire.com/talk/topic/4039-what-rss-web-designdev-feeds-do-you-follow/ Bottom line, only you can answer your main question (your topic title)....

Soma you and some other guys here make my job easy because most of the hard questions were already answered. So thank you for all the help and support give here. You all make this forum great.

Thanks Ryan for your precious time! I'm in awe how you still respond to most posts... I'm sure you missed some, but I'm also loosing control

I know it's only a Proof of Concept, but I'm 50/50 as to whether this is a good idea or not if it's auto-saving live pages, no offense intended, as it could be updating part-changed content on a live page if you're halfway through typing when it autosaves couldn't it? Some people write/edit loooooooong pages I think it would be better if it autosaved to another part of the site (under your process page for example) and if you leave the page you're editing and go back to it it could do a comparison of modified dates and ask if you want to edit the later, non-live version. Of course, that's quite a lot more code but it's just an idea (it's also leaning towards version control too in that case).

Happy new year! What the error is saying is that you are trying to call a class that has already been called (there's a better way to express this but Google is your friend). There's various ways to solve this issue: include_once: http://www.php.net/manual/en/function.include-once.php require_once: http://www.php.net/manual/en/function.require-once.php Another way around this is when you make copies of existing classes, to rename them...e.g. CommentFormCustom to MyCommentFormCustom. The experts here will give you better answers... .... Further reading. http://stackoverflow.com/questions/708140/php-fatal-error-cannot-redeclare-class http://stackoverflow.com/questions/2418473/when-should-i-use-require-once-vs-include http://stackoverflow.com/questions/2595171/php-include-once http://www.w3schools.com/php/php_includes.asp http://www.w3resource.com/php/statement/require_once.php

Yes, that would be great. FYI, the first thing I had done was to simply modify ___execute() so I could pass it a page id and it would return the $data array of revisions. Then I wrote the snapshot function. Then I got the idea to hook it to pages. A couple more thoughts... Normally the revision data will be limited by data_max_age or data_row_limit settings. If you give the snapshot method a timestamp older than the oldest revision data you get current Page data and don't know whether that's really what the page was like at the specified time or not. The simple change below helps but doesn't tell you the difference between a Page which never changed and a Page with changes that are no longer in the database. public function pagesnapshot($event) { $page = $event->data['object']; if ($data = $this->snapshot($page, $event->arguments(0))) foreach($data as $k=>$v) $page->$k = $v; else return false; //ADDED THIS } Is there a simple way to have the snapshot capability automatically hooked into pages which have tracked fields? I'm wondering if the VersionControlForTextFields gather method could set that up. I noticed after I deleted a page that the version info for it did not go away. If data_max_age hasn't been set it won't age out and get cleaned up.

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

Case Study: SignificatoJournal.com: Migrating from MODX Evolution to ProcessWire Contents: * Useful MODX Fields * Custom Template Files * Template Chunks * Field Chunks * Snippets * The Writer Table * The Migration Script * URL Replacement * Image Migration * TinyMCE Code Breaks * Post Migration Data Checks * Link to Script Content I just finished migrating the magazine site that my wife and I run (http://significatojournal.com) from MODX Evolution to ProcessWire. How I did it may be of interest to other MODX users that wish to migrate their sites to ProcessWire. I liked MODX because it was so flexible. My experience with ProcessWire has been that PW is even more flexible than MODX, and it breaks the 5,000 page MODX Evo barrier that was the great bugaboo in Evo. I attempted to use MODX Revolution multiple times but was very unsatisfied with the slowness of the editorial interface. There were also other reasons that I left MODX for PW, that have been addressed by other writers. After using PW’s API to build a large web app in 2013 (which will be a different case study), and now, after having migrated my magazine site to PW, I’m absolutely thrilled with ProcessWire. I could go on and on... There were many things that I liked about MODX Evo, that provided functionality that I wanted to continue to use in ProcessWire. They included: Chunks, snippets, and a combination of built in MODX fields and custom template var “fields” that I created for my former website, including: Useful MODX Fields MODX Fields: longtitle (headline) pub_date introtext (summary) template (id of custom template) menuindex menutitle hidemenu (show in menu) * In PW, I use the three menu fields to create the menu of the site, using Soma’s excellent module “MarkupSimpleNavigation”, with code like this: 'selector' => 'show_in_menu=1' * I use the publish_date field to block display of pages with future publish_dates, as well as to show the actual date of publication set by the editor (not just the date of the saved record). Custom Template Var Fields: subtitle writer_id static_author static_author_attribution newsletter_volume_number headline_thumbnail article_type sitemap_exclude code_blocks1-7 Custom Template Files MODX Evo allows one to assign a custom template file to each article, which I found very useful. Unlike PW, MODX Evo uses a primary static data field set for each article, with custom fields added on as “template vars.” The advantage of the custom template files is that it allows one to use different display templates for different types of articles or section pages. I generally use a four level method of: - home page - multi-section page - section page - article page Given PW’s method of creating virtual data tables, aka template “field sets”, with display template files assigned to each template field set, I had to work out a method to have the same type of flexibility of assigning display template files to each page. For example, an article page might be a regular article page, with writer information, or an “article_plain” page, like a Contact Us page. A section page could be a multi-section page, with a list of sections, or a paginated section page that lists articles. I also had a need for custom section pages, to display articles based on “content_tags”. My solution was to create generic PW template data field sets, that all ran one php template file called “custom_template_controller.php.” The two main PW template field sets are: * article_page_structure_permanent * list_page_structure_permanent Using this method, when a new page is created, I select the PW data template first: and then, once I’m in the main set of fields, I select the custom template file for that page: The custom_template_controller.php is very simple, and simply pulls up the custom template file assigned to the page, and runs it: <?php ################################################################################################### # custom_template_controller.php ################################################################################################### include("./inc_vars.php"); include("./inc_functions.php"); #.................................................................... # block future publish dates; don't block home page (id 1) if ( ( $page->id == '1' ) || ( ! empty( $publish_date ) and $publish_date <= $now ) ) { # page can be displayed } else { wire(session)->redirect("/http404", false); } #.................................................................... include("./$custom_template_file"); ################################################################################################### The "./inc_vars.php" file gets the value of the field: $custom_template_file = $page->custom_template_file->select_value; and also initiates a variety of variables and template “chunks”. Template Chunks MODX Evo allows one to define “chunks” of text that can be replaced in the templates or in data fields, using {{tags}} that are replaced at run time. In PW, I divided the chunks into sets of templates chunks, and a smaller set of field chunks. Because of the way PW uses PHP as its “templating” language (which I REALLY like), I decided to simply place the template “chunks” in a file called "./inc_vars.php", and define them as normal PHP variables. Since that file is loaded before every page, the variables are available to use in the custom template files. Field Chunks For field chunks, I created a PHP function that loops through a set of “chunk” data pages and looks for corresponding tags in the body field, and then replaces them. I placed the “field chunks” branch of data pages under a hidden master page called “elements”, which I also used for custom selects like the custom_template_files. The field chunks use the MODX delimiters of curly brackets {{chunk_name}} and the contents of the chunks are replaced. For example, “{{email.pfb}} is replaced with an image of the email address as the title of a clickable, Javascript encoded mailto: link. In MODX, the field chunk system also allowed one to replace tags in text fields of data coming from template vars (custom fields). I found that my primary need for that was with code that TinyMCE didn’t like, such as data entry forms or special Javascript, so I created seven “code_block” fields, e.g. “code_block1” … “code_block7”. Seven is a bit much, but at the time I created the fields in MODX, I was using many Amazon affiliate tags for books and CDs, in various articles. Snippets MODX Evo also has handy-dandy snippet tags that get replaced at run time. For my purposes, I only need to replace snippets in the code block fields, prior to replacing the code block tags in the body text. For example, I have a form that needs to display a dynamically generated captcha image that gets created by a Perl script. So, in the code_block1 field of the article, which contains the form, I place a snippet tag: [!s_form_get_captcha!] which then gets replaced by the same function that parses the chunk tags. I used the syntax [!...!] from MODX Evo mainly for convenience. Unlike MODX, the ! exclamation marks don’t affect caching of the snippet. To work with the snippet tags, I created an array in the chunk parsing function that attaches the snippet tag to the name of a PHP include file: $snippet_array = array( '[!s_form_get_captcha!]' => '/home/sigj/s_form_get_captcha.php', ); In this case, the PHP file “s_form_get_captcha.php” contains a backtick call to a Perl script which returns the dynamically generated captcha image. But, the PHP file could contain any normal PHP code that has to be generated at run time. Here are the contents of the function that parses chunks and snippets: ################################################################################################### function parse_field_chunks($page_id) { $body = wire(pages)->get("$page_id")->body; $snippet_array = array( '[!s_form_get_captcha!]' => '/home/sigj/s_form_get_captcha.php', ); #.............................................................................. $field_chunk_id_array = wire(pages)->find("parent=1052, include=all"); foreach( $field_chunk_id_array as $chunk_id ) { $chunk_name = '{{' . wire(pages)->get("id=$chunk_id")->name . '}}'; $chunk_value = wire(pages)->get("id=$chunk_id")->chunk; $body = str_replace($chunk_name, $chunk_value, $body); } #.............................................................................. # replace code_block tags with field values for ( $count=1; $count<=7; $count++ ) { $code_block_field = 'code_block' . $count; $code_block_tag = '{{' . $code_block_field . '}}'; $code_block_value = wire(pages)->get("$page_id")->$code_block_field; # now parse code block value for snippet tags # [!snippet_name!] # [!s_form_get_captcha!] foreach ( $snippet_array as $snippet_tag => $snippet_include_file ) { if ( strpos($code_block_value, $snippet_tag) !== false ) { $snippet_value = include("$snippet_include_file"); $code_block_value = str_replace($snippet_tag, $snippet_value, $code_block_value); } } $body = str_replace($code_block_tag, $code_block_value, $body); } return($body); } ################################################################################################### The Writer Table I use the writer_id field as a popup, to pull in an id from a data table of long term writers. When an article page is displayed, code grabs the id and pulls in the writer info, including a photo, attribution and Javascript encoded email address. In MODX, I had to use a custom table. In PW, I simply created a template field set called ‘writer_page_structure_permanent.’ I use a ‘static_author” and “static_author_attribution” field for those times when an author is a one-off writer. My code tests for a writer dropdown ID for ‘Non-Registered’ writer, and if the static fields have something, then that data is displayed. Template Structure Here are some screen shots of my PW template structure, which essentially replicated my previous MODX structure: Templates: List Page Structure Permanent: Article Page Structure Permanent: The Migration Script One of the challenges I faced with my script to migrate the data was the assignment of the correct parent of each article. Luckily, I wanted to keep the exact structure of the section and article tree and the urls. Since I didn’t have tens of thousands of articles, I decided to create an associate array of the sections and articles under the first level of the home page (i.e. starting at level 2), and then use that sorted list to create the ProcessWire parents before each lower level of section or article. I built the script dynamically, testing as I went, so I wouldn’t say that the script is fit for any and all MODX situations. It’s heavily tailored to my installation, and is missing a few elements that I missed until after I had finished with it (thus causing me to fix some things by hand). URL Replacement I had to parse through each article, in both the body, summary and subtitle, to make sure that any internally pointing MODX urls were replaced with the full url. MODX Evo uses the syntax [~ID~] in the “<a href...” tag to dynamically create the full page url at run time. I had to create a routine to replace the ID tags with page urls, e.g. “/columns/some_article_name”. Image Migration I first took the lazy way out and thought that I could simply move the “/assets/” folder from the MODX installation over to the new account. However, when I opened a PW page in edit mode, the links to the /assets/... images were there, but the images weren’t attached to the page, and thus, in edit mode, the image didn’t now show up in the edit box. I therefore added a routine to copy the images to each page. TinyMCE Code Breaks I found that TinyMCE kept trashing my various CSS codes that came over from MODX. I tried adding various tags to the body field’s “valid_elements” field under Input / TinyMCE, but finally just changed valid_elements to: +*[*] It’s a bit radical, I suppose, but my editors are fully trusted. After that, my migrated data was fine. Post Migration Data Checks After I migrated the data for the umpteenth time, in order to get it right, I still needed to do a variety of clean up tasks. I found the Selector Test module by Niklas Lakanen very useful (Thanks, Niklas!), and used it to run checks like: body*=src\=\"{~root_url}assets (which looked for left over links to /assets/ which came from MODX) I also queried the MODX and PW tables directly, using SQLYog, a Windows MySQL client. I ran a script that compared the results of a find command (find . -type f -printf "%f\n") under the MODX assets folder to the files under the PW site/assets/files folder. I found about 70 files that were not copied, some because they were in template files, which my script didn’t parse, and some because the filenames were problematic, like files with spaces, etc. The script took into account the PW code that changes uploaded file names. To do that, I copied the PW “validate_filename” function into my script. For all my checking, I still forgot things, like parsing the subtitle or summary fields for hrefs, which I then had to go and do by hand (since there were very few records like that). I also created a few redirect aliases by hand, instead of trying to handle them via the script. All in all, this migration confirmed once again that website migrations are a Bear. Ugh. I’d rather not do them. Link to Script Content Here’s the link to the script. Note that it didn’t catch everything, and it was heavily tailored to my design. Also note that I’ve removed some of the private data, like writer’s names, etc. sj_modx_pw_migrate_script.php That’s my case study. I hope it may be useful to another “MODX Refugee”. Peter Falkenberg Brown

Happy New Year everyone! For a large website project, images are all separate pages that contain a bunch of data, similar to image pages on Wikimedia Commons. When you want to add an image to another page, you have to load them from the Wikimedia-like page. This all works as expected. I also enable "Link to larger version". However, when someone clicks the image, instead of just showing a larger version of the same picture, I want the user to be shown the page with all the extra data, including the name of the creator and the licence under which the picture is available. Now, I think this can be done using regular expressions, but I cannot seem to get it done. I have created a function to pass $page->body through that then searches for HREF-attributes for pictures (stored in assets). What I want is to have the "larger version"-link be replaced by a link to the picture page. I cannot wrap my head around it, however. Is there a kind soul who can help me out? Simply put, I want the function to search through $page->body, when it finds something like: '/href="\/cms\/site\/assets\/files\/(\w+)\/(\w+).(\w+)"/i' I want it to replace that with a link to the picture page, for example 'href="example-page/target/"'. Any tips?

And I thought I left the hard ones to you.

Yeah that's what I also thought having it only for unpublished pages or also just certain templates. But first wanted to know if it's possible at all to autosave and how. There maybe also a way to save the edits not to the page but to a file and load it on demand after a loss. Im not too keen creating new pages for it. Also I think certain fields like files will not work this way. Speaking of drafts and live version that's something still missing in pw and I would have that on top priority. But Im not in charge of it and it's on the roadmap, though got delayed by a lot. I'm waiting for it since the beginning of using pw two half years ago. ;p Though Im really wondering if with the flexibility pw offers how to use pages and combinations of fields and hooks if a draft system really works out well... if you know what I mean... seeing also things like 'simple' clone feature is not working in all cases. No offend intended, I know Ryan is doing all he can and doing a hell of a job, but he's still "alone" on those stuff.

Its a good start and is showing that this part of it works and with various fields. It does need to be mixed with some sort of draft/versioning system, I agree, to become a full solution, but that also requires some fairly heft complications: To start with, if you lose connection or something, when you return to the page you need to be offered the choice of the draft version or the published live version. This probably means adding an extra link in the page list actions to open a draft (only shown if it exists) If you are looking at the draft version, then you need to have the option of saving the draft as a draft, or publishing, which would overwrite the live version.

I know Pete. Exactly, but I didn't ask for it and will not use it cause I can hit save.

The module may need a Pages::deleted hook: public function init() { $this->pages->addHookAfter('deleted', $this, 'hookPageDeleted'); } public function hookPageDeleted($event) { $page = $event->arguments(0); $this->db->query("DELETE FROM " . self::TABLE_NAME . " WHERE pages_id=" . (int) $page->id); }

Definitely check out version control for text fields if you haven't already. This module is so good, that it's rare I wish for anything else. That's not to say that there isn't more to be done with regards to core version control, but Teppo's module covers the most common version control needs beautifully.

To check category permissions I need permissions set by template access for each category? DIfferent templates for the categories? Yes, though I used that only to keep the example really simple. Your actual needs may demand something more. For instance, if you wanted to define the roles that could access, with each category page, then you might create a new "custom_roles" Page reference field that selects from pages in /processwire/access/roles/. Then add that field to your "category" template, and edit your categories to select the roles. Then you could modify the previous example to be something like below, that adds a viewable() hook to category pages as well. /site/templates/admin.php <?php wire()->addHookAfter('Page::viewable', function($event) { // if it was already determined page isn't viewable, exit now if(!$event->return) return; $page = $event->object; $user = wire('user'); if($page->template == 'category') { $found = false; // check if user has any of the roles selected for category foreach($page->custom_roles as $role) { if($user->roles->has($role)) { // user has the role, so this page is viewable $found = true; break; } } // if no matching roles found, page is not viewable if(!$found) $event->return = false; } else if($page->category) { // if category isn't viewable, we'll say this page isn't viewable either if(!$page->category->viewable()) $event->return = false; } }); // the rest of admin.php ...

Since ProcessWire doesn't generate markup for you, you'd have to do this from the API side. Here's a simple example where you have an email subscription form and you accept an email address and store it in the 'title' field of a new page. <?php $showForm = true; $email = $sanitizer->email($input->post->email); if($email) { // parent where we will store our new page $parent = $pages->get("/subscriptions/"); if($parent->child("title=" . $sanitizer->selectorValue($email)) { // this checks if we already have this email echo "<p>You are already subscribed!</p>"; } else { // create a new 'subscription' page $subscription = new Page(); $subscription->parent = $parent; $subscription->template = 'subscription'; $subscription->title = $email; $subscription->save(); $showForm = false; echo "<p>Thank you! You have been subscribed.</p>"; } } if($showForm) echo " <form action='./' method='post'> <label for='email'>Enter your email address</label> <input type='email' name='email' id='email' /> <input type='submit' name='subscribe' value='Subscribe' /> </form> "; There are also some tools that can automate this process to some extend, like FormBuilder, and the FormTemplateProcessor (proof of concept), among others. But the best way to get exactly what you want is to use the API.

Dear Matthew, Hey, those Biblical names are easy to mix up: Peter, David, Matthew, Lazarus... Fancybox Lightboxes on Front end Images: To all, here's another example: I just parsed through an admin page, to determine what's needed on the front end to use the Fancybox lightboxes on an href to an image, and came up with this: <link type='text/css' href='/wire/modules/Jquery/JqueryFancybox/JqueryFancybox.css?v=126' rel='stylesheet' /> <script type='text/javascript' src='/wire/modules/Jquery/JqueryCore/JqueryCore.js?v=183'></script> <script type='text/javascript' src='/wire/modules/Jquery/JqueryFancybox/JqueryFancybox.js?v=126'></script> <script type='text/javascript' src='/wire/modules/Inputfield/InputfieldImage/InputfieldImage.js?v=100'></script> <!-- For the Fancybox to work, the hrefs that link to images need this class: <a class='InputfieldFileLink' href='xyz.jpg'> --> In the Significato Journal, we use a lot of images in the articles, and I'd like to start using popups to larger versions. PW has that very fine function, when you add an image to a page (in TinyMCE), to automatically scale a smaller image down, and it has a check box if you want to link to the larger image. I like that a lot. But... by default, it doesn't have a checkbox for target blank, and it doesn't have a dialogue box to use the Fancybox popup. (Unless I missed something.) So, on this article for example: http://significatojournal.com/help-the-world/freedom-human-rights/help-to-end-the-unbearable-evil-of-modern-slavery/ I created a sidebar with images, linking to larger versions. Once I added the above Fancybox css and js files AND manually added the string class='InputfieldFileLink' to the first image in the sidebar, (via the HTML code button in the body text editor), the first image used the Fancybox popup! Zowie! I love it. (I haven't edited the other images yet.) Yes: I read the comments on another post about not using the default JQuery files, so I understand that risk. Maybe I'll copy them to my site dir. My questions now are: a) WISHLIST: it would be really great to add a dialogue box on the image insert, to use the Fancybox module, and b) does anyone have any clever code ideas to parse through the body text and edit the <a hrefs> that have images with the above class string? I don't want to add that class to every href in the body text. I suppose I could use a preg_match to grab every <a ...> and then check for a '.jpg', '.png', '.gif', and then add the class to that string. Just kicking ideas around. Thanks! Peter

Hi Soma Happy New Year! Okay, it is now saving, but on my limited test it saved the two text input fields on my page but not the CKeditor (inline). I will do some more tests tomorrow sometime Night!

$parent = $page->parent; $current = $page->id; $overviewchildren = $parent->children("id!=$current, limit=4"); Or maybe $overviewchildren = $page>siblings("id!=$page, limit=4"); Edit: oh and welcome!

I have the same problem as Rjay: Fatal error: Can not call constructor site/modules/FieldtypeEvents/EventArray.php on line 14. Hope somebody can help with this issue, tnx

This could be down to the IP address of your connection. The ProcessWire config variable 'sessionFingerprint' ensures consistency between IP address and user agent of the session information. This helps to prevent "session fixation" - whereby malicious users could potentially use your session cookie information to impersonate you and gain unauthorised access to the site. To determine if this is the cause, try changing sessionFingerprint to false in your site's config.php file, and carry out your VPN connection test again as you described.

This is pretty much how I'd solve this, still no need for any core changes or additions Create new template called "symlink", add page type field "symlink" with value limited to single Page (use PageListSelect as input field type) and then in template file do something like this: <?php if ($page->symlink instanceof Page && $page->symlink !== $page) echo $page->symlink->render(); else throw new Wire404Exception(); Now you can add as many symlinks you wish and easily choose which page each is tied to. Don't forget to add canonical tags to let robots know which version of this page is the "original" one, though, or you'll have serious SEO issues.

I was incredibly intrigued when I found PW two days ago! A lighter-weight Drupal, enabling a much more agile way of working, is exactly what I have desparately needed for the few side projects I'm doing in my limited time besides my developer work at Uppsala University. My first PW site ever produced is now up (although somewhat a work in progress): A humble little site for our humble little firm: RIL Partner ABAttaching a screenshot as well, for your convenience.

That $p->snapshot() stuff is supercool! It would be trivial to create "timeback machine" for frontend...

Hi, I just translated the two english language files in /wire/modules/Inputfield/InputfieldTinyMCE/tinymce-3.5.8/plugins/codemagic/langs/ and changed the names to fi_dlg.js and fi.js. Those files are attached here renamed with .txt. I think it was like when using the language code fi codemagic supposed to find files called fi.js and fi_dlg.js. fi_dlg.js.txt fi.js.txt

I've been experimenting with an addition to VersionControlForTextFields. Let's say we have a Page with some revision data. $soup = wire('pages')->get('/specials/soup/'); echo "<br/>Current soup: " . $soup->title; //Doing this gives Page a new method wire('modules')->get('ProcessRevisionHistoryForTextFields'); //What kind of soup were we serving last week? $soup->snapshot('-1 week'); echo "<br/>Old soup: " . $soup->title; After the call to snapshot() any version controlled fields of the Page will have the values they had at the time specified. The changes to make this work are made to the ProcessRevisionHistoryForTextFields.module file. Add one line to the init() public function init() { parent::init(); $this->addHook('Page::snapshot', $this, 'pagesnapshot'); //add this line } Add these: public function pagesnapshot($event) { $page = $event->data['object']; if ($data = $this->snapshot($page, $event->arguments(0))) foreach($data as $k=>$v) $page->$k = $v; } public function snapshot($page, $time='') { $id = $page->id; if (!$id) throw new WireException("Missing required param id"); if (!is_integer($time)) $time = strtotime($time); if (empty($time)) $time = time(); // how many of this page's fields do we keep history for? (configured for each template) $ct = count($page->template->versionControlFields); // find values $sql = " SELECT m.fields_id, m.pages_id, d.* FROM " . self::TABLE_NAME . " AS m, " . self::DATA_TABLE_NAME . " AS d WHERE m.pages_id = $id AND d." . self::TABLE_NAME . "_id = m.id AND m.timestamp <= FROM_UNIXTIME($time) ORDER BY m.timestamp DESC "; $result = $this->db->query($sql); // generate data (associative array) $data = array(); if ($result->num_rows) { while ($row = mysqli_fetch_assoc($result)) { $field = $this->fields->get($row['fields_id']); if (!array_key_exists($field->name, $data)) $data[$field->name] = $row['data']; if (count($data) >= $ct) break; } } return $data; }

Am I seeing double? Enjoy ur vacation!

@ryan: thanks for the support via PM. I haven't done any further work on that because I'm on vacation and only sometimes online via mobile. @ryan: thanks for the support via PM. I haven't done any further work on that because I'm on vacation and only sometimes online via mobile.

I don't think you can use the user pages to use access control for front end. User pages are special pages and I think not meant to be used as viewable pages on the front end anyway. Since you're speaking of front end users, you just get the users the members "can view" according to some "virtual" rules and use API to list their profiles using a dedicated page/template. I.e. /users/profile/xyz and use urlSegments to control the listing. On front end you're free to check for access and do what is needed to show or hide stuff. You member role would also be just a guest role with only view access since they won't need or have admin access. So it's up to you to control that in your templates. Just a dummy example. if($user->hasRole("member")) { $members = $users->find("roles=member"); .... } else { echo "Sorry, you're not allowed to view."; }

Many thanks for the info pwFoo! I really should go about test this myself asap, but have been busy developing my first PW site I'm not sure the .htaccess file should be a too big problem. For rilpartner.se, .for example, we are successfully ourselves using nginx, which has its own URL handling, and I could easily add the single rewrite rule needed to get it to work ... and I from what I've hear, hhvm should be able to run with nginx, using fastCGI / fasterCGI. Will also report if I get the time to test this out more!

I don't know if this will be any good for your situation or not - but I recently forked this module for a specific purpose. The functionality I used it for was to allow a whole Flickr photoset to be added to an image field, just by the URL. A text box is appended to the image list, where the URL of a photoset can be entered. When clicking Save, the module will retrieve the photos from the set, and add them to the field. The PW description field will be populated from the photo's title. Find it here: InputfieldFlickrset. It's rather simple, but you may find it useful to use or to customise as you need.

I agree with what you've said. In fact, after reading this insanely exhaustive write-up about password reset techniques, http://www.troyhunt.com/2012/05/everything-you-ever-wanted-to-know.html, I think it might be best to send the user a reset link that's only active for a few hours, and have them pick a new password rather than emailing them a temporary one.

I just downloaded this module and wanted to try it out. However, when I try to edit the page with the assigned template/field I am getting this error. Fatal error: Can not call constructor site/modules/FieldtypeEvents/EventArray.php on line 14 It is probably user error, but I cannot figure it out.

Hi, doesn't see hhvm before but looks interesting... htaccess and php.ini support seems missing at the moment, but is planned. I'll read some more about it and maybe do some (simple) tests with it... *update* Simple installation (CentOS 6 yum repo) and a simple php test works fine, but to run PW, Drupal ... I think the htaccess file have to be converted, because apache, htacess, php.ini isn't supported by hhvm yet... But seems to be work in progress.

Congratulations, you found a diamond in a cms heap. You will find that out your self the more you work with it. You can modify it in any way you want with the API of processwire. You can use any css framework to make responsive websites, like cube, foundation, etc. PW comes with tinymce. You can already do all the things you need with that. You can activate extra functions in tinymce inside the PW configuration like: fontsize, fonttype, fontcolor, background color, charmap, etc. etc But using css for that is preferred to keep your design clean and portable. Study the API of processwire, you are going to need that first. Then learn basic php things like foreach, do-while that you are going to need together with the API. The learning curve is only to become familiar with how pw works. PW works different from other cms'es because pw has no cms rules, no cms walls. PW adapts to the designer and coder, not the other way around like almost all other cms'es out there. Go through the PW tutorials until you get that "aha that's how pw works" moment and then you can go on for your self, you don't want to stop anymore also because pw is that addictive http://processwire.com/talk/topic/4173-grouped-forum-posts-links-articles-tutorials-code-snippets/

(Note: Teppo typed faster than me, so I am repeating some bits here) HI Adonis And Happy New Year back at you! Okay, let me answer the bits I can. First, template. Basically, ProcessWire does not have a templating system of any sort, so you do not have to learn anything. In the /site/templates/ directory, anything with a php extension is regarded as a template. So, if you create a file called myfile.php in that directory, you can then go to Setup > Templates in the admin and add it as a template. (Click New Template and you will see it listed.) You can then create a new page using that template. Obviously, as it is has no mark up in it, nothing will actually get displayed, but it is a start. To use it more fully, you just need to write HTML in it (as you would a stand alone html page) and then add a bit of processwire php markup to output the fields. For instance, the Title field would have automatically been added when you added the new template in the admin so to out put it you could put in your html, for instance: <h1><?php echo $page->title; ?></h1> The main thing is to understand the difference between a template and a template file Template: A processwire object that associates a group of fields together Template File: The file where you put any markup and/or logic for outputting those same fields. You should go and do this over the top tutorial and it will all become clear! http://wiki.processwire.com/index.php/Basic_Website_Tutorial CK Editor Since this is an add-on module, you can do pretty much as you like with it. However, there are a couple of plugins added to it (for images and links) that are customised for processwire that need to be left intact. PHP Knowledge I have very little php knowledge, but PW has proved a really good way of learning the basics! So my knowledge has increased using it. Make sure you learn about the basics of using echo and how to do a foreach loop. (plenty of examples in this very forum) And then read the API, especially the cheat sheet. That will do you for now - go play!

Hello there and welcome to the forum! A few quick answers and/or comments: 1. Awesome. Feel free to contribute any time you want 2. ProcessWire doesn't produce markup per se, so you can create whatever markup you wish and, for an example, use any layout / CSS framework you prefer. You simply create your templates as pure HTML (though within PHP files) and then ask ProcessWire to pull in content from current page to whatever location you want, with simple PHP syntax like <?php echo $page->body ?>. 3. CKEditor module is very configurable. Install it, see field settings and you'll find out just how far it can go. If you need any help, don't hesitate to ask. Personally I prefer to control stuff like font colors via style sheets so the site doesn't end up looking like something a drunken unicorn left behind, but I get that this might in some instances be necessary. 4. Sounds reasonable. No need to start from the deep end. 5. Most likely no. Again, you won't need to start with complex stuff, simply echoing out content takes you long way already. I wrote a blog post some time ago comparing PHP templating to Twig (and explaining the basics), so you might want to check that one out here if you're more familiar with other templating engines. 6. Some people prefer tutorials, others start with the documentation, personally I started learning with a real project (by the end of which I had pretty much grasped all the basic concepts of PW.) It's your choice really, but whatever route you take there's a lot of material available already. Again; ask and you shall receive (pointers for where to look, that is)

Basically, since Processwire does not have any theming engine, the trick is to just do what you like and add the ProcessWire API to output your data ... pages, that is. So, as Martijn says, just install PW, chuck out all the bits you don't need (fields, templates and so on), and then just think about it like writing a bit of HTML. In fact, just write some HTML. You can use any framework you like - Bootstrap, Foundation, Adobe Edge, Frontpage 97 ...... You can use any Javascript/Jquery functionality you like. You can use any anything you like. Since PW does not have anything in the front end, you cannot conflict with anything unless you create the conflict yourself True freedom! That would be "Free as in ProcessWire"

Just a quick heads-up: like you've already pointed out above yourself, you really shouldn't do this, as it seems to open a ton of new security issues. There are probably even better ways to do it, but why don't you at least create a new page (or Process module) and use PW API to handle the saving? It should be pretty straightforward, i.e. something like this: <?php if ($user->hasRole('admin')) { $target_page_id = (int) $input->get->page; if ($target_page_id) { $target_page = $pages->get($target_page_id); if ($target_page->id) { if ($user->hasPermission('page-edit', $target_page)) { $content = $input->post->content; $target_page->of(false); $target_page->body = $content; $target_page->save(); } else throw new WireException("Permission issue"); } else throw new WireException("Page not found"); } else throw new WireException("Missing page ID"); } else throw new WireException("Missing role"); Generally speaking, whenever you find yourself fetching (or, even worse, storing) data to/from native PW database tables, it's likely that you're doing something wrong (Exceptions above exist mostly to demonstrate couple of things you'll want to take care of if you do this at template level. Process modules have their own method of handling permissions, which makes that part less complex. Note that this was written in browser and I've no idea if that code works straight away, but I hope you'll get the point..)

@saml, what I usually do is: 01. Instal ProcessWire. 02. Delete unwanted pages. 03. Leave fields as they are. 04. Leave templates as they are. 05. Rename Fields & Templates when needed. 06. You'll see that you'll reuse every single template & field.