Leaderboard

I look forward to getting ProcessWire compatible with Composer. That's one of the things I'd wanted to do with 2.4 though other priorities for ProcessWire have gone ahead of it and likely won't be supporting it till after 2.4, but hopefully soon after. We may need to make changes to directory structure, but I'm averse to doing anything major there as I think we need to give priority to what's best for the web sites that ProcessWire powers over what's best for Composer. But we'll do what we have to do, just always in the context of our intended audience over Composer's (which have crossover, but are also different in many ways). Our audience veers much further towards web developers than dedicated PHP coders. Most of our audience is not integrating multiple PHP projects, but we do want to better support the few that are. 2.4 development is pretty much finished. Just trying to work out all the bugs before releasing it. Though I think it is already just as stable as 2.3 for the most part. I am also very interested in evaluating PSR-4 for ProcessWire. With regard to PSR-2, I'm less enthusiastic. Standards are great, and I support the PSR-2 standard for new projects looking to adopt a standard. But I think it's silly for projects that have already adopted a standard, as PSR-2 is a lot of compromise. ProcessWire's own code standard doesn't compromise so much, and in our context PSR-2 is a downgrade. However, I also see it as largely a non-issue. I don't care what standard people contribute code in, as IDEs make it largely irrelevant, at least for the way we merge code here. PhpStorm converts code to ProcessWire's standard automatically. I just encourage people to code in a standard that they find most readable and usable for them, so long as it's consistent.

Hi all, You've probably noticed I have been away. I am now back (but will be away here and then). What have I missed please? I have tonnes of posts to wade through (just 15 pages of new threads), thanks Cheers, /k

Hey guys, I'm new here, and I'm loving ProcessWire and the community spirit so far. We're just about to start using ProcessWire for our new clients requiring PHP solutions. Moving in a Rails direction, structure in our projects is becoming more and more of a necessity. As such, I've tried to employ some MVCish techniques in creating a boilerplate for ProcessWire for getting projects going quickly. One of the primary goals of this structure is to make it easier to separate logic from markup, and to prevent tags from being split over templates. Keeping `body`, `html`, and structural markup open and close tags in the same file greatly reduces cognitive overhead, and reduces opportunities for mismatching tags to exist. This approach also reduces duplication, and is great for keeping files small, focused, and organised. The main structure of the boilerplate is well defined, and ready to use in production. The repo is available here: https://github.com/fixate/pw-mvc-boilerplate (link updated 2014/01/17) Structure Although not completely MVC (using classes for controllers feels redundant, there are no models, and a full MVC approach will require a fair amount of customisation), it is heavily MVC inspired. Additionally, the structure is an extension of Soma's delegate approach. File structure: ├── site ├── assets ├── modules . . . ├── templates // boilerplate contents here ├── assets // css, js, fonts, images, etc. ├── controllers // variables and functions specific to templates ├── errors ├── partials // markup not specific to any particular template ├── views // layouts specific to a template ├── _init.php // used to load global and template-specific controllers ├── main.php // the 'alternate template' for all templates . . . **NB: This structure has largely been updated and improved - see the UPDATE - 2014/01/17 at the bottom of this post! Controllers Controllers hold template specific variables and functions. There is also a global controller responsible for making global fields, such as SEO fields, available everywhere, as well as being responsible for the actual delegation. Template logic should be handled as much as possible from within controllers. Views Views are responsible for handling markup and output. Views have available to them both the global controller, and their own controller. Logic should be, as much as makes sense, handled in a controller, with the view pulling the results in for display. Partials Partials hold markup not specific to any particular template on its own, such as the `<head>`, header, navigation, scripts, or footer. As with views, it is best to keep these as logicless as possible. _init.php _init.php is responsible for making controllers available to views. Controllers are only included if they exist - sometimes a template-specific controller may not be necessary, in which case you won't need to create one. main.php main.php is the default layout (equivalent to layout/application.html.erb in Rails) into which everything is rendered. This file has been kept small deliberately to let partials and views manage more fine grained markup structures, while this file serves the main site structure. A call to render_view(), defined in global-controller.php, is responsible for delegating rendering to the view of the current template. Additionally, there is a constant defined in globals-controller.php useful for serving different assets depending on if you are working in a local environment, or if your site is live. This is useful for preventing Google Analytics from running in a dev environment, or for using unminified scripts for debugging. This boilerplate eliminates the need to do much configuration when beginning a project, apart from having to change each template's alternate template in the admin. I hope this will assist in quickly organising and developing new projects! ------------------------------ UPDATE - 2014/01/17: ------------------------------ All files for rendering are postfixed with .html.php in good ol' Rails fashion. main.php has been removed in favour of mvc.php. mvc.php requires config/boot.php which then handles which controllers, views, etc. are used the main layout is now found in views/layouts/application.html.php - like Rails again. partials are now kept inside views/ each page template can have its own optional controller, or simply inherit functionality only from ApplicationController ├── site ├── assets ├── modules . . . ├── templates // boilerplate contents here ├── assets // css, js, fonts, images, etc. ├── controllers // variables and functions specific to templates ├── core // core mvc files - base controllers etc. (project specific stuff does not go here) ├── errors ├── views // folder for template files, layout files, and partials ├── layouts // application layout ├── partials // markup not specific to any particular template ├── mvc.php // the 'alternate template' for all templates . . .

