Leaderboard

Sunday afternoon pw art:

I think what you are looking for is: $page->save("total"); If you did just $page->save() you'd end up in a loop because your hook would get called again each time it saves itself. EDIT: Oh and in case you haven't figured it out, you need to set the field value first: $page->total = $ratTotal;

This gets you the label in the context of the entered template. $templates->get("template_name")->fieldgroup->getField('body', true)->label; You could also do this to get for the template of the current page: $templates->get($page->template->name)->fieldgroup->getField('body', true)->label;

It has nothing to do with PW I believe. PW only gives you the urls where the images resides $image->url. Cannot imagine how that could be get wrong. I have found the gallery what @KG60 seems to mean. For me it is looking like wrong calculations for div.pp_overlay and (maybe as a result of that) a wrong calculation for div.pp_pic_holder. And this is not a thing related to FF only. I see it with all my browsers the same (Win7 FF, IE11, IE10) Some questions came to my mind when seeing this: Why is pp_overlay defined by class and not by ID. I think it has to be a single unique div. Why is it calculated to cover the document dimensions and not the viewport dimensions. The first one may be not of interest, but the second one is the point that is wrong here I bet. Or if this is right too, than at least the position calculations for the div.pp_pic_holder are wrong (don't know / remeber if it is derived from overlay or not). It definately generates the right with and height, according to the viewport, but the wrong position. Also if one adjust the srolling a bit, it corrects to the correct position. Also the overlay goes way way beyond the footer of your document, and when it appears the other divs get scrollbars. --- FF win7 wrong position! ---- IE 11 In IE it also doesn't correct the position like in FF, and the other content divs only get vertical scrollbars.

https://github.com/adrianbj/ProcessModuleToolkit It allows bulk automated migration installation and upgrading of modules (and their config settings) from one PW install to another, so it should be very handy in setting up new sites with your standard collection of favorite modules and settings. Allows includes batch installing by a list of module class names. Go to the Setup > Module Toolkit and follow the prompts. During the import, you can choose which modules from the collection to import. You can optionally import the module config settings from the source install. The one caveat is if a particular setting includes a reference to a page, template, or field ID, it won't work, but you can easily update this setting on the destination install. Batch install new modules directly from the modules directory with a list of module classnames or URLs to module zip files. You can optionally, automatically update all of the imported modules (if they are in the ProcessWire modules directory) to their latest available versions. It copies the module files so you can use it to migrate modules that are not available in the PW modules directory, or on Github. Great for all those custom helper modules you've created. Full restore feature in case something goes wrong / you change your mind. I maintain a dedicated test PW install for installing and configuring modules which I can then export for use in my projects using this tool. Please test and let me know what you think!

Hi all, Here's a preview of a Gallery photo album module I am working on (very slowly! ). Development is currently in closed beta testing. The module will consist of a backend (as seen on video below) and a frontend that is framework and lightbox agnostic, aka plugin whatever and it will still work. Features Unlimited number of albums and sub-albums (easy to query using PW API) Multiple methods to add albums and photos (including uploading images and zip files, scanning a folder for FTP'ed photos, etc) Automatic album and photo creation based on names of folders and files respectively Bulk editing (moving, deleting, tagging, etc) Manager themes in several colours A bit of eye candy Etc... This is in beta so it is still rough around the edges. Feature suggestions? Yes please Apologies the video is way too long and you might get bored toward the end...

@peter: take a look at InputFieldFile. // usage with a Inputfield file with the name 'your_field': $tpl = new TemplateFile($config->paths->templates . "includes/" . $page->your_field); $tpl->set('current', $page); $markup = $tpl->render(); You then can access al Page fields in the php file with $current, like $current->title or $current->id etc.

$fields->save() would save details about that field - various settings etc, rather than the contents of the field on that particular page. $event is coming from the event that is hooked, so in this case, @majkiris is hooking page save, so by getting the first argument from the save event, he is getting the page object. You could also do: $page = $event->argumentsByName("page"); The first argument, eg arguments[0] won't always be the page object, it depends on the hook. Sometimes, for example, it might be the width of an image. Hope that helps a little.

