Leaderboard

Ok, let's make it really simple for people using chrome to do this If you are using chrome do this to have PW search with google on the omnibox by simply typing "pw [spacebar]" 1. right click on the omnibox and chose "Edit Search Engines" 2. scroll down until you find these input fields 3. Fill them as in the image: third field should be https://www.google.com/search?q=site:processwire.com%2Ftalk++-site:processwire.com%2Ftalk%2Fmembers%2F+-site:processwire.com%2Ftalk%2Fuser%2F+%s This is the equivalent to this search in Google: "site:processwire.com/talk -site:processwire.com/talk/members/ -site:processwire.com/talk/user/ %s" where %s is the query 4. type "pw [spacebar] Edit Search Engines" and see if this thread appears in first PS: I'm sure there is an equivalent way to do this in other browsers, but I'm not going to look for that now. Edit: simplified the url

Ahem....she

I could also post all my PW bookmarks but that would probably break the forums! So, I leave you with my all time favourite treasure trove (OK, so they are not part of the forums but everything hinges on this) The PW API docs: http://processwire.com/api/ (especially $page, $pages, selectors and the cheatsheet)... Sorry if I am repeating myself!

ProcessWire has language alternate fields, which basically do what you describe out of the box. Unlike multi-language fields, language alternate fields can also be used with image fields.

You should practice what you preach... How comes everytime I look at user in forum you're searching the forum?

so "processwire.com soma is best" is simpler than "pw diogo is best"? hm...

I cannot tell what threads or posts I best like, it would end up in a list greater than 20 or more. But I can share a little trick I use to quickly find some of them via google: site:processwire.com/talk (one or more names of users that took part of the conversation) AND ("wordphrase that was in a post there, at best a long one", but need to exact!) OR (a very individual word, if there was any) OR (common keywords) So when I need to know how to setup an apache server for best caching / compression I search for buttock (top, not buttock!) with or without willyc: search->buttock Yesterday gebeer needs to know from where a page->render() function was called. My remembered keyword was "caller", and I know that it isn't talked very often about that: search->caller A search for younger + foxes do result in a single thread, where as the terms old + foxes is a little bit more common

https://processwire.com/talk/topic/4173-grouped-forum-posts-links-articles-tutorials-code-snippets/

Pageimage Naming Scheme I have created a module that extends the naming scheme for images. It reflects more options within the filename. An example is here: http://images.pw.nogajski.de/new-naming-convention/ The module is on github (zip)- additionally you need PW version 2.4.2 or newer (while writing this, the latest dev version from today) The module is in alpha state, so yet do not use in production sites. To install and start using it works very smooth: It doesn't force to recreate your already cached images, only uses the extended naming scheme when need to create new image variations. Also recognizes both naming schemes when collecting imageVariations. Recognizes PageImageManipulator-files too per update to 0.1.3. If you want to uninstall it, you can run a cleaning script from the configuration screen that removes imagevariations to avoid orphaned files when switching back to the core naming scheme. Running the cleaning script as simulation is supported too. --- There are a new thing to mention: You can send a new option together with your images $options array: "forcenew" => true! This results in recreating these single variation of the image, without dropping all other variations. Now that you can have a lot more variations per image, this should be the preffered way to drop / recreate cached image versions. Questions, suggestions are welcome.

I finally got to a somewhat finished state of a low-budget project I've been working on besides my main job at the university. Enjoy it at shallahotel.com In short, Shalla Hotel is a small hotel in Shashemene, near Awasa 250 km south of Addis Abeba, Ethiopia. The aim of the website for now is to just provide a simple presentation page for the Hotel. The website will be improved continuously from now on.

For a recent (low-budget) ... would instead become: echo ul( li( 'Home' ) . li_foreach_page( $page->children ) ); I have collected the code I'm regularly re-using so far in a github repo: https://github.com/samuell/pwutils'>github.com/samuell/pwutils I'm sure many of you are doing things like this already, but I was just thinking that this kind of thing could be a good idea help each other improve upon. I was thinking that having a common such micro-library with all the common cases covered to speed things up, should be a productivity booster that we all can benefit from. What do you guys think? Maybe there is something like this already, that I just missed?