The new "Add New" button is nice feature but I'm not sure it's very useful for all sites (the way it works for now), if I have a site structure that doesn't allow for the right setup needed. Either because the template may used in different branches, and or a multisite setup. I dream of a more configurable thing, and maybe also able to disable it.

News from 3D Printer world: a 3D printed small rocket engine ! Used tech in the 3D printer http://en.wikipedia.org/wiki/Direct_metal_laser_sintering Used material in the 3D printer cobalt-chromium Advantages Cheaper and faster than traditional ways of constructing small rocket engines. Total cost of this one: 6800 dollar. Videos of testing the 3D printed rocket engine that will launch a 1,33 Kg miniature-satellite into space. http://www.space.com/23097-students-test-fire-3d-printed-rocket-engine-video.html

If you don't want a user deleting pages, then it should be as simple as not giving them page-delete permission. If you want to change the behavior on a per-template basis, then come up with two roles... one that has delete permission and another that doesn't. Give the user both roles. On templates where you want them to be able to delete pages, assign both roles. On templates where you don't want them to be able to delete, then only assign edit permission to the role without page-delete permission.

Pagetree Add New Child Reverse New Pages in Descending Sortorder (newest first) while sortmode can be "Manual Drag-n-Drop" When a site display an overview of the latest posts, news, image-albums, etc. the newest entries should be on top of the list. We can achieve that by using an automated setting for the sortfield e.g. when the page was created = "-created". But this way we are not able to manually move a single page in the tree. This module enables us to do exactly that. It works with manually created pages, with pages created via the API, also when bootstrapped by importer scripts. Pagetree "Newsitems" with 3 newsitems sorted in descending order. New created item 4 is added to the top. To change the order click item 3 and drag it to the top and drop it. How to use it Download the module into your site/modules/ directory and install it. In the config page you find a single textarea field. Here you can enter the templatename or page-ID of the page which children should get reverse added, - optionally followed by a comma and the child-templatename if you need a more precise selector. You can add as many parents as you like, but only one on each line and in this format: TEMPLATE-NAME or PAGE-ID[,CHILDTEMPLATE-NAME]. A few examples: newsitems posts,post 1042 1033,album You want set your template(s) sortfield(s) to 'Manual drag-n-drop' if not have done already. ATTENTION You need to setup the TreeParent and the module config when there are no children in it! Otherwise it will not work! Also disabling the module once you have added children and then add one new page to it will mess up all! (You may think about to install the module as permanent in critical situations.?! see below ->) If you need to install it in a site for an already existing branch, you can do it this way: move / rename your existing branch create a new (empty) branch with the original name move your childpages into the new branch remove the renamed (and now empty) old branch DOWNLOAD - Version 1.0.2 get it from the Modules Directory Want to make it bulletproof? If you are concerned that the module settings could be dropped by other users or that the module itself could be uninstalled by accident, you may edit the module file directly: add the settings to the class constant permanentValue uncomment setting for permanent in the ModuleInfo This way the permanent settings couldn't be dropped by accident. To change it you first need to edit the modules file again. Example: You have two settings in the inputfield of the modules config, without permanent setting: parenttemplate1,childtemplate1 parenttemplate2,childtemplate2 Now you want to have the the first setting become bulletproof permanent: a) you enable the setting in the getModuleInfo, (uncomment setting for permanent) b) you write your permanent settings under the constant permanentValue const permanentValue = "parenttemplate1,childtemplate1"; After both steps, the module cannot get uninstalled anymore (Step a), and the first setting cannot get deleted anymore (Step b), as it is recreated with every call of the configscreen. (See first code line of method getModuleConfigInputfields) If you want to keep both definitions permanent, write them separated with a newline character "\n" : const permanentValue = "parenttemplate1,childtemplate1\nparenttemplate2,childtemplate2"; History of origins create pages via API, how add to the top of tree? Create new child as top sibling rather than bottom? New page on top? Pin Page to Top of Page Tree? move and sort pages with the API