Thank you adrian! Of course it works. I swear to my life that i did tried that..but it didn't work (maybe i used $page->save($total)). Thank you for the link Ivan. I will dive into it later.

solved: i failed to put the full folder of the getid3, i had just copied only the main class file.. major facepalm @adrian - forgot to thank you for helping.. (was actually replying to your post when the solution dawned on me..) by the way, this is pretty awesome, now i can read id3 tags and create pages based on those tags; also prevent users from uploading mp3 files where the bitrate is too high (in order to keep the filesizes small we use 128 for streaming files)...

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

*** lights a fire...

My bad. I thought it is out of scope error (which probably happened when majkris was performing $fields->save if I got it right). I am glad Adrian helped us here. But I want to take something out of this for myself too . As I understand, $page = $event->arguments[0]; sets $page variable in the scope of the class method. But I do not know what is $event and its arguments. Where do they come from? I would be happy to get an explanation or a link to documentation article/forum post.

Glad you got it sorted. Now that I think about it, this nesting level issue has come up before in respect of installing Blog. MarkupBlog docs are on my site here: I will need to update them soon with the latest changes as shown on post #207 and #244 here in the forums which you might want to read as well.

I am just loading all available translations and realized that there is also a naming inconsitency which should be standardized throughout Processwire. 1. two letter code for language (small letters) underscore two letter code flavour (capital letters) Right now the easy language install mdule shows on the add page the correct way in fdoing it but than on the installed languages both parts are in small letters only which is not consistent and confusing! Also German exists twice as de and as de_DE and finnish is only fi too! On https://github.com/PW4ALL/ProcessWire-Weblate/tree/master/site/languages it is all now standardized. the languages are right now just uploading. I assume that this is right now only the translations of the core. Name Title Core Translation Files Site Translation Files default English 0 0 de German 119 2 fi Finnish 0 2 zh-cn Chinese 84 0 cs-cz Czech 99 0 de-de German 122 0 es-es Spanish 25 0 fr-fr French 67 0 vi-vn Vietnamese 70 0 he-he Hebrew 36 0 it-it Italian 38 0 ja-jp Japanese Language Pack 70 0 hu-hu Hungarian 135 0 nl-nl Dutch 24 0 pl-pl Polish 37 0 pt-pt Portuguese 20 0 re-gr Processwire-greek-language 20 0 ru-ru Russian 68 0 sk-sk Slovak 37 0 se-se Swedish 23 0 tr-tr Turkish 135 0 also here the naming is quite inconsitent http://modules.processwire.com/categories/language-pack/ and should be corrected (actually those would no more be needed) if weblate will be used for future centralized translations. Or better would be to simply update them than from the translation git. Spanish exists even doubled with same name! es_ES which is not usable and confusing! Turkish has exactly the same problem and is existing twice. Collaboration would avoid it and marking a flavour with a different 2 letter Flavo code woudl help to clarify what s actually needed and what not! If there are more translation files of the core please let me know so I will add them to https://github.com/PW4ALL/ProcessWire-Weblate/tree/master/site/languages. Thanks

Hi Kongondo, I've resolved the issue and this was the problem: xdebug.max_nesting_level=100 I use Xdebug and your installation had originally crashed because the PHP program nesting level had hit this limit. I've no idea why this Xdebug setting should impact on PHP when not debugging but for whatever reason, it was. I extended this to 200 and voila - it installed just fine! I couldn't ever run Cleanup because it never (I presume) got far enough along in the install before it crashed due to the nesting limit. In any event, I reverted to backup (again) with the higher nesting limit and it all functioned perfectly! Now, all I have to do is learn to use the MarkupBlog module Anyway, thanks for being calm and patient and making this work available. The dashboard and utilities look really great and I'm glad I don't have to code up another half-baked, home-made blog yet again! Cheers.

Thanx for the ultra fast response. Works quite well