This reminds me of a "helper" from the diem cms/cmf that was pretty interesting back in the day. The code is still available as a standalone module on github but no longer maintained. Another similar but different tool is "haml" from ruby, which there are some php ports of. It would be interesting to try these out in the context of pw.

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

saml, Nice work! I could see using this for some of the more simplistic/repetitive tasks. That said, it could perhaps be a rabbit hole that goes to deep if you try to account for all the scenarios that might be thrown at it. Also: can we hide this from the noobs?

updated to version 0.1.3 fixed a bug with ignoring outputFormat when send as $options with method pimLoad found by @titanium added support for php versions with buggy GD-lib for sharpening and unsharpMask added support for the coming module PageimageNamingScheme into pimVariations()

Thank you, Horst, for this great module. Bug report: the ratio isn't calculated correctly. Two lines containing: 'ratio' => floatval(($info[0]>=$info[1] ? $info[0]/$info[1] : $info[1]/$info[2])) have to be: 'ratio' => floatval(($info[0]>=$info[1] ? $info[0]/$info[1] : $info[1]/$info[0]))

If you just want to add a different colour to the module itself: https://processwire.com/talk/topic/4650-new-processwire-admin-theme-on-dev-branch/?p=54479 If you want to completely change the theme: Key word is 'module'. The new admin theme is a module. You should be able to copy the module, change its name (including the class name), install it as a normal module (/site/modules/) - and change the CSS (even HTML) as you wish

To make this with save buttons you'd have to trick a bit. Here's a example POC module that adds a "Save minor" save button and increments a integer field on page. That field can be hidden, not visible on edit. https://gist.github.com/somatonic/11206761

Hi There is also an api cheatsheet: https://processwire.com/talk/topic/3757-cheatsheet-e-book-for-offline-use/ Made by Soma http://cheatsheet.processwire.com/ Converted to pdf by Vineet Sawant https://dl.dropboxusercontent.com/u/86357215/Cheatsheet_1.1_v0.3.pdf Converted to docx by k07n https://www.dropbox.com/s/fyt2z72vkwdm358/Cheatsheet.docx

Then all you need to do is retrain two sets of users; those who think all their work is of minor importance and those who think all their work is of major importance. ;-)

Oh wow, where to start?? I started bookmarking threads and then I gave up very quickly because the whole forum is a treasure trove Like Kongondo, my one bookmarked and favorite page that I return to again and again is http://processwire.com/api/ I also spend a lot of time in the FAQs, API & Templates, and the Modules/Plugins sections of the forum

For Custom Front-End Login System: https://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/ I still go there to revisit code whenever I am working on custom login.

Max, glad you got it sorted. Just wanted to point out that this head.inc/footer.inc being the PW way is a common misconception . That is not the PW way; there is no PW way . This is a source of joy for some (the-have-my-cake-and-eat-it-too crowd) and a source of frustration/confusion for others, especially those used to a CMS telling them how to do things (Joomla, WordPress, anyone?). In PW, different people use different approaches according to preference, practicality, etc. Hey, if you wanted, you could even have one massive HTML file with all the markup you need and keep on duplicating that across different template files with only slight modifications. Not very practical (and a lot of unnecessary work on your part) but it would work. The Blog Profile, the Skyscrapers Profile and the default install are good examples of various approaches. But the definitive post on different approaches are in this classic thread.

