Leaderboard

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

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

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...

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.

Hi Nico, this is a very interesting development and perfect for a particular use case I have in mind right now. Your solution is very simple and elegant so far. I see your problem with regards to ProcessWire's flexibility and I think the ProcessMigrator json file would be the best approach. How possible would it be for each theme module to have its own ProcessMigrator json file that could be used (as an optional step) to import fields used in the template? In this scenario you would install a particular theme module and then decide on whether you wanted to also install its field sets that guarantee a workable setup (or a bit of a blank slate). Using a system like this would enable theme authors to create truly packageable themes whereby they can create themes for specific use cases and be able to guarantee that the fields are available in the system. The difficulty would obviously be that you're giving a lot of control to the theme modules and something would have to be done to ensure that a users site is decimated or bloated by the newly installed theme. In other words the theme module could easily provide too much unnecessary and complicated functionality as with other CMS options out there - yes, I'm looking at you WordPress. Another interesting possibility would be to enable a system of overrides somehow, whereby any template files could be overridden from the installed theme module by creating an equivalent file in the templates directory in PW. This would then allow customisation of any theme modules and allow the theme module to be updated without losing the customisations. Or instead of this approach, a child theming system could be created where a child theme module could have a parent theme dependency, again, allowing a child theme to override the parent one. Just a few thoughts

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!

Hi zwergo, great project. Thank you for sharing. A lot to learn from your code. I'm really happy that I could convince you to take another look at PW as the right tool for your project. Cheers Gerhard

@pideluxe: agreed. That (basic theme groundwork) is exactly what I've been trying to suggest all along.. and exactly what Nico is doing with WireThemes project, so we're definitely on the same page here. I don't see having (more) 3rd party site profiles and/or themes (whatever you call them and however you put them together) as something that would seriously harm ProcessWire as a project, but that's just me Also, anyone repeating the "themes shouldn't be in core" mantra, take a closer look at this discussion: unless my memory is failing me, no-one has suggested such a thing. We're discussing third party themes here. Please don't get dragged into pointless argument over whether customisable, interchangeable themes should be in core -- they shouldn't, period.