As I wrote I took the German Translation as it seems quite good and complete (most translated) You can find it here: https://github.com/PW4ALL/ProcessWire-Weblate/tree/master/site/languages as there are no English JSON files we woudl need to create them like a normal translation like I wrote above. Concerning using a PageID or using a PageName this can be a very little change IMHO. Instead of the ID we would choose the pagetitle ;-) and this would be than de_DE instead pf PageID 1012 and fi_FI instead of PageID 1013 in my Example I described above. For older sites there could be even a fallback like: Choose the Page Title if available, otherwise choose the PageID To keep things much clearer as they are right now I moved all translations into the first "site" level = site/languages/de_DE/.....json file Like in WordPress and in TYPO3 wie would use a separate language folder. (also this change for the langue files is actually only a path which would need to be changed in Processwire - so it is not a big deal. Also here could be a simple question in the next releases asking what folders should be used: site/assets/files/1013/.....json or site/languages/de_DE/.....json. and as you wrote already in Version 4.0 or perhaps already in 3.0 this could be changed to site/languages/de_DE/....json as default and people still would be able to do itthe old way by checking the fallback (old) solution. Usually if things work fine and things get translated on the server many more people will start using and finally use only the translations from weblate. As we don't change the naming of the json file itself actually all those translations could be simply been pulled from github for everybody and than inserted in a very traditional way too without any further changes. ;-) To update all those translation files and also to aff all those translation files which are currently already available I will extend our transaltion processwire site so that we can install here all available modules. We can use it also to see which nes get updated and which not. A cronjob will than regularly update this site and also copy the language.json files. If you have an idea what would be best to assure that the already translated translations get not overwritten by updating the modules peobably with anolder JSON file, please let me know. Scenario: we install a module in the site and have the site translated into another language, which means there is a translaotion.json file probably available for that module already. Some time later we update this module and again the translation probably gets updated (and is probably overwriting the old one grrr). IMHO we should move a module translation only once to the translation server and everything later has to be pulled from the translation server! After we have moved actually all cor and available module files to the weblate this will be a one stop solution as people will simply use it as it will provide much better translations for much less effort as it is community driven ;-) But OK we simply need to start it to get everything up to weblate as fast as possible. I will look in that next week and upload and update all I can get on translations in German. I use German as it has already a great community like many other Open Source CMS and I am German and can understand it ;-) In parallel you could start looking after the russian stuff too and add more translations. As I pointed out already ru_RU would not change the filenames in that folder and therefore could be easily uploaded to the site. We could even modify the easyinstalllanguage Module in pulling the languages from the pw4all/ProcessWire-Weblate repository.