This thread is used as a place to collect: 1. links to posts in the forum answering (repeating) newbie questions 2. links to posts in the forum and elsewhere on the net giving good insight in processwire 3. links to good articles about processwire 4. links to good tutorials posted in the forum 5. links to movie clips 6. links to posts in the forum talking about modules 7. code snippets or links to code snippets 8. Usefull Helpfiles Many good posts that answers (repeating) newbie questions or give good insight in the how and why of processwire, links to tutorial posts, (also on the net), movie clips, clarifying articles and code snippets are spread over the forum. PM me if you know a link. About this kick start see this post: http://processwire.com/talk/topic/4143-wordpress-dominates-19-of-the-web/page-2#entry40910 This is a work in progress, it takes time to make it grow bigger and better. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = STARTING NEWBIES AND DESIGNERS Link1: Starting and growing with processwire. https://processwire.com/talk/topic/3990-another-simple-photo-gallery-tutorial/page-4#entry61069 Link2: I am basically a designer with some programming skills. My question is this: Can I go ahead to use processwire for this even though i am still learning php. http://processwire.com/talk/topic/3954-starting-out-with-website-intranet-and-internet/ Link3: Feeling overwhelmed http://processwire.com/talk/topic/3215-newbie-overwhelmed/ Link4: Questions concerning PW and it's capabilities http://processwire.com/talk/topic/1557-questions-concerning-pw-and-its-capabilities/ NEWBIES FIRST CODING QUESTIONS link1: Using a default install, I'm stepping through the tutorials, templates, etc and trying to understand the basic concepts behind processwire and at this point in time "head.inc" & "foot.inc". http://processwire.com/talk/topic/3421-footinc/ Link2: I am puzzled why some html tags are starting in head.inc but don't end in head.inc Instead they are ended in foot.inc http://processwire.com/talk/topic/3388-question-about-headinc-and-footerinc/ Link3: Question about not using ?> in processwire http://processwire.com/talk/topic/3370-question-about-missing/ Link4: After you installed processwire, it comes with a default website. What is the best way to fill in your own website ? How do you replace the default processwire website with your own ? http://processwire.com/talk/topic/3379-how-to-fill-in-your-own-website/ Link5:How much extra work/time will I have to put in, as far as understanding and writing php and getting the hang of the PW system, just to be able to create the same responsive designs I would make in HTML/CSS/Javascrip, while also achieving the easiest type of content editing capabilities (in line with what you can get with a CushyCMS type product)? http://processwire.com/talk/topic/3961-new-to-cms/ Link6: I realize what I am confused about was really something quite basic, such as where are the snippets of php code go beside on templates? Can they go on a page as the value of body field for example? http://processwire.com/talk/topic/3383-back-to-basic/ Link7: I'm stuck in something that should be very simple. http://processwire.com/talk/topic/3720-my-first-doubt-using-pw/ Link8: Several questions before I can start. http://processwire.com/talk/topic/3589-several-questions-before-i-can-start/ PROCESSWIRE CMS INSIGHTS Link1: Reading this thread makes you understand processwire real quick. http://processwire.com/talk/topic/5667-help-a-noob-get-started/ Link2: Very good case study from RayDale giving good insight in processwire http://processwire.c...a-a-case-study/ Link3: Symphony or Processwire ? Another good insight. http://getsymphony.com/discuss/thread/79645/ ARTICLES Link1: Why he choses processwire over modx http://www.mademyday.de/why-i-chose-processwire-over-modx.html COMING FROM MODX ? Link1: You've been using MODX but now you've found ProcessWire. It’s totally amazed you and you can’t wait to get started. But…you are wondering where everything is. If this is you, read on… http://processwire.c...ning-from-modx/ Link2: A MODX refugee: questions on features of ProcessWire http://processwire.com/talk/topic/3111-a-modx-refugee-questions-on-features-of-processwire/ Link3: Code comparison between modx and processwire. http://processwire.com/talk/topic/2850-processwire-for-designers/page-2#entry30349 COMING FROM DRUPAL ? Link1: How to move your site from Drupal to ProcessWire. http://processwire.c...ndpost__p__8988 PAGES IN PROCESSWIRE Link1: Understanding pages in processwire http://processwire.com/talk/topic/5667-help-a-noob-get-started/page-2#entry55820 Link2: More about the function of pages in processwire http://processwire.c...fused-by-pages/ Link3: How to hide Pages from the Topnavi via Adminmenu http://processwire.com/talk/topic/2037-how-to-hide-pages-from-the-topnavi-via-adminmenu/ TEMPLATES IN PROCESSWIRE Link1: A good post with code examples to start a template http://processwire.com/talk/topic/43-template-tutorial/ Link2: Template design a better route http://processwire.com/talk/topic/2782-template-design-better-route/ Link3: A different way of using templates http://processwire.com/talk/topic/740-a-different-way-of-using-templates-delegate-approach/ FRONT-END / BACK-END Link1: ProcessWire Setup and front-end editing made easy http://processwire.com/talk/topic/2382-processwire-setup-and-front-end-editing-made-easy/ Link2: Creating a front-end admin http://processwire.com/talk/topic/2937-creating-a-front-end-admin/ Link3: How would I build functionality and write information from the front-end to the back-end? http://processwire.com/talk/topic/2174-writing-from-front-end-to-back-end/ Link4: Is it possible to create a custom login page like a template ? http://processwire.com/talk/topic/107-custom-login/ Link5: A "members-only" section in the front-end. Integrating a member / visitor login form http://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/ Link6: Trouble deleting pages from the front-end. http://processwire.com/talk/topic/2290-trouble-deleting-pages-from-the-frontend/ MODULE Front-end Edit. It turns the content of $page->body into a clickable area and gives the ability to frontend edit the content via tinyMCE http://processwire.com/talk/topic/3210-module-frontend-edit https://github.com/Luis85/PageInlineEdit/ MODULE Fredi, friendly frontend editing. http://processwire.com/talk/topic/3265-fredi-friendly-frontend-editing/?hl=fredi http://modules.processwire.com/modules/fredi/ MODULE Admin-bar Provides easy front-end admin bar for editing page content in ProcessWire 2.1+. http://processwire.com/talk/topic/44-is-there-way-to-get-information-about-current-user-in-templates/ http://processwire.com/talk/topic/50-adminbar/ http://modules.processwire.com/modules/admin-bar/ MULTI LANGUAGE WEBSITE IN PROCESSWIRE Link1: Multi-language website page names / URLs http://processwire.com/talk/topic/2979-multi-language-page-names-urls/ Link2: API http://processwire.com/api/multi-language-support/multi-language-urls/ Link3: The name of the default language can't be changed in Pw, but the title. http://processwire.com/talk/topic/4145-recoverable-fatal-error/#entry40611 ADD NEW USER TO YOUR WEBSITE AND PASSWORD RESET Link1: Integrating a member / visitor login form http://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/?hl=%2Bpassword+%2Breset#entry15894 Module http://processwire.com/talk/topic/2145-module-send-user-credentials/?hl=%2Bpassword+%2Breset BASIC TUTORIALS FOR NEWBIES Link1: Approaches to categorising site content http://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/ CODE SNIPPETS AND FUNCTIONS Link1: Get page id from images object https://processwire.com/talk/topic/6176-get-page-id-from-images-object/ Link2: Function to render Bootstrap 3 carousel markup from ProcessWire images object https://gist.github.com/gebeer/11200288 .HTACCESS EXAMPLES ON YOUR HOSTING SERVER Example1: A working .htaccess file. The issues were that the .htaccess file must exist on the server before installing processwire and that the server did not allow options in the .htaccess file. After fixing that processwire could be installed on the server without any problem. Note that such restrictions might be different on your server that you need to find in the faq of your host. RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?q=$1 [L,QSA,NC] HTML KICKSTARTER Link1: How can i integrate HTML Kickstarter with processwire? http://processwire.com/talk/topic/2731-how-can-i-integrate-html-kickstarter-with-processwire/ MOVIE CLIPS Field dependencies are coming in ProcessWire 2.4. Field dependencies are basically just a way of saying that one field depends on another. It dictates which fields should be shown in a given context. https://www.youtube.com/watch?feature=player_embedded&v=hqLs9YNYKMM HELP FILES Cheatsheet Link1 Cheatsheet 1.1 as pdf file Download: http://processwire.com/talk/index.php?app=core&module=attach&section=attach&attach_id=1299 Link2 Cheatsheet is now a processwire site (great work by Soma) http://cheatsheet.processwire.com/pages/built-in-methods-reference/pages-find-selector/ INTERVIEWS Link1: About the history and coming to be of processwire http://processwire.com/talk/topic/4084-about-ryan-and-processwire-an-interview-with-ryan-cramer/