hi all, new PW site launch: http://www.ohmspeaker.com/ some of the modules that were helpful or essential for this: cropimage formbuilder fredi importcsv minify piwik analytics procache batcher redirects version control template decorator modules manager page link abstractor sitemap xml admin custom pages markup simple navigation (for the sitemap) forum topics related to this site dev: Legacy Site URL redirects: http://processwire.com/talk/topic/3641-redirect-legacy-url-to-new-pw-page/ Clean up spelling: http://processwire.com/talk/topic/3519-use-api-to-spellcheck-whole-siteclean-up-spacing/ hashes in URLs on change selected product http://processwire.com/talk/topic/3496-help-with-url-param-change/ FormBuilder http://processwire.com/talk/topic/2904-how-to-redirect-by-id/ http://processwire.com/talk/topic/2821-3rd-party-send-conditionally/ http://processwire.com/talk/topic/2820-use-session-to-remember-form-selections/ Custom Menus http://processwire.com/talk/topic/2787-custom-menu-not-related-to-page-tree/ other notes: The skyscraper profile provided the example for how to get started with the advanced product search, a.k.a. the speaker finder. The standard search has been extended to show results in different categories. there is some use of Soma's word limiter for the news teaser text, and for making meta descriptions out of body fields, from this topic: http://processwire.com/talk/topic/3429-how-to-set-text-linecharacter-limits-in-templates/ the design is built on twitter bootstrap framework Fredi proved to be totally essential for the client, in being able to rapidly edit things without having to find things in the admin. This site is going to replace an existing site on a different domain (ohmspeakers.com). At some point we weren't sure if/how we would be able to handle the shopping cart element, and then found foxycart, which proved to be the best choice, very flexible, and easy to implement for this type of site. FC is hands down the simplest and easiest way (imho) we could achieve things like the legacy product pages, where there are various parts and upgrades displayed on 1 page. this version is sort of a "v1", and will be expanded/improved a lot for a v2, which would happen in about 4 months.. BTW - these speakers are really good; i now own 3 pairs ... they look great and do sound totally amazing...! -marc

kongondo, Glad you are back. New admin themes on the dev branch is a good place to start if you haven't seen it.

"Only required if..." Is now translated as "Nur benötigt wenn..." That seems wrong as it should be "Nur Pflichtfeld wenn..."

So here is my first module for ProcessWire http://modules.processwire.com/modules/assets/ I am interested to hear your critics / thoughts . Feedback welcome.

I believe you need to replace not overwrite the /wire directory

$allresults is a PageArray having Pages where "template=chalet" and "fireplace=1". There's no way a search with "template=repeater_calendar" could match that set, as the template is different. I'm not sure I understand what you're trying to achieve exactly, but it looks like there's a little confusion between regular pages and repeater items (which are stored as pages as well). You could try and find the matching repeater items first (replace $allresults with wire('pages')) and then use only those matches that have the right properties for the page itself. If repeater "calendar" exists only in template "chalet" you'd only need to filter out those results where property "fireplace" does not match 1. And of course skip unpublished repeater items at once (see the code example in my previous post in this thread). Hope this helps (if I even understood you right).

Just another one finished. Cygal - Art Deco furniture Big amount of images, a lot of different templates and responsive of course. Not my taste regarding the furniture but as long the client has good images...

Good to have you and josh back again

there is field permission module by Ryan, you find it from modules directory. on mobile so I leave the searching for you.