Great idea! This is the place we intend to collect all modules. We got already the core in - ok we need to manage the updates later on a regular base. https://github.com/pw4all Have a look to https://github.com/PW4ALL/ProcessWire/tree/master/site-languages/install/files Here the translations for German and Finnish got stored in 1012 and 1013 while the German folder contains lots of translated modules already and the Finnish one only 2 translations actually. The way those translations get stored and the folder name is actually not really a good way doing it. Better would be to name the German Folder de_DE, or de_CH, or de_AT as depending on the region you are there are differences in the translations and would need to be reflected in a site translation or the one of the modules. The same actually applies to en_US, en_CA, en_UK, en_AU etc which are all not the same even most words probably are the same or similar. Another source of actual problems is the original text as this does not get stored in a json file! let's talk about an example: go here: https://github.com/PW4ALL/ProcessWire/blob/master/site-languages/templates/_main.php you can see the original text parts as they look like: No 1 - echo _x('en', 'HTML language code') No 2 - __('Edit') No 3 - echo _x('Search', 'placeholder') No 4 - echo _x('Search', 'button') No 5 - echo __('Powered by ProcessWire CMS') No 6 - sprintf(__('Logout (%s)') No 7 - __('Admin Login') and compare it with the German translation: https://github.com/PW4ALL/ProcessWire/blob/master/site-languages/install/files/1012/site--templates--_main-php.jso { "file": "site\/templates\/_main.php", "textdomain": "site--templates--_main-php", "translations": { "6f9fc985da145fcdd180f254dd161c57": { "text": "Suche" --- echo _x('Search', 'placeholder') -> No 3 }, "2c889b7622e6ed4e56a1414ac333c814": { "text": "Suche" --- echo _x('Search', 'button') -> No 4 }, "7dce122004969d56ae2e0245cb754d35": { "text": "Bearbeiten" --- __('Edit') -> No 2 }, "3ee693d376f73e2bfa34e985c30bec66": { "text": "Abmelden (%s)" --- sprintf(__('Logout (%s)') -> No 5 }, "b6e31daf2404aab3d78c7e972dfe3f8d": { "text": "Login" --- __('Admin Login') -> No 6 }, "7679c0bdbd87c1984bd611c24b3cd0cb": { "text": "de" --- echo _x('en', 'HTML language code') -> in Head Section No 1 } } } No 7 is missing in the German translation! and with the one of the Finish translation: { "file": "site\/templates\/_main.php", "textdomain": "site--templates--_main-php", "translations": { "7dce122004969d56ae2e0245cb754d35": { "text": "Muokkaa" --- No 2 }, "91e2c8e591043b9d9c7611a185358068": { "text": "Toimii ProcessWire CMS" --- No 7 }, "3ee693d376f73e2bfa34e985c30bec66": { "text": "Kirjaudu ulos (%s)" --- No 5 }, "b6e31daf2404aab3d78c7e972dfe3f8d": { "text": "Kirjaudu" --- No 6 }, "6f9fc985da145fcdd180f254dd161c57": { "text": "Haku" --- No 3 }, "2c889b7622e6ed4e56a1414ac333c814": { "text": "Haku" --- No 4 }, "7679c0bdbd87c1984bd611c24b3cd0cb": { "text": "fi" --- No 1 } } } as you can very easy see there is abolute no logical order in those translation files. Similar to PO files the translations are assigned to a certain string. Without an external tool actually or an integrated solution translation is a hazzle like this. only as a comparison to that here a file from WordPress, where you can see a very clear structure and order but also here you need to translate stuff in an external program which creates the right matches so it will work with your templates. #: E:\!our theme wordpress\residence\!versions\1.07/wpresidence/404.php:16 msgid "Page not found" msgstr "" #: E:\!our theme wordpress\residence\!versions\1.07/wpresidence/404.php:20 msgid "" "We're sorry. Your page could not be found, But you can check our latest " "listings & articles" msgstr "" #: E:\!our theme wordpress\residence\!versions\1.07/wpresidence/404.php:24 msgid "Latest Listings" msgstr "" #: E:\!our theme wordpress\residence\!versions\1.07/wpresidence/404.php:44 msgid "Latest Articles" msgstr "" #: E:\!our theme #: wordpress\residence\!versions\1.07/wpresidence/advanced_search_results.php:452 #: wordpress\residence\!versions\1.07/wpresidence/templates/search_unit.php:19 msgid "Search Parameters: " msgstr "" #: E:\!our theme #: wordpress\residence\!versions\1.07/wpresidence/advanced_search_results.php:458 msgid "Save this Search?" msgstr "" #: E:\!our theme #: wordpress\residence\!versions\1.07/wpresidence/advanced_search_results.php:459 msgid "Search name" msgstr "" #: E:\!our theme #: wordpress\residence\!versions\1.07/wpresidence/advanced_search_results.php:460 msgid "Save Search" msgstr "" #: E:\!our theme #: wordpress\residence\!versions\1.07/wpresidence/advanced_search_results.php:472 msgid "" "Login to save search and and you will receive an email notification when new " "properties matching your search will be published." msgstr "" #: E:\!our theme #: wordpress\residence\!versions\1.07/wpresidence/advanced_search_results.php:506 #: wordpress\residence\!versions\1.07/wpresidence/search.php:32 msgid "" "We didn't find any results. Please try again with different search " "parameters. " msgstr "" Wordpress always needs an aditional mo file! Þ•$,8˜9Project-Id-Version: wpresidence POT-Creation-Date: 2014-11-17 10:56+0200 PO-Revision-Date: 2014-11-17 10:56+0200 Last-Translator: Language-Team: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Generator: Poedit 1.5.4 X-Poedit-KeywordsList: _;gettext;gettext_noop;_e;__ X-Poedit-Basepath: . X-Poedit-SearchPath-0: E:\!our theme wordpress\residence\!versions\1.07 and TYPO3: you can very easily edit the xml file in any editor if you like! <?xml version="1.0" encoding="UTF-8"?> <T3locallangExt> <data type="array"> <languageKey index="de" type="array"> <label index="mlang_labels_tablabel">Informationen über Module</label> <label index="mlang_labels_tabdescr">Zeigt diese Seite über die vorhandenen Module an.</label> <label index="mlang_tabs_tab">Über Module</label> </languageKey> </data> </T3locallangExt> TYPO3 translations always hava ow also the xliff file <?xml version='1.0' encoding='utf-8'?> <xliff version="1.0"> <file source-language="en" datatype="plaintext" original="messages" date="2011-10-17T20:22:32Z" product-name="aboutmodules" target-language="de"> <header/> <body> <trans-unit id="mlang_labels_tablabel" xml:space="preserve" approved="yes"> <source>Information about modules</source> <target state="translated">Informationen über Module</target></trans-unit> <trans-unit id="mlang_labels_tabdescr" xml:space="preserve" approved="yes"> <source>Shows this page about available modules.</source> <target state="translated">Zeigt diese Seite über die vorhandenen Module an.</target></trans-unit> <trans-unit id="mlang_tabs_tab" xml:space="preserve" approved="yes"> <source>About Modules</source> <target state="translated">Über Module</target></trans-unit> </body> </file> </xliff> Go and compare also the folder structres and where those translations get stored and you will realize that it is very easy in TYPO3 - typo3conf/l10m/de/modulename/mod/de_locallan_mod.xml especially also because each module has the original translation already in an xml file available (same format!) They work with placeholder texts! a bit more complicated to find in Wordpress - wp-content/themes/themename/languages/themname.po - allways depending on a theme and actually quite complicated in Processwire as even the location changes during the installation process from site/install/files to site/assets/files site/assets/files/1012/site-templates--_main-php.json and than even in another language the files have the same name! site/assets/files/1013/site-templates--_main-php.json without having a look inside one of those files you even don't know what language they are! ---- while you have in WordPress and in TYPO3 the original language or the placeholder name ALWAYS available in a readable form it makes it way easier to translate. ==================== My suggestion rightnow would be to ask Ryan for a clear statement on how the translation is actually done in TYPO3 so that we can figure out a feasible way to get all the originals into the translation system. Right now this system is actually ONLY working if people stay brave in English in their originals which limits Processwire already and lowers probably even it's quality as people are more or less forced to use probably a language they can only translate via Google and to be honest - Google is nice for public usage but not at all suitable for a professional translation. Questions to people who did the translation module of processwire and Ryan. 1. What would be the best way to pull out the translations in the original file? What format as the original is stored in php files and not in json files unfortunately 2. How can those location strings be generated and assigned? 3. Would there be a chance to change the way / file formats, translations get done. Probably we don't even need a big change as IMHO only a Json file with the original Language would be needed ;-) Benefit of this idea: Processwire would NOT depend on any default language and could set any language as default and define even a very flexible fallback of languages. In other words. All original languages which have been already been inserted into processwire .php files would beed to get extracted to a json file which is in English language. As there are different flavours of languages which are quite important when selling websites, the numbering need to be changed and I suggest to use de_DE, en_US, de_CH, de_AT, en_UK etc instead. Many English, German or any other Language flavours would be possible after that change. After the complete extraction of those language translation terms inside the defaul PHP files to jSON files those default PHP files could also hold also simple placeholders instead of the original translations. This would make it for non English spoken Developers much easier to contribute. They would set a "marker" and than add their localisaztion which could be german, russian and thai etc and the english one would simply be missing until somebody comes and is able to translate it into english language. If a separate JSON file in english would be available than also the problem with setting a default language would be solved very easily. I think there should be a way to parse all .php files for __ _x _n and extract all those terms into one external json file per .php file. It would use a standardised labeling - i.e. en_US-locallang-modulename.json in another step we can collect all those en_US-locallang-....json files and put them in a centralized folder i.e. files! I personally would avoid using files for that purpose as keeping all translations in a translation folder or simply call it "languages" would be much much easier. As than those files are in another location and also there woudl be now an original english language file which itself could be translated into several english flavours, only the paths to those newly created languages and localisationfiles would need to be changed. the structure at the end would look like this site/languages/default/default-locallang-module1name.json site/languages/default/default-locallang-module2name.json site/languages/default/default-locallang-module3name.json ... site/languages/en_US/en_US-locallang-module1name.json site/languages/en_US/en_US-locallang-module2name.json site/languages/en_US/en_US-locallang-module3name.json ... site/languages/en_GB/en_GB-locallang-module1name.json site/languages/en_GB/en_GB-locallang-module2name.json site/languages/en_GB/en_GB-locallang-module3name.json ... site/languages/de_DE/de_DE-locallang-module1name.json site/languages/de_DE/de_DE-locallang-module2name.json site/languages/de_DE/de_DE-locallang-module3name.json ... site/languages/de_CH/de_CH-locallang-module1name.json site/languages/de_CH/de_CH-locallang-module2name.json site/languages/de_CH/de_CH-locallang-module3name.json ... now it would be very easy to pull ONLY the files from site/assets/languages/*/*.json into weblate and translate them. As Json files are monolingual we woudl need to define a default and this could be the default folder (even it would be a duplicate of any other language, but this folder would simply hold all "placeholder" strings which could be in English or German or simple placeholders. This site/languages folder could regularly check with the core and all modules i.e. on pw4all github if there are any new strings which would need to be translated. It would update the default files but all language files woudl stay the same. Those strings which are i.e. missing in default now would be marked as to be deleted in the translation files (but carefull as perhaps some older modules from people who don't update their sites would need them) and newly added translations would be marked as new and to be translated. This way a quite fast workflow could be created to get translations up and running very fast as a community based effort using weblate. site/docs/default/default_doc_module1name site/docs/default/default_doc_module2name site/docs/default/default_doc_module3name .. site/docs/en_US/en_US_doc_module1name site/docs/enUS/en_US_doc_module2name site/docs/en_US/en_US_doc_module3name ... Concerning the documentation I suggest to do actually exactly the same like with the languages and use readthedocs for the default and present alo the translations on readthedocs. also this documentation gets stored on github in a documentation folder which simply lists the modules. Each read the docs file could than be pulled if needed in a site from there. ----- But the first step would be to get Ryan involved here as if the core won't provide a base json file it is a bit crappy to translate the rest! - there really needs to bea better logical order and structure in folder/ file-namings and inside the translation .json file itself. ---- So the first step is done but I need to wait now until those files will appear. I took a site we use for our purposes and it has nearly all modules already translated into german language ;-) That's fine. I created on a new repository in where we will store all those translation files. I already changed the folder namings to be de_DE, fi_FI like it should be. Next I will try to ecxxtract all the English stuff as there is no JSON file available right now but irt would be very usefull. I will let you know as soon as we get further on weblate and than see how to continue. If you can see a way how to extract all the english defaults into one JSON file this would be very appreciated! We now continue also setting up the docs on readthedocs People who want to join this effort please contact us via PM so we can start creating translation and documentation teams. --- You are right Ivan that it is a lot to read but IMHO it is worth it and we need people who like to contribute so they need to know the idea behind it. Concerning Ryan you are also right that he is probably busy with other stuff and that is why we already started right the way. But I hope that he can at least get his thoughts on how to extract the default translations and how to probably change the page numbering 1012 to a de_DE etc. I guess that this won't be a big deal. If you have ideas please contribute them here as I am sure people will read and follow the thread.