Hey Alan, thanks for the kind words. If I understand correctly what you're asking (making an album where each image is stored in its own child page along with other metadata), then that is actually simpler than what I've done here since we don't need to "fake" the pages--they already exist. Here's what the gallery-album.php would look like: <? $config->styles->append($config->urls->templates . "scripts/fancybox/jquery.fancybox.css"); $config->styles->append($config->urls->templates . "scripts/fancybox/helpers/jquery.fancybox-thumbs.css?v=1.0.7"); $config->scripts->append($config->urls->templates . "scripts/fancybox/jquery.fancybox.pack.js"); $config->scripts->append($config->urls->templates . "scripts/fancybox/helpers/jquery.fancybox-thumbs.js?v=1.0.7"); // Configure thumbnail width/height & number of photos to display per page $thumbWidth = 150; $thumbHeight = 150; $imagesPerPage = 32; $images = $page->children("limit=$imagesPerPage"); include("./head.inc") ?> <?= $images->renderPager() ?> <div class="upOneLevel"><a href="<?= $page->parent->url ?>">← Albums</a></div> <h2><?= $page->title ?></h2> <div class="album"> <ul class="album-row row"> <? if(count($images) > 0) { foreach($images as $image) { $thumb = $image->images->size($thumbWidth, $thumbHeight); ?> <li class="album-photo darkenOnHover col span3"> <a href="<?= $image->images->url ?>" rel="fancybox-gallery" class="fancybox" title="<?= $image->images->description ?>"> <img src="<?= $thumb->url ?>" alt="<?= $thumb->description ?>" /> <!-- Uncomment this line if you want descriptions under images <p class="album-photoDescription"><?= $image->$images->description ?></p>--> </a> </li> <? } } ?> </ul><!-- /album-row --> </div><!-- /album --> <div class="group"><?= $images->renderPager() ?></div> <script type="text/javascript"> $(document).ready(function() { $(".fancybox").fancybox({ prevEffect : 'elastic', nextEffect : 'elastic', loop : false, mouseWheel: true, helpers : { title : { type: 'outside' }, thumbs : { width : 100, height : 60 } } }); }); </script> <? include("./foot.inc") ?> Where "images" is the name of the image field on your child pages. I haven't tested this yet but it should work. You can then use $image variable anywhere within the loop to access your other metadata fields.EDIT: Just corrected a stupid mistake. This should work now!