It's really easy with "Terminal" to get all the translatable files. Just open the root dir of your ProcessWire installation in the terminal ("cd /YOUR/DIR/PATH/" or drag'n'drop the folder onto the terminal.app icon). Then entering the following line: grep -lr '__(\|$this->_(' * grep search command -l only show filenames -r recursive '__(\|$this->_(' search term with OR ( \| ) condition * the folder you want to start the search in. because we are already in the folder because of "cd" we can use the asteric My result on PW 2.4.9: wire/core/AdminTheme.php wire/core/Field.php wire/core/Fields.php wire/core/FieldSelectorInfo.php wire/core/Fieldtype.php wire/core/FieldtypeMulti.php wire/core/Functions.php wire/core/Inputfield.php wire/core/InputfieldWrapper.php wire/core/LanguageFunctions.php wire/core/Modules.php wire/core/Pagefile.php wire/core/Pageimage.php wire/core/Pages.php wire/core/Password.php wire/core/Session.php wire/core/SessionCSRF.php wire/core/Wire.php wire/core/WireCache.php wire/core/WireHttp.php wire/core/WireUpload.php wire/modules/AdminTheme/AdminThemeDefault/AdminThemeDefault.module wire/modules/AdminTheme/AdminThemeDefault/AdminThemeDefaultHelpers.php wire/modules/AdminTheme/AdminThemeDefault/default.php wire/modules/Fieldtype/FieldtypeComments/CommentFilterAkismet.module wire/modules/Fieldtype/FieldtypeComments/CommentForm.php wire/modules/Fieldtype/FieldtypeComments/CommentList.php wire/modules/Fieldtype/FieldtypeComments/FieldtypeComments.module wire/modules/Fieldtype/FieldtypeComments/InputfieldCommentsAdmin.module wire/modules/Fieldtype/FieldtypeDatetime.module wire/modules/Fieldtype/FieldtypeFile.module wire/modules/Fieldtype/FieldtypeFloat.module wire/modules/Fieldtype/FieldtypeModule.module wire/modules/Fieldtype/FieldtypePage.module wire/modules/Fieldtype/FieldtypePageTable.module wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module wire/modules/Fieldtype/FieldtypeRepeater/InputfieldRepeater.module wire/modules/Fieldtype/FieldtypeSelector.module wire/modules/Fieldtype/FieldtypeText.module wire/modules/Fieldtype/FieldtypeTextarea.module wire/modules/Fieldtype/FieldtypeURL.module wire/modules/Inputfield/InputfieldAsmSelect/InputfieldAsmSelect.module wire/modules/Inputfield/InputfieldButton.module wire/modules/Inputfield/InputfieldCheckbox.module wire/modules/Inputfield/InputfieldCheckboxes/InputfieldCheckboxes.module wire/modules/Inputfield/InputfieldCKEditor/InputfieldCKEditor.module wire/modules/Inputfield/InputfieldDatetime/InputfieldDatetime.module wire/modules/Inputfield/InputfieldEmail.module wire/modules/Inputfield/InputfieldFieldset.module wire/modules/Inputfield/InputfieldFile/InputfieldFile.module wire/modules/Inputfield/InputfieldFloat.module wire/modules/Inputfield/InputfieldForm.module wire/modules/Inputfield/InputfieldHidden.module wire/modules/Inputfield/InputfieldImage/InputfieldImage.module wire/modules/Inputfield/InputfieldInteger.module wire/modules/Inputfield/InputfieldMarkup.module wire/modules/Inputfield/InputfieldName.module wire/modules/Inputfield/InputfieldPage/InputfieldPage.module wire/modules/Inputfield/InputfieldPageAutocomplete/InputfieldPageAutocomplete.module wire/modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelect.module wire/modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelectMultiple.module wire/modules/Inputfield/InputfieldPageName/InputfieldPageName.module wire/modules/Inputfield/InputfieldPageTable/InputfieldPageTable.module wire/modules/Inputfield/InputfieldPageTable/InputfieldPageTableAjax.php wire/modules/Inputfield/InputfieldPageTitle/InputfieldPageTitle.module wire/modules/Inputfield/InputfieldPassword.module wire/modules/Inputfield/InputfieldRadios/InputfieldRadios.module wire/modules/Inputfield/InputfieldSelect.module wire/modules/Inputfield/InputfieldSelectMultiple.module wire/modules/Inputfield/InputfieldSelector/InputfieldSelector.module wire/modules/Inputfield/InputfieldSubmit/InputfieldSubmit.module wire/modules/Inputfield/InputfieldText.module wire/modules/Inputfield/InputfieldTextarea.module wire/modules/Inputfield/InputfieldURL.module wire/modules/Jquery/JqueryWireTabs/JqueryWireTabs.module wire/modules/LanguageSupport/LanguageParser.php wire/modules/LanguageSupport/LanguageSupport.module wire/modules/LanguageSupport/LanguageSupportFields.module wire/modules/LanguageSupport/LanguageSupportPageNames.module wire/modules/LanguageSupport/LanguageTabs.module wire/modules/LanguageSupport/ProcessLanguage.module wire/modules/LanguageSupport/ProcessLanguageTranslator.module wire/modules/Markup/MarkupPageFields.module wire/modules/Markup/MarkupPagerNav/MarkupPagerNav.module wire/modules/PageRender.module wire/modules/Process/ProcessField/ProcessField.module wire/modules/Process/ProcessForgotPassword.module wire/modules/Process/ProcessHome.module wire/modules/Process/ProcessList.module wire/modules/Process/ProcessLogin/ProcessLogin.module wire/modules/Process/ProcessModule/ProcessModule.module wire/modules/Process/ProcessPageAdd/ProcessPageAdd.module wire/modules/Process/ProcessPageClone.module wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module wire/modules/Process/ProcessPageEditImageSelect/ProcessPageEditImageSelect.module wire/modules/Process/ProcessPageEditLink/ProcessPageEditLink.module wire/modules/Process/ProcessPageList/ProcessPageList.module wire/modules/Process/ProcessPageLister/ProcessPageLister.module wire/modules/Process/ProcessPageSearch/ProcessPageSearch.module wire/modules/Process/ProcessPageSort.module wire/modules/Process/ProcessPageTrash.module wire/modules/Process/ProcessPageType/ProcessPageType.module wire/modules/Process/ProcessPageView.module wire/modules/Process/ProcessPermission/ProcessPermission.module wire/modules/Process/ProcessProfile/ProcessProfile.module wire/modules/Process/ProcessRole/ProcessRole.module wire/modules/Process/ProcessTemplate/ProcessTemplate.module wire/modules/Process/ProcessUser/ProcessUser.module wire/modules/Session/SessionHandlerDB/ProcessSessionDB.module wire/modules/Session/SessionHandlerDB/SessionHandlerDB.module wire/modules/Session/SessionLoginThrottle/SessionLoginThrottle.module wire/modules/System/SystemUpdater/SystemUpdater.module wire/modules/Textformatter/TextformatterEntities.module wire/modules/Textformatter/TextformatterMarkdownExtra/markdown.php wire/templates-admin/debug.inc wire/templates-admin/default.php wire/templates-admin/topnav.inc (Inspired by Manfred62's post: https://processwire.com/talk/topic/7245-translation-for-pw-25/)

Ok, apparently this is called auto-pairing, and I finally disabled it by adding "this.ace.setBehavioursEnabled(false);" in site/modules/adamkiss-InputfieldAceEditor-16d5afe/InputfieldAceEditor.js at line 57 (i.e. just before "this.ace.getSession().setUseWrapMode(true);", but I guess any line around is fine).

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

Content of $page is always the page you are currently on. In the case of visiting the home page, the fields blog_images and blog_summary do not exist, since its another template ("home", I guess). But there's a solution: $pages, the entirety of your, well, pages. In this case you "just" have to filter by template blog-post: $blogposts = $pages->find("template=blog-post"); and then: foreach ($blogposts as $b) { echo "<img src={$b->blog_images->first()->url} />"; echo "<p>{$b->blog_summary}</p>"; }

This is easy as: <ul class="thumbs"> <?php $images = $page->blog_images; foreach ($images as $image) { $thumb = $image->size(106, 106); // or whatever your thumb dimensions are echo "<li><a href='$image->url' class='fancybox'><img src='$thumb->url' alt='$image->description'></a></li>"; }?> </ul> Assumptions for this code snippet: You will be styling .thumbs via CSS to get the grid style output You are using $(".fancybox").fancybox(); as a trigger

I'm going to have to start working earlier in the evening. cheers

I don't think I am missing anything here. Isn't it as simple as echo'ing $t->id ? You have t->id

hi guys, i'm happy to show you my first project realised with processwire and to say hi the first time here in the forum, although i have been reading, following, learning and liking around here for some weeks now the reason why i did not post any questions is quite simple: all answers for my questions have already been posted (and answered) in the forum/wiki/docs - really great! let me also say thanks to gebeer, who forced me to take a second look to processwire (coming from joomla/seblod and thinking processwire is not worth the effort of changing from a well known system - i was so wrong ^^) So what is "GeoWire"? (http://www.geowire.org) GeoWire is a web mapping tool for creating and sharing web-maps. It's a bit similar to google maps, but you can put your own maps (also all the google layers) and overlays into it and create your own functionality with javascript. First it was a "static" HTML/JS project but within the weeks of development gebeer told me about processwire. So in the end i had my HTML/JS web map viewer ready and thought how great it would be to manage all the code snippets directly on the server with processwire as GUI - you could easily copy your map collocations, drag and drop layers in the layer tree, drag&drop buttons in the toolbar and so on... 2 days later i had the first working prototype ready!!! PW is just wonderful, thank you Ryan+Team! Today i - finally - finished the video tutorials for GeoWire which i published as an open source web mapping tool. Oh man, that sounds so arrogant for me - i'm not a professional developer and i know it is far from perfect, but at least i wanted to give it a try . I would have also put it to GitHub, but i have no experience with it till now and so it was too complicated for me. I hope I am not violating PW by providing GeoWire for download on my website geowire.org? I don't even know if anybody is interested in geowire at all, but maybe it can at least serve as starting point for any other similar projects... any feedback is appreciated. Here is the demo: http://www.geowire.org/demo Maybe you're interested in the videos: The Backend: http://www.youtube.com/watch?v=8sgq8GPYDYo How it works: http://www.youtube.com/watch?v=vxMtAQsKESY How it works in short by an example: The mapPanelToolbar makes this out of that using that code snippet, /* ######################################## ######## mapPanelToolbar.js ######################################## */ Ext.onReady(function() { mapPanelToolbar = Ext.create('Ext.toolbar.Toolbar', { dock: 'top', items: [<?php foreach($page->children as $child) { if($child->include_file) { include('GeoWire/include/'.$child->include_file); echo ','; } echo $child->include_direct.','; } ?>] }); }); that is recursively loaded by the processwire template // create javascript app file from all included code snippets ob_start("makefile"); // include all children of current page foreach ($page->children as $child) { include_file($child); } ob_end_flush(); function makefile($buffer) { if(!wire('config')->dev) { include('GeoWire/JSMin.php'); $buffer = JSMin::minify($buffer); } // take first map if it is homepage $pageid = (wire('page')->id == 1) ? wire('page')->child->id : wire('page')->id; file_put_contents("GeoWire/app".$pageid.".js", $buffer); } happy processwiring and good night Edit: Do you think something like this would be possible or even better put into a module? I know my first version of geowire will soon be outdated as it uses PW2.4 as core, but for the time it was the best way to go and to be honest, i don't know when/if i have the time/motivation to develop this project in future...

Here's a video of a module we're working on that I thought you guys might like. The module, Lister, provides a different type of Page List than the tree that you usually interact with in ProcessWire. It gives you a table of pages with customizable columns, filters and actions. Rather than try to explain what it does, I figured I'd show you. This module also uses a new (soon to be released) Inputfield invented by Apeisa, developed by me, and sponsored by Avoine, called InputfieldSelector – it's what you see on the configuration screen as well as the Filters tab. I recommend bumping up the size/quality to 720p so that you can properly see everything. The video has no sound... I tried to do one with narration, but that didn't work out.

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/

Hi Daerias Here is a generic tutorial explaining how to add ANY framework to ProcessWire - it is remarkably easy, indeed, there really is no proper need for my profile at all! http://processwire.com/docs/tutorials/installing-a-css-framework/ Joss

Hmm. I think I see whats happening. Youre basically saying "for each page that uses blog-post as a template, output X". I just realised my output isn't creating a new row for each blog post so I modified it to be as follows. <!-- START Nested Column containing featureimage and post-summary --> <?php $blogposts = $pages->find("template=blog-post"); foreach ($pages->find("template=blog-post") as $b) { echo " <div class='row'> <div class='small-12 large-6 columns'><img src={$b->blog_images->first()->url} /></div> <div class='small-12 large-6 columns'><p>{$b->title}</p><p>{$b->blog_summary}</p></div> </div> "; } ?> <!-- END Nested Column containing featureimage and post-summary -->

What about: foreach(array('guest', 'customer') as $r) $u->addRole($r); Still, I don't see any reason to add the guest role manually, so if you are only adding one other additional role, then you probably don't need anything to reduce multiple lines. It seems like maybe something changed recently. What version of PW are you running? If I test on 2.4.5 the guest role is automatically added, but not in 2.4.11 - https://github.com/ryancramerdesign/ProcessWire/issues/588 Wow - I am having a rough morning - nothing has changed - behavior seems to be consistent through versions.

Thanks so much, Marcus. I'll try that later. I know with my "usual" CMS I could achieve this in about 15 - 30 mins so it's great to see it's as easy within PW

No it's not possible in your syntax: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/User.php#L62 But you could do it like this (I think): $u->addRole("guest")->addRole("customer");

Hello there, I'm the author of the article on WPTavern, the infamous 30 minute trial article! I figured it would be nice to go to where the conversation is versus the other way around. So if you have any questions for me regarding my experience or anything else for that matter, I'm registered to the forum, but wouldn't want to derail the purpose of this thread. Also, thank you to those who have responded to the article in a respectful manner. I'm sure some of you think my article is like someone taking a crap on the project which is not what I did. The article is a simple documentation of my efforts to use and learn about the platform in 30 minutes in which case, that's all it took for me to decide it wasn't for me. The question is, how many people find ProcessWire, install it, and don't even give it 30 minutes before reaching the same conclusion? Is that even a concern or are those the people you don't want as part of your userbase anyways? Anyways, I'm happy to start a new thread specifically about my article or if someone else wants to do it. *** Moderator *** This topic was splitted from here. the original article that is discussed here can be found from here. -apeisa

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:

new german updates for actual PW dev 2.4.11 (09 August 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--core--functions-php.json wire--core--wirehttp-php.json wire--modules--fieldtype--fieldtypefile-module.json wire--modules--process--processmodule--processmodule-module.json added files: wire--modules--inputfield--inputfieldpagetable--inputfieldpagetableajax-php.json wire--modules--inputfield--inputfieldpagetable--inputfieldpagetable-module.json wire--core--wirecache-php.json wire--core--pageimage-php.json wire--core--fields-php.json pw-lang-de-dev-update.zip

Very impressed Good luck

Regarding Themes in ProcessWire: https://processwire.com/talk/topic/7236-wirethemes/

I agree with OrganizedFellow, that templates and themes should be separated from core. But it should be made easier for a not so tech-savy webmaster/developer, to install profiles (= themes) and to customize them to their needs. To accomplish this, i would suggest the following: develop ready-to-use profiles (maybe these could be named "PROfiles"?) for the most demanded website-types, e.g. coprorate site, blog, gallery, portfolio, shop, ... make it possible to install PROfiles side-by-side and as easy as installing modules, so that a corporate site could easily extended with a blog by installing the blog-profile proceed the fields/templates for each profile with a separate tag, e.g. all fields for a corporate site are prefixed with "corp_" + field name (except title-field or maybe others) all these PROfiles should be based on the same css-framework, i would suggest foundation, as ryan used it already for a profile. this makes it easier to use different PROfiles together with consistent styling PROfiles should use minimal styling. But maybe different CSS-styles could be made available for color-schemes or similar the templates should contain layout-files for special parts of a page (think of widgets or partials), so that developers could easily reuse these parts to create their own templates (e.g. on a corporate site display a list of the lastest blog-entries in the sidebar) PROfiles settings should be made available on one admin-page, maybe each Profile get its own tab (or whatever ui fits best), where the respective settings are shown As one conclusion, this makes it necessary, that markup is generated by the PROfile for outputting the content. I already hear the complaints about that this is not what is processwire intended for, thats right. But this is totally optional, not in core and you mustn't use it at all, you still could use your own code. It only would make it easier, even for developers, to get started with processwire by installing already tested and optimised profiles by processwire pros. There should be a PROfile-team for maintaining and ensuring consistency of things throughout the distinct PROfiles.

Quite a few hosts sell SSL certs far cheaper than you cam buy them directly from SSL companies and they're the same certs. I won't name-drop, but you can get a $249 cert (2048-bit encryption and some other fancy features) for less than half that price from one webhost, so you could choose to see this as a chore or you could ask your host to install it for your clients which will take them a short space of time and be auto-renewed along with the hosting so there's no major headache for you. You can choose to pass the whole discount on to customers or, quite reasonably, add a little markup for the time it's cost you but still come in a lot cheaper than buying a cert straight from the cert providers. Everybody wins and the internet is a little bit more secure with each site that switches

If you all read and review carefully, you'll notice that Ryan has not posted but has "Liked" many comments and replies here. He is very well aware of your opinions and wishes - as he always has!!! He's the one that adds all the valuable core necessities. I think it is awesome beyond awesome that we have such a leading developer that tailors HIS project to OUR wishes. The idea of templates and site profiles is a good one. They already exist! Not as simple as "One Click". But if you are a developer, designer, web oriented tech savvy person, it's just as simple to download a site profile and extract into the appropriate folder. This "One Click Theming" idea was made insanely popular by the folks that made WordPress, and frankly it is something that ProcessWire should probably avoid! Personally: I don't need it. I don't want it. So far, every ProcessWire site I have created has been 100% totally custom. The ONLY thing that I have reused or duplicated is my beloved Foundation CSS framework. Other than that, the sites are completely different, different jQuery plugins, different ProcessWire modules, different everything. When I think of templates, I think of these: http://foundation.zurb.com/templates.html If Ryan and the rest of the ProcessWire team should lean towards the way of offering templates and themes, then they should offer a small variety of layouts with different content. A generic Blog template could have title, author, publish date, summary, images fields, etc. with comments or without?! A generic Orbit template could have title, image url, image description, etc. for various images. A more advanced Realty template could have address, phone numbers, map coordinates, various images, etc. A search feature. A simple drag and drop prior to installation. And then when installed, all the fields and templates would be prefixed with an easy to distinguish name to connect them all together, so noobies can see how it all works. There are so many ways to do things in ProcessWire (it's a beautiful thing - ain't it?). Templates and themes shouldn't be any different. Keep it out of the core. Contributing users can offer their own site profiles (as they already do on girhub/elsewhere). Provide a nice interactive click through demo on their own site, or demo.processwire.com/template=?XYZ

Don't Show API Form Labels (If I may add this here for the sake of completeness.) I have been looking for a way to leave the label out of the markup that does not involve recreating a module (a silly thing to do). The solution we have been using up until this point was a blank label. (Resulting in unnecessary markup and a negative margin.) However curiosity took me to the Inputfield module. Hey great job on these fields BTW. Reading the file I came across these options. const skipLabelNo = false; // don't skip the label at all (default) const skipLabelFor = true; // don't use a 'for' attribute with the <label> const skipLabelHeader = 2; // don't use a ui-widget-header label at all const skipLabelBlank = 4; // skip the label only when blank // wire/core/Inputfield.php Found in: in Inputfield.php The best solution I found to use this in a form builder. (I would like to credit this to somma's comment on checkbox-other-text-in-header-than-label-text) //controller.php $submit = $modules->get("InputfieldSubmit"); $submit->skipLabel = Inputfield::skipLabelBlank; //HERE IS THE SOLUTION! $submit->attr("value","SUBMIT"); $submit->attr("id+name","submit"); $submit->attr("class","button"); $form->append($form_submit); Thank you Somma! Thank you Ryan!

There is also this plugin for CKEditor: http://ckeditor.com/addon/mathjax As of yesterday's PW dev version, external CKEditor plugins are supported and very easy to manage: https://github.com/ryancramerdesign/ProcessWire/commit/4b12d2e4f2ceb7eebb52261e723a847e08c8a569

I totally agree. Especially in Germany, TYPO3 has that weird reputation of being the best and most professional CMS/F in the room, although I perceived it on the editor/usability- and templating-side as unnecessarily complex (I tend to think that the service ecosystem that developed around this complexity tries to keep it that way). Since both TYPO3 and ProcessWire are relatively big here in Germany (each on their own scale) one could emphasize the "also a perfect business CMS" aspect on http://de.processwire.com even more Communication-wise, there's plenty to learn from the big fishes. /edit: I started a new thread on this topic since it's not really related to the WP tavern article: https://processwire.com/talk/topic/7184-lets-highlight-processwires-ability-to-be-an-enterprise-cms/

I want to like this post multiple times but the forum software doesn't allow me to do that. So: Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Honestly: It's comparing apples to oranges. PW is strong. It is the most intuitive, the best designed (in terms of API and UI) CMS out there with the smallest footprint possible. I recently used again the multi language support. I mean, look at the API. Look at the solution for a problem each CMS has. It is just beautiful. You have several ways to solve that problem (as always with PW). But it is there, written in the core, well documented on one(!) API page, because it just works intuitively, it is just simple. Every addition to the core is an addition which solves general problems and the way Ryan solves them is just genius. There is no addition you have to scratch your head when reading the new API. You always think: "wow, clever". And this is the way to go with the core. Make it simple, make it smart, make it beautiful! Regarding themes, profiles and such: It is already possible. It is out there. Provide a custom profile for a real estate agent: Give him a set of modules, fields and templates to handle his offers. This is no problem! This is even easier and more flexible than it ever will be in WordPress, because it goes way beyond a custom theme and can be installed with one click. But: Nobody will care at the moment, because ProcessWire has no own category in theme/template websites, because ProcessWire has not the attention of other plug&play systems. And this is totally okay! Think of TYPO3, a widely spread system, mostly used in enterprise environments and even on small sites (dunno why), but the point is: Everyone (at least in Europe) knows it, it is one of the most used systems in the business sector (not on private children soccer club websites). But: this is the goal! Be the system developers use. Don't be the system every idiot wants to use. Concentrate on performance, flexibility and most of all: beauty of the API! The rest will follow.

Well, I have spend under 30 minutes reviewing many systems. If it doesn't meet any of the expectations, then 30 minutes is more than enough. I find Jeff's article pretty good - I would assume that first impression is pretty much that, if you just wander around admin and look for buttons that do cool things for your site. If we want to go after big wp audience, then we would really need to focus on things like themes, plug and play modules etc. I would keep our audience where it is (people who are build websites, rookies and experienced). When developers are in, the rest will follow.

Hi there, Nick, and welcome to the forum! PW can handle this, but this isn't something any single module alone will do for you. It'll require custom code work, the amount of which depends a lot on how many users you'll have, whether you're prepared to create user accounts and connect them to editable pages manually or if you need to automate registration, how customised you want edit views for these clients to be etc. Below I'll try to describe three possible approaches you might use to make this work: 1. Keep client's user profiles (i.e. user accounts, which in ProcessWire are also pages) and publicly viewable product/info pages separated. Each user would have an account to your site but also separate, publicly viewable page he/she can edit. For this approach, I'd start with Page Edit Per User module, which allows you to define pages that specific user (one with no access to edit any pages by default) can edit: /clients/ # public part of your page /client-x/ /client-y/ /client-z/ # page for client z: publicly viewable info, products etc.; # after logging in, client z can edit this page /processwire/ # ProcessWire admin area /access/ /users/ /client-x/ /client-y/ /client-z/ # user account for client z: not publicly viewable; after # logging in, this client can edit page /clients/client-x/ 2. Add product information etc. custom fields directly to user's profile pages and then render those publicly. The problem with this approach is that all your users, including superusers, will have these custom fields, which might not make sense in your case (if you need other type of users later, it's going to be very confusing). Also, you'll still need public URLs for the profiles -- not much of a problem though, as you can always create a template that fetches user (like Pete descried in the thread linked to above), either based on a GET param or URL segment. If you go with this, be very strict with validation, i.e. before rendering user page make sure it's one that should be rendered, i.e. one of your clients and not, say, superuser account. 3. If you're confident in your skills with code, you could also create a Process module (a new view/tool for Admin area) that your clients use to handle their products. This would, essentially, be a custom-built CRUD tool for managing user-specific pages. This thread provides some useful pointers for this. Using this approach it would actually make sense to include basic info as custom fields on user profiles as explained above and creating separate pages only for products these clients sell (assuming that there's more than one product per each client). Hope I didn't confuse you too much with this -- please don't hesitate to post any questions this raises and/or you still have. Would be happy to clarify. I'd strongly suggest that you start building this thing and then ask once you face any specific issues.. the more you can limit the scope of your question, more likely you are to get a swift and precise answer

Its a nice little bit of real life: "Hey, information? I lost my socks." "They are behind the sofa" "Thanks." With data, there should always be the equivalent of "behind the sofa" somewhere.