That thumbnail cropping tool thingy: its like having a big bowl of your favorite ice-cream... That is all...

Wait till you see what horst has in the wings to replace this Stay tuned!

I am sure lots of very cool things could be done, all of which will require a little more than the 5 mins of planning and 20 mins of coding I put into this one Here is a revised version (with a new name) with about an extra 15 mins of coding that adds support for batch adding/removing of fields from templates. I think I might actually make use of this version quite a bit. EDIT: I don't think "Template Setup Batcher" is the right name - not really about setting up templates from scratch. Oh well - maybe change again if a newer version ever happens ProcessTemplateSetupBatcher.module

I think hanna code makes the most sense here, but of course if you'd rather avoid that for some reason (maybe no other needs for it on the site, or whatever), you can always do your own replacement. Have your editors enter [[gallery]] somewhere in the body copy and then in your template do a simple: echo str_replace("[[gallery]]", $galleryCode, $page->body); You just need to define $galleryCode in your template code somewhere before the body is output.

Inside a module I think you probably want $this->page or wire('page') Have you checked that $file->filename is returning a valid path to the file? Also, have you seen horst's module: http://modules.processwire.com/modules/local-audio-files/

I do not see any obstacles to test out weblate + github for translations. I searched weblate repo and did not find Processwire there yet. Lisandi, why don't you start the project and configure it as you are most familar with the software. If it can't be done the way PW stores translation strings please report back so we can deal with it. If the translation project grows and becomes important for the community, you could then hand off or share the administration rights with those interested (and probably Ryan first). We can deal with documentation and integration later. What do you think about it?