Thanks, very nice links! I liked especially the first one, with the css syntax support - Always good to avoid re-inventing the wheel in terms of syntax Would be interesting to see how much of a performance hit there is to the regex parsing involved ... though hopefully that's not anything major. Personally I would probably have "shortcut" functions on the form of a( ), li( ) anyway, which would pass on to any underlying library api. Will keep these links in mind as I continue playing with this.

@Can...looking forward to seeing your custom theme

I like this. I think a nice object oriented implementation in the background combined with pure php functions for the template context would be great I would go as short as possible: <div class="foo"><?= ul( li($pages->find('template=foo,limit=25') ) ) ?></div> <?= ul( li('Home') . li($pages->get('/') ) ?> <?= a($page) ?> // Produces a standard link to a page with href, <?= ul( li( a( img($page->images) ) ) ) ?>

oookay you´re such a genius!! sounds like a plan..will definitely give it a try! Ah @Horst hadn´t had the time to try the image manager myself..what a shame UPDATE: You´re my HERO Kongondo!!

I use a mixture of both - oops! I have come to love concatenating though. Using a text editor with syntax highlighting like ST, I can clearly see what is a string and what is a variable, unlike variables within curly braces within a string; these get the same colour as the string.

uuuuhh... ooopss, silly me I didn't realize it... (but I knew) There's something suspicious with that name.... Sorry bout that @einsteinsboi.

Hello Horst, thank you for that link. Very helpful, indeed. Actually, I found the solution to my problem through a link in that post to Ryan's post here. I can pass my own variable in the options array of $page->render(). On the page that gets rendered I check for the variable. If it is there, I don't include main.php. Love PW

Hi gebeer, don't know if it is what you are looking for: https://processwire.com/talk/topic/3660-what-page-was-the-caller-of-render/ If you get the page, you can ask for its template. So no direct solution here, but a solution.

What I would do, is replace the Save button with two separate buttons: "Save (Major)" and "Save (Minor)". Accent/highlight these as you see fit. The click action of either one would be caught by javascript, where you can then add a hidden field to the page to set the value of major or minor. Then submit the form. The module would hook into the save process to do the actual incrementing of the field value. The action is clear either way. There are no number fields for them to screw up (which they would, somehow) No annoying modal box gets in the way.

You never know for sure. (Maybe in 10 or 20 years, - or later?) Nice! If you are ready with it, you can post it under showcases and / or add an entry in the sites directory.

"protected" means it's well "protected" I never use or used the var_dump to inspect PW vars or objects. It is just too messy and often leads to more confusion or wrong assumptions and ways to retrieve something that there may already a API method for that. Looking at a var dump doesn't tell me that. What I do is think of what I'm dealing with and look in the classes according to see what public methods there are I could use. Pageimages are special objects, containing your image(s) as Pageimage which extends Pagefile. Pagefile can be images or files. I look at wire/core/Pagefile.php Pagefile contains a get() method that allows to get the Page the (single) image object is from. https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/Pagefile.php#L140 So this gets me the page $p = $img->get("page"); equals to without get() $p = $img->page; This doesn't mean there's a object->page, but rather a magic get method mapping the call to a get("page") You can also get the Pageimages from a single Pagefile $pagefiles = $img->pagefiles; That gives all the other images/files from the same field (in case there's any) Pagefiles also has a method to get the page with a public method for example $p = $img->pagefiles->getPage(); https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/Pagefiles.php#L81 So tons of ways and option, and none of it you'll get to know when doing a var_dump.