@kongondo thank you - i did just go ahead and use my normal way of managing menus which is by setting up a menu page tree and then coding the output manually; Welcome Back!

Hello, Just a little contribution (in french) about how (hard) configure processwire template files to integrate Google Authorship notions in Processwire. http://blog.itanea.fr/posts/configurer-processwire-pour-utiliser-la-notion-d-authorship-de-google/ See you,

Greetings Larry, Excellent discussion! Coming from the world of PHP frameworks, I am also very curious about the most "MVCish" way of working in ProcessWire. An interesting challenge is that a lot of the "M" and "C" necessities in frameworks are handled differently (I would say better) in ProcessWire. And yet, as we develop more complex sites, the templates can get quite involved with material that properly should be abstracted into some sort of classes/functions/controllers. What's great about ProcessWire is that we have the best aspects of frameworks, with the freedom to be creative in how we structure views and functions/classes, and it takes care of many crucial database elements in efficient ways. We then have the potential to develop interesting structures, without being forced to worry about too many conventions. I'd love to see a discussion here where we share creative ideas for structuring ProcessWire sites in MVC ways. Thanks, Matthew

PW is like a drug. Don't try kids, you will be hooked.

Thx @all ;-) Good catch. This is the problem you have with the hidden scrollbars on recent OSX versions. Will fix that, thx!

http://www.tamperemusicfestivals.fi/jazz/ The four-day jazz festival starts today. There will be a lot of traffic on the website, but I'm sure everything will run smoothly since ProCache makes the site run very lightweight and fast. In previous years this website has been running on WordPress or MODX. This year we switched to ProcessWire, and it has been a huge improvement. Everything on the site is fully editable, which makes the client very satisfied. Also, PW has revolutionized my workflow as well. I have quite the same feeling as when I switched from Windows to OS X : ) Logo is designed by the artistic director of the festival, everything else by me.

Greetings, This is a discussion I am glad to get into... I'd want to know more details about what the client needs and expects to accomplish, because that would definitely help make stronger arguments against Joomla. But up front, my main arguments are... Joomla does not support custom fields in its core. The only way to be able to have custom fields in Joomla is to add what is known as a "CCK" (Content Construction Kit), and that essentially grafts what I call a sub-CMS onto the main CMS. Without a CCK, you are stuck with the basic fields that Joomla assumes you will use for all your pages ("articles"). It is extremely tricky to implement what we think of as routine JS and PHP elements in Joomla sites. You cannot properly work directly inside your page code, as everything in Joomla is done inside "module positions" for your pages. Speaking of templates, the templating structure of Joomla is extremely limiting. Everything in your site must be placed inside those "module positions," you must define everything that goes into those module positions using a convoluted back-end, and your templates inherit all sorts of core Joomla styling and layout assumptions. In other words, you cannot simply create various layouts and name them according to specific content types. Joomla core makes numerous assumptions about how things should look and behave. If you want to change how a blog list looks, for example, you must hack core settings of either your core Joomla install or your templates. If you simply want to say "See Full Story..." instead of "Read More..." at the end of your intro pages, you have to hack the core code. Joomla makes it extremely difficult to manipulate URLs in any kind of creative fashion. Because it assumes you must always insert an "article ID" into your URLs, you cannot go very far with dynamic pages because you cannot know the ID of your "articles" before they are created. The core installation of Joomla has a convoluted directory structure: 15 main directories and an arrangement of sub-directories that are a major challenge to follow. Often, sub-directories are literally repeated and material of the same type (such as plugins) can end up in several different directories. This is because Joomla is designed to be built completely in the GUI, which gets us back to the problem described above in #2. These are just a few of the problems that plagued my work with Joomla. But again, the real power comes when the client says, "I want this..." and you can show how much better and easier it is to do it in ProcessWire. Can you follow up with some of the specific requirements of the client? Then I can give you more particular arguments. Thanks, Matthew EDIT: onjegolders: yes, indeed... Looking back, I think I have actually posted a few "Joomla rants" here in the ProcessWire forums: http://processwire.com/talk/topic/2129-justifying-diy-coding-vs-installing-modules/?p=20438 http://processwire.com/talk/topic/4143-wordpress-dominates-19-of-the-web/?p=40964 http://processwire.com/talk/topic/3952-reservations-for-hotel-rooms-and-restaurant/?p=38742

