Leaderboard

Hey, it's really a pain if you start a new translation that you have to enter each path separately. Why can't ProcessWire just do a quick search, find all translatable files and create the fitting .json files? Or does it behaves like that already and I just missed it? So you won't have to keep a blanko language like manfred created (thanks for this!): https://processwire.com/talk/topic/7245-translation-for-pw-25/

One of the reasons I created my module... https://processwire.com/talk/topic/2787-custom-menu-not-related-to-page-tree/

You mean like this one? https://processwire.com/talk/topic/4451-module-menu-builder/ I got stuck somewhere and stopped developing it....In the (probably very distant future) I might rethink and revisit it . I am liking your eagerness to learn module creation and the inner architecture of PW. Keep the fire burning and enjoy the ride ! I can promise you two things: (i) As you hit the 'aha moments', you'll wonder why you didn't discover PW earlier . (ii) You'll realise even more that Ryan Cramer is an unsung hero; what he's done with the PW API is amazing; he's carefully thought out (almost) everything.... ...respect... Happy coding...

Try mousing over the collapse down arrow over on the right - that does what you are looking for, or better yet, install: http://modules.processwire.com/modules/helper-field-links/

In tutorials section of the site we are encouraged to request tutorials. This topic is such a request. ProcessWire is advertised to be great in not only building unique frontend features, but also custom backends. I would be very much interested in tutorial on building a custom backend for a site. I put some questions that could be covered in such a tutorial in a list below: How to create custom backend pages How to change the default starting page for admin users How to serve different backends to different users depending on roles How to style the page tree (I have seen it styled in some Soma's video tutorials, so it is a request for a best practice or an advice) Anything else you think appropriate here))) If someone could generously provide a screencast of a custom backend workflow it would be great tutorial in itself.

Like I mentioned in another topic I'm working on a theming system for Processwire. Today I finished a huge step in the right direction: A theme switcher. How does it work It's really easy. Frontend Themes are modules, (I added two testing Themes to the attachment), which only contain the module information (version, author, name, ...). They are based on a module called "WireThemes" which is included, too. WireThemes is the main controlling class. It rewrites the path of "$config->paths->templates" and "$config->urls->templates" which afterwards pointing to the folder of your Theme and contains the installing and uninstalling methods. What I'm still working on ProcessWire's great strength - but in case of theming a big complication - is that you have to/can create fields by yourself. So it's hard to create a theme which fit's on every system. That's why I'm still brainstorming how to make this easier. Possible solutions I see at the moment are: Creating a site profile with the most used fields Creating a json file for ProcessMigrator Hoping that the 2.5 default site profile includes the most used fields so I wouldn't have to change something ... Please try it and tell me about any problems. And if you have additional ideas this is the right place to write about them. Download: https://github.com/NicoKnoll/WireThemes

Heya, everybody! The Hungarian language pack for Processwire is on the way. I will post here about the stages of the translation process. Stay tuned!

New functionality added: https://github.com/NicoKnoll/WireThemes/blob/master/README.md#how-to-create-a-theme

That's how we should always start thinking with PW It abstracts things less and allows to use the API for everything.

Well your idea to build this using PW pages has just given me an idea...In my case I was using a custom database to allow for any menu item (be it an external or internal link) to be a parent or child of any other menu item (i.e. not align to the PW tree). I got stuck at deleting and recursively re-parenting menu items....

Sparrow, no need to apologise for anything . Your question will help the next guy. Once I write the API documentation, you'll realise that you can also tweak this Blog to make fundamental layout changes. You can output bits and pieces (tags, posts, categories, authors, comments, etc) anywhere using its API since it is a PW module. All these bits and pieces are independent of each other. This is similar to PW pages in the sense that you can output page fields anywhere in any order in your site or even not output any of the fields.

Yeah, use my fork and it will work:. Hani still didn't merged it... https://github.com/NicoKnoll/Processwire_FieldType_Select_Drop_Down/tree/patch-1

This post is in response to this question posted on GitHub Comment Layout First, I'd like to reiterate that this Blog Module does not use any CSS framework. The Blog (site) Profile (on which Blog Module is based) uses the Skeleton CSS framework. However, in this Module's demo/example output/template files, I have used PocketGrid CSS. It is not a requirement. You can use whichever CSS framework (or not) you wish. The following example is for this module (but is equally applicable to the Blog Profile). It is very easy to style Blog's comments by targeting the output HTML IDs and Classes in your CSS. In my example template files, my custom styles are in blog.css. The example code below is an HTML output of Comments where 'comments are allowed'. <div id="comments"> <span class="num-comments-icon">2</span> <h4>Comments</h4> <ul class="comments CommentList"> <li class="comment CommentListItem" id="comment1"> <p class="comment-head CommentHeader">Comment by kongondo on 13 April 2014 11:16 pm</p> <div class="comment-body CommentText"><p>Simply the best CMS.</p></div> </li> <li class="comment CommentListItem" id="comment10"> <p class="comment-head CommentHeader">Comment by kongondo on 23 May 2014 2:42 pm</p> <div class="comment-body CommentText"><p>ProcessWire rocks, yeah!</p></div> </li> </ul> <!--CommentForm--> <div id="CommentForm" class="CommentForm_new"> <h4>Post a comment</h4> <form id="CommentForm_form" action="./#CommentForm" method="post"> <p class="CommentForm_cite"> <label for="CommentForm_cite">Your Name</label> <input type="text" name="cite" class="required" required="required" id="CommentForm_cite" value="" maxlength="128"> </p> <p class="CommentForm_email"> <label for="CommentForm_email">Your E-Mail</label> <input type="text" name="email" class="required email" required="required" id="CommentForm_email" value="" maxlength="255"> </p> <p class="CommentForm_text"> <label for="CommentForm_text">Comments</label> <textarea name="text" class="required" required="required" id="CommentForm_text" rows="5" cols="50"></textarea> </p> <p class="CommentForm_submit"> <button type="submit" name="CommentForm_submit" id="CommentForm_submit" value="1">Submit</button> <input type="hidden" name="page_id" value="2488"> </p> </form> </div><!--/CommentForm--> </div> So, you do not need to tweak any file. All you need is to style the output. For the PHP stuff, I am in the process of writing some documentation... Hope this answers your query. Thank you for using Blog

I think the idea is possible but it would have to make certain assumptions about what people want to do (favourite would be to provide the most common output). For example with an images field storing multiple images I might suggest they get outputted as thumbnails in a UL element and have thumbnails link to larger versions. Anything like this would also be best if it spat out comments in the template as to how to change things or rather link to relevant parts of the documentation and API. It's not impossible to do, but at some point you're just going to be recreating what's already in docs like the Planets tutorial, but possibly without people bothering to read and learn what's going on. I guess what I mean is there's always a trade-off when lowering the barrier to entry, so perhaps if the auto-generated templates were very well commented that would make up for it.

Menu Builder As of 29 December 2017 ProcessWire versions earlier than 3.x are not supported Modules Directory Project Page Read Me (How to install, use, etc..) For highly customisable menus, please see this post. If you want a navigation that mirrors your ProcessWire page tree, the system allows you to easily create recursive menus using either vanilla PHP or Soma's great MarkupSimpleNavigation. In some cases, however, you may wish to create menus that: 1. Do not mirror you site's page tree (hirarchies and ancestry); and 2. You can add custom links (external to your site) to. That is primarily where Menu Builder comes in. It is also helpful if you: 3. Prefer creating menus via drag and drop 4. Have a need for menus (or other listings) that will be changing regularly or that you want to allow your admin users to edit. The issue of custom menus is not new here in the forums. The difference is that this module allows you to easily create such menus via drag and drop in the Admin. Actually, you can even use it to just create some list if you wanted to. In the backend, the module uses the jQueryUI plugin nestedSortable by Manuele J Sarfatti for the drag and drop and is inspired in part by the WP Custom Menu feature. Please read the Read Me completely before using this module. For Complex or highly-customised menus, it is recommended to use the getMenuItems() method as detailed in this post. Features Ability to create menus that do not mirror your ProcessWire Page Tree hierarchy/structure Menus can contain both ProcessWire pages and custom links Create menu hierarchies and nesting via drag and drop Easily add CSS IDs and Classes to each menu item on creating the menu items (both custom and from ProcessWire pages) or post creation. Optionally set custom links to open in a new tab Change menu item titles built from ProcessWire pages (without affecting the original page). E.g. if you have a page titled 'About Us' but you want the menu item title to be 'About' Readily view the structure and settings for each menu item Menus stored as pages (note: just the menu, not the items!) Menu items stored as JSON in a field in the menu pages (empty values not stored) Add menu items from ProcessWire pages using page fields (option to choose between PageAutocomplete and AsmSelect [default]) or a Selector (e.g. template=basic-page, limit=20, sort=title). For page fields, you can specify a selector to return only those specified pages for selection in the page field (i.e. asm and autocomplete) For superusers, optionally allow markup in your menu titles, e.g. <span>About</span> Menu settings for nestedSortable - e.g. maxLevels (limit nesting levels) Advanced features (e.g. add pages via selector, menu settings) currently permissible to superadmins only (may change to be permission-based) Delete single or all menu items without deleting the menu itself Lock down menus for editing Highly configurable MarkupMenuBuilder - e.g. can pass menu id, title, name or array to render(); Passing an array means you can conditionally manipulate it before rendering, e.g. make certain menu branches visible only to certain users [the code is up to you!] Optionally grab menu items only (as a Menu object WireArray or a normal array) and use your own code to create custom highly complex menus to meet any need. More... In the backend, ProcessMenuBuilder does the menu creation. For the frontend, menus are displayed using MarkupMenuBuilder. Credits In this module's infancy (way back!), I wanted to know more about ProcessWire modules as well as improve my PHP skills. As they say, what better way to learn than to actually create something? So, I developed this module (instead of writing PW tutorials as promised, tsk, tsk, naughty, naughty!) in my own summer of code . Props to Wanze, Soma, Pete, Antti and Ryan whose modules I studied (read copied ) to help in my module development and to Teppo for his wonderful write-up on the "Anatomy of fields in ProcessWire" that vastly improved my knowledge and understanding of how PW works. Diogo and marcus for idea about using pages (rather than a custom db table), onjegolders for his helpful UI comments, Martijn Geerts, OrganizedFellow, dazzyweb and Mike Anthony for 'pushing me' to complete this module and netcarver for help with the code. Screens

As briefly discussed earlier with Ryan (http://processwire.com/talk/topic/1560-searching-multiple-fieldtypes/page-2#entry23307), I tried to build some sort of test suite for ProcessWire. The tests aim for selector consistency (in-memory and db) and of course making them free of bugs - once and for all. The beginning of the test suite with instructions can be found from https://github.com/niklaka/ProcessWireTests . I wouldn't be surprised if I had to go and restructure the whole thing sooner than later (more than once even), but that'll do for now. Next I'll focus on writing a basic set of tests to cover at least the most common selectors (as there's currently only a few of the most simple ones there). This testing stuff if somewhat new to me and I've been reading lately a little something on the subject. Hope I got at least something right . Having said that, any help (or constructive criticism) from you my dear friends is highly appreciated. Especially if you'd happen to have any/some experience on testing - but I'll take kind words from anyone . I decided to try where I'm able to get with PHPUnit and so far it looks like it would be very much possible to build something useful with it (no, I'm not exactly surprised as it sure is a proven tool for such a thing). I did take Ryan's idea of using Skyscrapers profile as a base for testing (you're not making changes to it are you Ryan ), but there may be need for some other approach as well, even another Skyscrapers based one. Well, I'll go and write a a couple of more tests now. (PS: If some admin feels this post fits some other area better, please do move it - I wasn't sure where to put it myself.)

The Module Blog for ProcessWire replicates and extends the popular Blog Profile. Blog is now in version 2. Please read the README in the Github link below in its entirety before using this module As of 20 December 2017 ProcessWire versions earlier than 3.x are not supported Blog Documentation is here (Work in Progress!) See this post for new features in version 2 or the readme in GitHub. To upgrade from version 1, see these instructions. ################################################## Most of the text below refers to Blog version 1 (left here for posterity). Blog version 1 consists of two modules: ProcessBlog: Manage Blog in the backend/Admin. MarkupBlog: Display Blog in the frontend. Being a module, Blog can be installed in both fresh and existing sites. Note, however, that presently, ProcessBlog is not compatible with existing installs of the Blog Profile. This is because of various structural and naming differences in respect of Fields, Templates, Template Files and Pages. If there is demand for such compatibility, I will code a separate version for managing Blog Profile installs. In order to use the 'Recent Tweets Widget', you will need to separately install and setup the module 'MarkupTwitterFeed'. Please read the README in the Github link below in its entirety before using this module (especially the bit about the Pages, etc. created by the module). I'll appreciate Beta testers, thanks! Stable release works fine. Download Modules Directory: http://modules.processwire.com/modules/process-blog/ Github: https://github.com/kongondo/Blog You can also install from right within your ProcessWire install. Screenshots (Blog version 1) Video Demos ProcessBlog MarkupBlog Credits Ryan Cramer The Alpha Testers and 'Critics' License GPL2

for the upcoming PW version 2.5: here you find a list of files which I have translated (based on the actual dev pre 2.5). These are 122 files (updated). Not all have to be translated, but are "nice to have". If someone wants to start a new lang-pack, take the empty lang files from the zip. list of all files: wire--core--admintheme-php.json wire--core--field-php.json wire--core--fieldgroups-php.json wire--core--fields-php.json wire--core--fieldselectorinfo-php.json wire--core--fieldtype-php.json wire--core--fieldtypemulti-php.json wire--core--functions-php.json wire--core--inputfield-php.json wire--core--inputfieldwrapper-php.json wire--core--modules-php.json wire--core--pagefile-php.json wire--core--pageimage-php.json wire--core--pages-php.json wire--core--password-php.json wire--core--process-php.json wire--core--sanitizer-php.json wire--core--session-php.json wire--core--sessioncsrf-php.json wire--core--wirecache-php.json wire--core--wirehttp-php.json wire--core--wiretempdir-php.json wire--core--wireupload-php.json wire--modules--admintheme--adminthemedefault--adminthemedefault-module.json wire--modules--admintheme--adminthemereno--adminthemereno-module.json wire--modules--admintheme--adminthemereno--adminthemerenohelpers-php.json wire--modules--admintheme--adminthemereno--debug-inc.json wire--modules--admintheme--adminthemereno--default-php.json wire--modules--fieldtype--fieldtypecomments--commentfilterakismet-module.json wire--modules--fieldtype--fieldtypecomments--commentform-php.json wire--modules--fieldtype--fieldtypecomments--commentlist-php.json wire--modules--fieldtype--fieldtypecomments--fieldtypecomments-module.json wire--modules--fieldtype--fieldtypecomments--inputfieldcommentsadmin-module.json wire--modules--fieldtype--fieldtypedatetime-module.json wire--modules--fieldtype--fieldtypefile-module.json wire--modules--fieldtype--fieldtypefloat-module.json wire--modules--fieldtype--fieldtypemodule-module.json wire--modules--fieldtype--fieldtypepage-module.json wire--modules--fieldtype--fieldtypepagetable-module.json wire--modules--fieldtype--fieldtyperepeater--fieldtyperepeater-module.json wire--modules--fieldtype--fieldtyperepeater--inputfieldrepeater-module.json wire--modules--fieldtype--fieldtypeselector-module.json wire--modules--fieldtype--fieldtypetext-module.json wire--modules--fieldtype--fieldtypetextarea-module.json wire--modules--fieldtype--fieldtypeurl-module.json wire--modules--inputfield--inputfieldasmselect--inputfieldasmselect-module.json wire--modules--inputfield--inputfieldbutton-module.json wire--modules--inputfield--inputfieldcheckbox-module.json wire--modules--inputfield--inputfieldcheckboxes--inputfieldcheckboxes-module.json wire--modules--inputfield--inputfieldckeditor--inputfieldckeditor-module.json wire--modules--inputfield--inputfielddatetime--inputfielddatetime-module.json wire--modules--inputfield--inputfieldemail-module.json wire--modules--inputfield--inputfieldfieldset-module.json wire--modules--inputfield--inputfieldfile--inputfieldfile-module.json wire--modules--inputfield--inputfieldfloat-module.json wire--modules--inputfield--inputfieldform-module.json wire--modules--inputfield--inputfieldhidden-module.json wire--modules--inputfield--inputfieldimage--inputfieldimage-module.json wire--modules--inputfield--inputfieldinteger-module.json wire--modules--inputfield--inputfieldmarkup-module.json wire--modules--inputfield--inputfieldname-module.json wire--modules--inputfield--inputfieldpage--inputfieldpage-module.json wire--modules--inputfield--inputfieldpageautocomplete--inputfieldpageautocomplete-module.json wire--modules--inputfield--inputfieldpagelistselect--inputfieldpagelistselect-module.json wire--modules--inputfield--inputfieldpagelistselect--inputfieldpagelistselectmultiple-module.json wire--modules--inputfield--inputfieldpagename--inputfieldpagename-module.json wire--modules--inputfield--inputfieldpagetable--inputfieldpagetable-module.json wire--modules--inputfield--inputfieldpagetable--inputfieldpagetableajax-php.json wire--modules--inputfield--inputfieldpagetitle--inputfieldpagetitle-module.json wire--modules--inputfield--inputfieldpassword-module.json wire--modules--inputfield--inputfieldradios--inputfieldradios-module.json wire--modules--inputfield--inputfieldselect-module.json wire--modules--inputfield--inputfieldselectmultiple-module.json wire--modules--inputfield--inputfieldselector--inputfieldselector-module.json wire--modules--inputfield--inputfieldsubmit--inputfieldsubmit-module.json wire--modules--inputfield--inputfieldtext-module.json wire--modules--inputfield--inputfieldtextarea-module.json wire--modules--inputfield--inputfieldurl-module.json wire--modules--jquery--jquerywiretabs--jquerywiretabs-module.json wire--modules--languagesupport--languageparser-php.json wire--modules--languagesupport--languagesupport-module.json wire--modules--languagesupport--languagesupportfields-module.json wire--modules--languagesupport--languagesupportpagenames-module.json wire--modules--languagesupport--languagetabs-module.json wire--modules--languagesupport--processlanguage-module.json wire--modules--markup--markuppagefields-module.json wire--modules--markup--markuppagernav--markuppagernav-module.json wire--modules--pagepaths-module.json wire--modules--pagerender-module.json wire--modules--process--processfield--processfield-module.json wire--modules--process--processfield--processfieldexportimport-php.json wire--modules--process--processforgotpassword-module.json wire--modules--process--processhome-module.json wire--modules--process--processlist-module.json wire--modules--process--processlogin--processlogin-module.json wire--modules--process--processmodule--processmodule-module.json wire--modules--process--processmodule--processmoduleinstall-php.json wire--modules--process--processpageadd--processpageadd-module.json wire--modules--process--processpageclone-module.json wire--modules--process--processpageedit--processpageedit-module.json wire--modules--process--processpageeditimageselect--processpageeditimageselect-module.json wire--modules--process--processpageeditlink--processpageeditlink-module.json wire--modules--process--processpagelist--processpagelist-module.json wire--modules--process--processpagelister--processpagelister-module.json wire--modules--process--processpagesearch--processpagesearch-module.json wire--modules--process--processpagesort-module.json wire--modules--process--processpagetrash-module.json wire--modules--process--processpagetype--processpagetype-module.json wire--modules--process--processpageview-module.json wire--modules--process--processpermission--processpermission-module.json wire--modules--process--processprofile--processprofile-module.json wire--modules--process--processrole--processrole-module.json wire--modules--process--processtemplate--processtemplate-module.json wire--modules--process--processtemplate--processtemplateexportimport-php.json wire--modules--process--processuser--processuser-module.json wire--modules--session--sessionhandlerdb--processsessiondb-module.json wire--modules--session--sessionhandlerdb--sessionhandlerdb-module.json wire--modules--session--sessionloginthrottle--sessionloginthrottle-module.json wire--modules--system--systemupdater--systemupdater-module.json wire--modules--textformatter--textformatterentities-module.json wire--templates-admin--debug-inc.json wire--templates-admin--default-php.json empty lang pack: pw-lang-empty-2.5.zip EDIT: thanks to Nico/Ryan. Updated the lang pack. Now includes 122 files.

In PW 2.4.0, if you add a Page field with a PageListSelectMultiple input type, it works fine unless it's included in a FieldSetTab field, in which case its items cannot be sorted. Moving it out of a FieldSetTab makes the pages sortable again, but the problem repeats if the field is again moved into a FieldSetTab. If anyone can let me know how I can fix this I'd greatly appreciate it. EDIT: I noticed the classes "ui-sortable InputfieldPageListSelectMultipleSortable" are missing from the OL when the page select field is inside the FieldSetTab. I tried adding them through jquery and through the module directly but it still doesn't fix the problem. There are no JS errors being displayed.

Update: Apertus is abandoned in favor of a fork of the far more advanced Admin Theme Reno, "SuperReno". Download the current version on GitHub: https://github.com/marcus-herrmann/AdminThemeSuperReno An AdminTheme meant for developers Still en route to an enhanced version of the Knowledge Base Site Profile I'm now releasing an AdminTheme suited for said profile, sharing its design. This is, as usual, an early, not yet heavily tested release. It is intended to be activated for superusers only, since other themes such as Modesta or the default one are much more apt to customers and editors. Requirements Current ProcessWire 2.4.X Developement version A modern browser (but I think that's the last thing a developer is missing) Download | Project on GitHub Features Some of us work on a large number of ProcessWire installations at once. The following options aim to customize your backends to that extent that you can tell them apart within miliseconds and without looking at the URL. Therefore, within the theme's configuration (meaning: the module's settings), you can change the following: Environment indicator When using a development, staging and production version of a project, use this little switch in the theme's setting to indicate which installation you're currently on. Set main color In order to not confuse installations using Apertus, "color brand" them. Use hex, rgb(a), hsl(a), or named CSS values to your liking, but remember to apply a relatively dark color to prevail contrast. Set project name Lastly, name project backends. Shortcuts Search the forums from within every page of your ProcessWire backend Have all the important API documentation links at hand Check for new modules from every page using the tools upper right (refresh icon) Installation Copy all files from the ZIP archive to your /site/modules/ApertusAdminTheme/ directory. Click "Check for new modules" in ProcessWire Admin Modules screen. Click install for the module labeled: "Apertus Admin Theme". Background The design of this Admin Theme is based on my Knowledge Base Site Profile. Also, it is created to accompany a newer version of said Site Profile. This is the first version of Apertus, not yet heavily tested and therefore bleeding edge. Please use with caution. I named it "Apertus" (latin for open, uncovered) because of the default state of the main navigation (Page, Modules, Access,...). This is a pre-release (0.0.1) needing current dev version of PW to prepare for ProcessWire 2.5. Please help me improving the theme by reporting bugs on GitHub. Thanks! Roadmap Things I intend to implement/change in future versions: Making useful links configurable Proper responsive behaviour Refactoring JS Remove Compass dependency when compiling theme's CSS /edit: Added screenshots clarifying where to find theme's settings

Hi, I was reading a very interesting post in this forum (https://processwire.com/talk/topic/7166-wp-tavern-article-and-processwire-themes/page-4), about PW and its popularity compared to other cms like Wordpress. The key point that has been discussing is: how can PW be more attractive to non developers (ie designers)? (ok here another question arises "Do we want that PW reach an audience bigger that developers only?" but this is another topic...) Wordpress for example has a theming system that certainly is very attractive and quite easy to use, and I noticed someone in the community is already working on a module that could do some steps in that direction. That could be great but there's another thing that in my opinion could help very much: an automatic template file generator. Let me explain... I think that one of the things that scares a person which is not a developer the first time he uses PW, is the fact that after creating some fields and a template that contains these fields from the administration panel, he has to create a new empty file named as the template and put it inside the templates folder. Obviously from a developer point of view this is not a big problem, I go searching the docs and try to find what to put in this file, but from the point of view of a person that has no the developer mental scheme that thing could be scary at the beginning, and I imagine that if this person is trying out a lot of cms to find out which is better for him, he could easily think "ah dawn this is too complicated for me!". Ok, so what if I can, after creating a template, press a button and let the system create the template files for me? This could be great! I can now go to PW tree page, add a page with the template I created before and when I navigate the site I have already a page that is working, and it also outputs the fields that I filled! Then, I go editing the template file that has been created automatically and change the html as I prefer, but I don't have to bother about php code at all... The next step is thinking about a small wizard that create the file when I press the generator button: for example I have to choose if I am creating a simple detail template or a list template. In case of the list maybe we need the user to enter some filter parameters to generate the array list (template type, parent, etc.) and so on... So, this is not a trivial task but maybe not even impossible. In the future you can also think about a way to make this module useful even for developers, for example creating some template for outputting the html of the template files.... But maybe I am going too far So basically I think it could be very interesting to create a module that adds this functionality to PW... What do you think?

Can you please comment/reopen this issue or open a new issue on Github?

@enricob: 1) You do not have to add an alternate template file on a per page basis, you only have to add it once for a newly created template. Don't know how many templates one need for a average site, - I seldom have used more than 10 or 15. 2) I think it isn't a good idea. For example, it is different if a page has a template that has no template file compared to pages that have a template which is assigned a template file. Those pages without a template file cannot be shown on the frontend (because there is no template file that specifies how to generate the output). Such pages have many usecases like for example toolpages etc., or trees and childpages that you need to define categories or tags or whatever. You don't want them accessible through HTTP.

Thank you. Worked like a charm

@woop, it means roughly that instead of modifying files within /wire/modules/Fieldtype/FieldtypeComments/ directly, you'd copy entire FieldtypeComments directory to /site/modules/FieldtypeCommentsExtended/, change classnames etc. there to match that new name and then modify the code per your needs. Modifying code within /site/* is always safer and more future-proof than touching any code within /wire/*.

Ok, now everything is more clear to me. Thanks both for your time. This is really a friendly forum. I'll try to plan the best strategy for me. Probably I will post very soon for other questions Have a nice day

Yes, I like this approach very much. Again, this seems to be an elegant way to handle the flexibility that ProcessWire provides. It's obviously going to take knowledge of how to use ProcessWire by the end user to be able to map the fields correctly, or a range of themes could be accompanied with an install profile. Either way we could achieve standardisation and flexibility all in one. A profile could be created by a theme author specifically as a starting point to test the various themes they supply out. Currently this approach gives a lot of possibilities and permutations in creating themes. It also gives ProcessWire CSS Zen Garden type functionality whereby installing the basic standard profile and then switching themes could provide all sorts of different looks to the frontend. All without too much complexity added, either in the theming system itself or in the individually installed themes. Finally, a designer could use a theme module as a base, copy the files from it into the 'templates' directory. Uninstall the theme module and then use the files they have copied across into the templates folder as the basis for a site that they work on top of. This is then a very nice method for designers to learn how to use ProcessWire with a lower barrier to entry. Even better would be to have a system of overrides with the current theme still installed This is an interesting concept and could help to make a theme more universal. However, would this not bring more complexity and bloat for the end user and theming system? This is also similar (in concept) to how Drupal works as well with multiple and potentially redundant template files that can be overridden. It provides the possibility of a theme being able to cope with new fields and field types being used after initial install. However, it comes at a cost of having to provide field template files for so many different permutations and therefore much higher complexity and overhead when creating the themes.

Having read all these posts popping up lately about this subject, please notify me before processwire is going to be turned into processteer so I can download pw's original latest stable.

Thanks for the install instructions. I guess that's where I went wrong...

Yes, as best practice interface examples. For Drupal, the menu module is a necessity, since all content is in a flat "pool". I guess the same thing goes for Joomla. Overall, my idea is nothing else that a wrapper for a fully native solution, a container for the "virtual tree" approach. But instead of having this subtree in the area editors can access, it's "hidden" sub-"Admin", to keep the tree clean(er). This is not a one-size-fits-all solution or proposition, just an extract of sone my experiences with customers

The thread starts with WP and Drupal screenshots. I just wanted to point out that the menu components of those systems may differ greatly from what you and kongondo intend to implement as a module. And those coming from those systems may be confused. I know that as I came from Joomla and it took some time to start to understand why is there no menu system in PW by default. In fact there is, but it is built in the page-tree. Personally I try to use as many default features as possible while working with ProcessWire. It makes me feel safer and pushes me to learn more of it's API and PHP in general. Thats why I think that "virtual page-tree branch" is preferable approach. But in no way do I deny the possible need for a menu builder module and even can imagine using it myself in some cases.

Though this topic is old enough, let me pick it up again. I also encourage you to move the localization to Transifex. From the view of translators, it is amazing that the translated strings are stored in translation memory, so in the case of an update a translator needn't start his job from scratch, but can leverage the already existing translations. Additionally, it supports team work, so multiple translators can apply for the translation of a project, adding reviewer privilege for the best translators, the quality assurance may be provided. In the case of multiple languages, the challenge of "who is faster" may motivate your translators to complete a job as soon as possible - a kind of international competition.

Another option would be to let the theme define some required fields which you can assign. So you could use already existing fields. And maybe a button to create the rest of the needed fields. Or maybe all fields are optional. Probably I go this way.

I couldn't agree more with Apeisa here. It comes down to a choice: if you want ProcessWire to become popular outside of that group of traditional developer types then you have to appeal to those with 30 minutes to spare and low technical experience. If on the other hand people here are happy to let ProcessWire grow slowly, organically, continually appealing to more technical mindsets then it is doing a great job already and should simply continue on that path. There is nothing wrong with either route and it all comes down to the expectations of the community here. One word of warning about expectations though. I watched the Drupal community grow from version 5, 6, 7 onwards and the bitterness that resulted within the community when WordPress started to dominate the market (around Drupal 6) was palpable. The Drupal community believed that they had a far better system with more flexibility and inherent security, but they were very scathing of the fact that WordPress (sometimes described as 'HerdPress' within the Drupal community) became so popular and Drupal didn't. My point (eventually) is that until very recently (with the advent of Drupal 8) the Drupal community missed the reason as to WHY WordPress was dominating so. They thought it was marketing, but really, it wasn't. The simple reason was that Drupal was engineered for developers and encouraged very little involvement from the design community. I couldn't count the amount of times designers would attempt to engage in the forums and request a simpler theming system only to be sounded out by the developers there - sometimes very aggressively. WordPress on the other hand encouraged the design community and became easy enough for designers with traditional design mindsets to pick up. WordPress actively engaged that audience and a theming system was built that partially catered towards them. Combine the WordPress theming system and an admin interface which is one of the nicer ones to look at and use and you have a package that appeals very strongly to a lesser technical mindset. The whole concept of growth and whether to cater towards the less technical mindset then comes down to choice and expectations. If ProcessWire continues down its current path, it will build a very strong following of developers (and some slightly more technically minded designers). However, it will never grow beyond a certain scale and will always be less popular than many other choices already out there. Again, that's okay if the intention is there to focus on that audience to the exclusion of others. However, the market out there for the designer / CMS administrator type of profile is vast and much larger than that of a development centric audience. It's a simple truth and one which would need to be catered for with better turnkey solutions if ProcessWire wanted to better engage the non technical mindset. The community would also need to welcome them (which I don't think will be a problem from my experience). If ProcessWire wanted to engage and grow its audience to compete with the 'bigger' and more popular systems it's already (in my opinion) in a much better place than Drupal to capture a less technical market. It's API is streets ahead in terms of simplicity for frontend development and it's community is less hardcore. However, some things need to be more readily available to cater towards the designer type who isn't a frontend specialist. A theming system is central to that need (again, in my opinion). The traditional designer mentality is one that is only very slowly moving in a more technical direction (in a typical sense). The Photoshop GUI and knowledge of CSS being as technical as it gets for that type of user. Therefore, having pre-built examples and tools that are easy for a designer to iterate on are essential. Having a packageable theming system would not only help others coming from other systems with ProcessWire, but would enable designers to have less complex starting point to suite different needs. I work with a number of designers coming out of university who still have poor technical skills, they barely know Photoshop to the level that is needed. ProcessWire is unfortunately too great a step for them. Whereas WordPress is easy for them to pick up. In WP they can install a theming base and then iterate from that quickly, they also have plenty of how-to guides catering towards their mindset. Most of the time, they will use a theme base as a starting point for their PHP and XHTML markup and CSS, completely altering the CSS and some of the XHTML, but barely touching the PHP 'voodoo'. However, after a few months they start to become more comfortable with PHP and will then iterate on that layer as well. Then, a frontend developer starts to emerge! They are now very comfortable with WordPress because they have had success with it. Nico's solution I think is perfect for the ProcessWire community. Simple, elegant, potentially very powerful and more importantly optional. When this reaches maturity, you could combine this with a series of tutorials and profiles engineered towards a designer mindset and you have a very simple way to better engage that type of audience and attract them to the ProcessWire project. As a by product of catering for that designer mindset, you then also have the potential turnkey solutions that an even larger audience profile thirst for...

So many times I've worked into the evenings and been stuck on an issue for hours. The answer almost always comes to me as I'm standing in the shower the next morning, then I look at the code (Data - haha) and do this:

The table name should be: ProcessRedirects - so you should be able to just rename it using PHPMyAdmin or via SQL command line. It is created here: https://github.com/apeisa/ProcessRedirects/blob/master/ProcessRedirects.module#L326 Did you move from Windows to Linux? Names are not case sensitive on Windows, but they are on Linux? Still, not sure why it would have been created in lowercase in the first place, given the code that creates the table.

I have hard time understanding the real benefits redactor offers over ckeditor? I mean the acf, plugin architecture and already available plug-ins, inline mode, easy of settings/modification etc are very well done in ckeditor. Is it better looking and few kilobytes smaller? The size is not really an issue imo, since js is cached anyways. Also really pleased to see all the small improvements Ryan has implemented into ckeditor inputfield, which make the usage even simpler.

You have me thinking - I bet I could have Migrator create these automatically, so long as the Redirects module is installed I'll look into it.

Really like the page. Great layout and it's clear what they do. One small suggestion: Maybe you could replace the logo on the top-left with a retina/high resolution one? Everything else on the site looks nice and clean on my macbook. (Yes, I know. People with high density screens are the minority but we're growing fast )

Guys, Sorry I have been rather quiet in the recent past. You may have noticed I am in holiday mode and have been following, rather keenly, the trajectory of a certain spherical leather object ....Two more weeks to go and I should be back in play....(forgive the pun )

Franko, Sorry to hear you are having problems implementing Blog. Apologies, I have not had time to write the documentation. It is however quite easy to fit Blog in any design. The reason for the 'many' template files is explained in several posts in this thread . In a nutshell, the many template files have nothing to do with the module; they are only examples, are necessarily verbose and are meant to showcase the methods/functions available within MarkupBlog. Blog is a module and you can call it anywhere, any time you want in your template files. I will write up what its methods do and how to use them when I get some time.

Kongondo. I am in awe! WOW, WOW, WOW!!! My mouth has dropped to the floor and my prayers have been answered! This has been designed so beautifully, logically, and intuitively :'(You are super talented my friend. This is something that has been needed for quite some time. Thank you so much for this!!! I'm speechless.

Seriously? If yes, out of the box, no. But with some trickery, you can have MarkupBlog output posts from only a particular author, assuming each author has their own blog. I am just thinking out loud here. If this is a feature request, I'd like to have more details but also hear what others think Glad you like the module.

I love it when someone posts something as amazing as this! Another one where simply clicking 'Like' is nowhere near enough. Thank you Kongondo, this is an exceptional contribution.

Hi Beluga, Thanks for sharing that link. Very interesting. I've made a basic PM tool using PW, I'll be expanding it little more for a client's project. I'll post it here once it's ready. For now it's just a simple task management system. If anyone's interested, feel free to contact me, I've a demo online which I'm using to manage my company's projects. Have a great day!

Create an account on transifex and I add you into a project. It seems to be a very nice tool for doing translations in collaboration. Translations are easiest way for many people to "give back", and current way isn't very easy to get started. In github model you don't even see the original strings, which makes it clumsy. I think that tool like Transifex would lower the barrier to contribute and manage translations.

Another (huge) one is Transifex But the bad thing is that none actually support the format for the translations that Processwire uses: File formats on transifex File formats on getlocalization

Slightly longer explanation is that it's a problem with scope; you might want to take a closer look at PHP manual entry about variable scope. Essentially you need to use wire() (which is a function) instead of $input (which is an object and thus subject to same scope rules as variables) when you're in the context of a function. You could also pass the function a copy of (or reference to) whatever object or variable you want: function fDtest($input) { if(isset($input->urlSegment1)) echo ":)"; else echo ":("; } echo fDtest($input); .. but that's probably not what you want here. Anyway, hope this helps clear things out a bit Edit: removed reference sign from function call, that way of using references has been deprecated in PHP 5.3.0 and removed from 5.4.0.. and it wasn't even necessary step here, since in PHP 5 objects are by default passed by reference (kind of.) Because of this you need to be very careful when making any changes to objects such as $input inside a function since it'll affect global scope too. To pass an object by value you'd need to use clone instead. Variables, on the other hand, need to be prefixed with reference sign "&" in function definition in order to pass them by reference -- by default they're passed by value.. Thanks to @Nik for pointing these out, my information was outdated!

Hey Alan, I think it is just that you need to use wire('input')-> when inside a function.

Thanks for posting Soma, this is an interesting approach and not one I've seen before, but it looks great. The underlying concept and result is similar to the approach I usually use. Since you posted a good description, I'll try to do the same for mine. The only reason you see head/foot files in the default PW profile is because it seems to be simpler for new users to grasp. But I almost never use that approach in my own sites. Like your system, I have a main.php file which is my main markup file. But unlike your system, main.php is included from all the other template files (rather than main.php including them). The other template files focus on populating the key content areas of the site, specific to the needs of the template. Examples of key content areas might include "main" (for center column/bodycopy) and "side" (for sidebar/related info), though often includes several other identified areas. But I'll keep it simple in this case. Here's how it works: basic-page.php <?php $outMain = "<h2>{$page->subtitle}</h2>" . $page->body; if($page->numChildren) $outMain .= $page->children->render(); // list the children $outSide = $page->sidebar; include("./main.php"); main.php <html> <head> <title><?php echo $page->title; ?></title> </head> <body> <h1><?php echo $page->title; ?></h1> <div id='main'><?php echo $outMain; ?></div> <div id='side'><?php echo $outSide; ?></div> </body> </html> The benefit of this approach is that basic-page.php can setup whatever it wants in the key content areas ($main or $side) whether simple like in this example, or something much more complex. I actually prefer for the variables representing the key content areas to be optional. In the scenario above, $outMain and $outSide would have to be defined by every template or they would end up as uninitialized variables in main.php. As a result, I actually use $page as an anonymous placeholder for these variables (making sure they don't conflict with any existing field names) and then let main.php assign defaults if the calling template didn't specify one of them. For example: basic-page.php <?php $page->outMain = "<h2>{$page->subtitle}</h2>" . $page->body; if($page->numChildren) $page->outMain .= $page->children->render(); // list the children // note: no $outSide specified include("./main.php"); main.php <?php // setup defaults when none specified if(empty($page->outMain)) $page->outMain = $page->body; if(empty($page->outSide)) $page->outSide = $page->sidebar; ?> <html> <head> <title><?php echo $page->title; ?></title> </head> <body> <h1><?php echo $page->title; ?></h1> <div id='main'><?php echo $page->outMain; ?></div> <div id='side'><?php echo $page->outSide; ?></div> </body> </html> Final thing to point out here is that main.php is the only template actually outputting anything. Because basic-page.php (or any other template) is determining what's going to go in that output before it is actually sent, your template has the opportunity to modify stuff that you might not be able to with other methods. For instance, the <title> tag, what scripts and stylesheets are loaded, etc. Here's the example above carried further to demonstrate it: basic-page.php <?php // make a custom <title> tag $page->browserTitle = $page->rootParent->title . ": " . $page->title; $page->outMain = "<h2>{$page->subtitle}</h2>" . $page->body; if(count($page->images)) { // display a clickable lightbox gallery if this page has images on it $config->scripts->add($config->urls->templates . "scripts/lightbox.js"); $config->styles->add($config->urls->templates . "styles/gallery.css"); $page->outMain .= "<ul id='gallery'>"; foreach($page->images as $i) { $t = $i->size(100,100); $page->outMain .= "<li><a href='{$i->url}'><img src='{$t->url}' alt='{$t->description}' /></a></li>"; } $page->outMain .= "</ul>"; // add a note to $page->title to say how many photos are in the gallery $page->title .= " (with " . count($page->images) . " photos!)"; } if($page->numChildren) $page->outMain .= $page->children->render(); // list the children include("./main.php"); main.php <?php // if current template has it's own custom CSS file, then include it $file = "styles/{$page->template}.css"; if(is_file($config->paths->templates . $file)) $config->styles->add($config->urls->templates . $file); // if current template has it's own custom JS file, then include it $file = "scripts/{$page->template}.js"; if(is_file($config->paths->templates . $file)) $config->scripts->add($config->urls->templates . $file); ?> <html> <head> <title><?php echo $page->get('browserTitle|title'); // use browserTitle if there, otherwise title ?></title> <?php foreach($config->styles as $url) echo "<link rel='stylesheet' type='text/css' href='$url' />"; foreach($config->scripts as $url) echo "<script type='text/javascript' src='$url'></script>"; ?> </head> <body> <h1><?php echo $page->title; ?></h1> <div id='main'><?php echo $page->get('outMain|body'); // use outMain if there, or body otherwise ?></div> <div id='side'><?php echo $page->get('outSide|sidebar'); // use outSide if there, or sidebar otherwise ?></div> </body> </html> More than half the time, I'll actually just re-use page variables like $page->body and $page->sidebar rather than $page->outMain and $page->outSide. That way there's no need to consider defaults, since $page->body and $page->sidebar untouched technically are defaults. <?php $page->body = "<h2>{$page->subtitle}</h2>" . $page->body . $page->children->render(); But technically you've got a little more flexibility using your own self-assign anonymous variables like outMain and outSide, so figured I'd use that in the examples above. outMain and outSide are just example names I came up with for this example and you could of course name them whatever you want.