This is specific to any CMS or software you might run on a server (not just ProcessWire). When it comes to the security of the hosting, I prefer something dedicated (VPS or dedicated) so that you don't have multiple websites (managed by other users) sharing the same file system. When you are dealing with a shared file system, you've got more to consider when it comes to the permissions of files and such. You need to make sure that the permissions settings you've chosen for uploaded files and such is not going to give other accounts the ability to change them. You are also likely sharing MySQL instance with other users in a shared environment as well, so there's that matter of resources being shared. You can certainly secure the shared environment just as well as the dedicated one, but it'll take more work and monitoring. Shared hosting environments also represent a bigger prize to hackers, so that seems to be where they prefer to focus their efforts. I would go with a managed dedicated or managed VPS. For example, I think all the servers available from ServInt are managed (I know this one we're on right now is). One other recommendation would be to isolate your software. Don't run WordPress and ProcessWire from the same account if you don't have to. WordPress is always a target, and if you get broken into that way, then you could create problems for everything else running on the same account (this is not uncommon with WordPress at least).

@marcus...I think a get is better for a single page no need for a find...

I agree that most of these are good timesavers. Some of them already solved by modules, but I agree, that there is no need for too strict safety nets for developers/superusers.

Do not go down that road, it is a dark and miserable path where fellow travelers seek to fill your pages with a contagion of confusion and dismay. Aside from the occasional notion of "oh, this might actually work", you will find yourself subject to the chains of their template systems. At the end of the day, though your site may work, you may cringe at the mere mention of changing anything in it. And it only gets worse as your projects become more involved. (Speaking from experience.) Stay here, it's nice here.

Thanks, yes the forum is full of useful but scattered posts and when I have the time I try to sort them out. Next step could be to put everything in a database with a nice front end.