Just. Don't. Use. It. Seriously: I worked with Joomla exclusively a while ago (around 2004/2005) and the whole concept hasn't changed imho. The main problem is: It is by no means a flexible content management system, it is more a portal system. Let me explain what I mean: Let's say you have a large scale company with 1000 employees. All of those employess have a name, an email, a title and a linked department. You want to display one/several employees on each page in a kind of sidebar. The PW way: - Create a employees template - Add desired fields - Create page field in your other templates for selecting employees - You are then totally free to select employees in your template and you are able to output what you like (HTML, CSS). - You also have the possibility to use that information somewhere else because these are just usual PW fields. - An editor selects the employee(s) where it is needed: While editing the page The Joomla way: - Look if a module exists for that does this job for you (perhaps there is one, but probably not). - even if there is one you have to add your employees in some kind of extra database, where you are tied to the output of the module (not necessarily, perhaps the script kid lets you customize it). - But the biggest problem: Your editor will not be able to select the employees where it is needed. They have to go the modules section in the backend, have to find the module, have to identify the page they want to edit and then have the possibility to select an employee. This is a ridiculous workflow, image you have not only an employee to select but also header images, other side information and so on. The rest of Joomla can be summed up: - Bloated - poor security - inflexible - poor templating Joomla totally is okay for smaller groups, clubs or where ever no technical experience is needed and where the requirements are low. Everyone can set up a site really fast and choose from a lot of plugins (mostly poorly coded though). But when it comes to comfort, flexibility for editors... it is just poor.

Hello ProcessWire community At first I like to thank and congratulate Ryan for this wonderful work and I wished that I knew Ryan a long time ago And by the way you look awesome in the overview video Ryan And now a little bet about me: My name is Faisal Halwan from Saudi Arabia. I work in web development over 14 years now, and have dealt with various content management systems and PHP scripts in general. I was always dreamed of a flexible content management system for use in almost anything or what is now called CMF or allow me to say ProcessWire Thank you Ryan, you make my dream came true Yet I couldn't find any result in for any Arabic article talking about ProcessWire I will do my best to present ProcessWire and provide support in Arabic as soon as possible. Thank you and keep up the good work

for shure: // mysqli will be depricated, so use PDO if you start with it $sql = "awesome query"; // $database variable is available in your templates. $database is the PDO way. $query = $database->prepare($sql); $query->execute(); Oké, stupid me: Welcome to ProcessWire greentea

No problem! But when I want to be picky, your question was how to reach the last post. That's with the date-link. The dot or star that soma suggested is linked to the first unread post, not the last one. Also the dot-link is gone when read the whole thread, the date-link stays forever!

A couple small updates today to InputfieldImage and InputfieldFile, on the dev branch. You can now double-click the trash icon associated with a file/image, and it will select (or unselect) all files/images for deletion. The image inputfield now has a grid-view option. To switch to it, click the grid icon seen in the upper right corner of the field. This mode makes it more convenient to sort lots of images. Below are screenshots of the regular view and the grid view. You can toggle between them just by clicking the icon. While these screenshots use the development admin theme, this all works in the regular/old admin theme as well (and 3rd party admin themes I'm assuming too). Another update to mention is something sort of like the HelperFieldLinks module, but not quite as comprehensive. This works only in the development admin theme. If you hover the little down pointing angle on the far right of the Inputfield, it will append the field's name to the label. This is helpful for instantly telling what the field's name is from the API side. In this screenshot the "agent_files" part you see in the label appears only when that icon on the right is hovered.

kongondo, you rock! =) ps: Андрюха, пиши в следующий раз хотя бы через переводчик яндекса/гугла. Это, все-таки, англоязычное сообщество и корявки наши разбирать не каждому под силу, а люди реально помогают. Добро пожаловать на форум.

I'll take that as a yes . Пожалуйста!

Russian is my native language. I understand each word in first message, but hardly understand the whole message. So Like from WillyC has made my day =)

I'm definitely willing to build it unless anyone else has been interested in this. I need to spend a little more time playing with Redactor as I'm still not totally clear about what advantages it has over TinyMCE (other than being smaller). Though the API for it looks quite nice, but that's an advantage to the guy coding the module, not necessarily the end user.