Happy Birthday, too! (We need a Birthday calendar and a reminder - since i've read more in this forum than on my other social hubs.... )

We missed black friday, but cyber monday is still coming .

Greetings, It's embarrassing when you set a bandwidth limit on your own website -- then manage to exceed it. I'm in the process of completely revamping that silly old site anyway. It just keeps getting put off in favor of those nagging paying clients. Thanks for the heads up. Very much still alive, Matthew

If you install this module you´ll be able to use angular and use it in your templates directly. Example of a list of all children of the actual page. <script> app.controller('myCtrl', function ($scope) { $scope.children = []; $scope.children = <?=$page->getChildren()?>; }); </script> <div ng-controller="myCtrl"> <ul> <li ng-repeat="child in children">{{child.title}}</li> </ul> </div>

Are you familiar with $input->get? You can simply accept a city argument on category pages and vice versa. On your category page, you list cities like so: foreach ($cities as $city) { echo "<a href='{$city->url}?category={$page->id}'>{$city->title}</a>"; } On the city page where that link leads, you accept the argument "category": $category = $pages->get($input->get['category']); Now you know the city and the category to search for. Refer to the docs for more info on $input. Note there are several other ways to solve your problem.

Sorry for poor communications from my part. New shop module is currently in closed beta testing. I am pretty busy at the moment (both work and personal), so there is not too much focus on this. For the pricing I am thinking something like 50€ - 99€ for single site license. Also currently (slowly) building full featured shop profile, that would be single purchase and free to use parts or fully as many times as wanted (single site license required for all new shops though).

This is too blatant. In ModX I had a basic structure for my concept. I knew what to do in the header chunk and the footer chunk the rest I've done in the content. I figure it with Content and Template Variables. Im PW its much more complicated for me. its too flexible. you can do what you want and on every place. DAMN I have really get used to it.

Great guide Kongondo! Beyond being helpful to people familiar with MODX, I also think this guide would be helpful even to people that don't know MODX, as it introduces many ProcessWire concepts very well. Also, I'm not particularly familiar with MODX, so found it helpful in learning about MODX too. Thanks for your great work here.