Just wanted to mention that redirecting to the 404 page is wrong. wire(session)->redirect("/http404", false); Even if this would be correct... on a side note: the redirect to "/http404" without trailing slash would redirect to "/http404/" (with default settings), and further more if the 404 page uses the basic-page template and the requested page too, you'd end up in endless redirect. Back to why using this is wrong: It won't give you a real 404 page with correct header! It will just redirect to a regular page with content. Means this page will get indexed instead for all pages you're doing this. The way to do it is: throw new Wire404Exception(); This will render the 404 page content with correct header and keep you at the url you requested.

Not sure about the limited browser support. I thought back in the days 56k they told better to use progressive. As it give the the feeling that it loads quicker. ( below some info from wikipedia ) These days, we want to give more more control back to CSS. Old lightbox scripts, first load the whole image, then presenting them to the screen with animation. What I see happen now a days ( more & more ) other of lightbox scripts appear. The animation delivered bij CSS & not by Javascript. And images appear on the screen directly. ( after first byte is loaded ) see magnific lightbox for example. Progressive loading is way nicer then. For mobile progressive is ideal. ---- wikipedia compression : There is also an interlaced "Progressive JPEG" format, in which data is compressed in multiple passes of progressively higher detail. This is ideal for large images that will be displayed while downloading over a slow connection, allowing a reasonable preview after receiving only a portion of the data. However, support for Progressive JPEGs is not universal; when Progressive JPEGs are received by programs that do not support them (such as versions of Internet Explorer before Windows 7)[13] the software only displays the image after it has been completely downloaded. --- Interresting read @horst. Still have to think about it. To be continued !

Ay - I here you there brother. It's a coded jungle out there with brackets, curly brackets, comma's, semi columns, double quotes, single quotes, double points, forward slash, backward slash, arrows, white space, etc. etc. And then all that is going to be mixed with php, api, html, apart from css and js.

The current approach makes it possible to share images between Pages - that's nice, but what happens if I delete a Page that contains images reference by a body-field in another Page? I see at least 3 different common image use cases: Inline images belonging exclusively to the body-field where they're used Inline images shared between multiple body-fields Associated images for specific purposes (non-inline use) You can handle number 1 with the current approach, but you can't guarantee the images won't be shared with other pages, hence you can't be sure it's safe to delete a page that contains images - or worse, you may have to delete a certain page, and you will need to first somehow recover the images, place them somewhere else and update you references to those images. You can handle number 2 with the current approach, but it forces you to create dud pages to hold the images. Number 3 is handled perfectly, and that seems to be what this approach was really designed for - basically any inline use-case seems like a bit of an afterthought and the solutions aren't really ideal. I looked at soma's module, but it kind of seems to solve a different set of problems. Ideally, I'd like to have some sort of media manager, not only for images but for audio, video, documents and links to external media, as the same set of problems apply to all of those - in particular, the ability to share and track the usage of all media items. I think this is why most other CMS have a media management component of some sort? The ability to organize a media/image library into categories etc is a nice bonus, but simply being able to manage and use media in a controlled way seems more fundamental to me...

I really prefer to keep images in their own fields, separate from a textarea/TinyMCE field. It's not about any limitations at all. I've just found this to be the most flexible way of managing this over a long period of time. ProcessWire has always been built to what was ultimately most flexible rather than trying to do the same thing as other CMSs. But I do recognize that it's controversial and may seem unfamiliar if one is already used to a different way. I'm not against alternative patterns for this if it helps appeal to more coming from other CMSs, though not at the expense of the current one which I think is the ideal (at least for my needs). So I always try and keep an open mind about it and am open to supporting more options for those that want them in the future.

This is a matter of view, really; textareas hold regular text (even if it's markup) and image / file fields hold images / files (binary data.) It's about separating content by type, even if not necessarily by purpose. Another important thing to note here is that an image isn't limited to one textarea. Current implementation allows one image to be used with as many other fields as necessary -- or none at all if that's preferred. Disagreed. In the context of web content images are never _really_ inline, they're separate entities loosely tied to content (markup) with <img> tags. In some other environments this might make more sense, but not here You're confusing "limitations" with "decisions" here. As always there's more than one way to do it and not doing it "the way most CMS work" doesn't mean it's somehow faulty. Not 100% sure if that's really what you meant here, though that's the message I'm getting. Regarding an actual solution, I'd suggest taking a look at Soma's image manager and perhaps extending on that. I'm certain that contributions would be very much welcome. If it's tags that are bugging you, perhaps this could be tied more strictly with TinyMCE / CKEditor image plugin or something like that? (Sorry, I'm not exactly familiar with this module, so I can't say if that's already something it does.) Edit: after some Googling justboil.me and couple of it's alternatives (TinyMCE image / file upload plugins) popped up. PlugoBrowser seems very nice too, though not free.. but if it's client work you're going to use this for, $20 price tag shouldn't make much of a difference. Perhaps it would make more sense in this case to integrate one of these locally, possibly coupled with a custom plugin / view for selecting images from that location -- unless that plugin already comes with these features, that is. Some plugins for sure do, I even remember using something like that in the past. (Umm.. iBrowser?) Not sure if TinyMCE within PW allows custom modules, but I believe there was an option for it.. haven't really had that need myself

For the most part, I like the way that it works now. It's not really a "technical limitation," but a matter of flexibility. No matter how you do it, it's going to be a 2-step process of uploading and selecting the image, but the PW way bypasses having to build a separate folder structure while uploading your images and then having to hunt them down afterwards, while still retaining the flexibility of using images that appear on other pages if you want to. When you "add an image to the page" you literally are doing just that--adding an image to the page. Keeping the images separate from the individual WYSIWYG fields also allows you to reuse images more easily (in other WYSIWYGs or in your templates) and to see at a glance what images you have stored & available for use on that page. I think that it is actually more intuitive for people who are not familiar with CMSs at all. Plus the drag-and-drop functionality and auto-resize settings in the image containers bring a whole new level of usability to the CMS. I do agree that being able to drag and drop from the images field to the WYSIWYG would be an excellent feature, though. All of that being said, I recommend using individual custom image fields and outputting/resizing those images directly in the template with the API as much as possible. I have found that it is the most foolproof system for clients, and is where ProcessWire truly excels. Only use images inside the WYSIWYG for inline article images and never for images that are part of the site's layout.

In our case just explaining it once usually does the trick -- haven't really had the need to add anything about this to descriptions or stuff like that. It's a simple concept really and our clients have so far seemed to appreciate it, at least once they've been explained why this works this way. Personally I prefer to think of image (and usually file) fields as "storage spaces." If content in those fields should be visible on the page (note: this isn't automatically the case!) it should be added to one of that pages visible fields (in our case most commonly named after columns -- left, main, right etc.) Of course there are special cases where you could automatically show images or files on page.. or you could use repeaters to create fixed blocks with couple of options regarding text and image positioning or something like that. Depends a lot on the use case really. Anyway, my point is that current approach is very good for many situations and can be easily customized for various needs, image manager being just one example of this. Give it a good try, see how it works for you in some real life cases and if it still feels wrong, you can always implement something else for your needs. Regardless of that, one important thing to keep in mind when working with PW is that "page" is so much more than a "page" in some of the other CMS' out there and thus comparing some features between PW and it's competition doesn't necessarily make much sense. In our case a page is an object that can serve multiple purposes and hold all kinds of data for many different purposes.. you really shouldn't expect all of them to be public or even viewable

Double check what you're calling size() on. This sort of error happens [mostly], when: You have an error in your code – chance is, your field is called 'images' and you're calling 'image' You have another type of error in your code – calling image function on ImageArray, for example [rather than $images->size, you want something like $images->eq(0)->size() There is nothing uploaded yet. This happens, when your code is okay, but isn't prepared to receive no data, and, in fact, does receive no data Also, there might be problem with what Ryan posted, but if history taught us anything, it's that Ryan's code is mostly ok.