Leaderboard

Hi all, today I stumbled upon yeoman and went searching for a PW generator. Larry Botha mentioned in a side not in his thread about MVC template approach that he has put a yeoman generator for PW together. I test installed it and it is working great. Pretty fascinating how quick we can setup a PW project with yeoman. This definitely can be a great timesaver. Larry's generator sets up a pretty opinionated PW install with his MVC structured fixate template and KSS etc. It would be great if we could have an unopinionated version that gives us a clean PW install. We could add options to the generator for installing a choice of boilerplate templates like the blank template, Foundation, Bootstrap, Blog etc. Just wanted to get your opinion on this. If any of you are interested, we could pull something together. Cheers Gerhard

When compressing the PNG image with ImageOptim (and the underlaying programms) you reduce e.g. the color depth of each pixel indivually, you remove full alpha transparency on complete transparent pixels and you reduce the color palette. Lots of stuff happens and basically the whole file is "repacked". ProcessWire isn't (and can't be) that intelligent. When resizing you create a new PNG file without all those optimization. ProcessWire reads the file and puts the image content into a new file using the full 24bit for every pixel of the PNG file. As you have already noticed, the quality settings don't have that much of an effect on the final image size. You would have to use ImageOptim again on the thumbnail. And as a shameless self promotion: There is our ProcessImageMinimize module/service which does exactly the same as ImageOptim but directly "on the fly" with ProcessWire. With the next version launching this weekend, you can minimize up to 2000 images for free.

Those modules are purely written for this setup. You take them out of the site then they won't function. I don't see value for those in Modules section, that list should be clean. (less is more) - If you want to get insight of the working for the tabs (ProcessPageEdit::buildForm) go for Soma's TemplateNotes - For the Process module, take a look at ProcessHello (ryan's great howto do process modules ) In basic, modules are not hard to do. When you know what to hook, and you know how to get the $event object and you know how to give it back, then it's not much different from working in your templates. There are many modules around here. And in a lot of circumstances others already have done these three things for you. If you take those as starting point, you only have to write some basic PHP. Don't let the word .module "fog" your mind

Awesome! What Martijn here shares with us that's just about the limit. We/ I can learn so much from the Code inside. I asked Martijn if he can help me with my pedigree problem to output the familytree and he gave me back a complete basic Homepage structur and THREE new modules!!! THANK YOU PS I hope you share this modules also in the "Modules-Section" because they are really helpful and others can be inspired for own modules - I for one am it.

Hi Franko, try this: <a href="<?=$c->url;?>">

cstevensjr is awesome !

Very nice work. I've been actively following this post. The amount of help provided on this forum is outstanding.

Ralf needed a parental Pedigree and I helped him to setup a very basic site. I quite liked the building of it and it resulted in doing 'to much' just for fun. I Asked Ralf if I could make it to a site profile so that someone else could profit from it to. Horse template Family Tab (Horse template) Pedigree (d3js) Unfinished Horse ( Horses created by Pagefield, but not yet edited ) Menu building /processwire Menu front-end / Download The Profile: pedigree_profile.zip

Well I can give you the parser for free: Just put the "wp-import" folder in the same directory as "site" and "wire" and add the name of your xml file in the folders "index.php". --- And if you still prefer a real module you can support development via (for example) PayPal mail@nico.is --- Edit: Forgot to add the attachment wp-import.zip

Hi! Just finished my first module This module adds a new "Google-Analytics" Page in your Admin-Panel and displays various Statistics from a Google Analytics Account. It uses the JQuery plugin "jqplot" to display the charts. Github: https://github.com/w...GoogleAnalytics Modules directory: http://modules.proce...ogle-analytics/ Features Visits by Date (Chart) General Statistics about Visits (Total visits, Visit duration, New visitors, Returning visitors etc.) Demographics: Countries, Cities, Languages System: Browsers, Operating Systems, Screen Resolutions Mobile: Operating Systems, Screen Resolutions Pageviews by Date (Chart) Top Content Traffic Sources: Keywords, Referral Traffic by Domain and URI Choose a default date range displaying statistics: last 24 hours, 2 days, 1 week, 1 month etc. Custom date range by setting a "start date" and "end date" Requirements Google Account and Analytics Account A Project in the Google APIs Console cURL Installation 1) Create a Project in the Google APIs Console: Create a new Project in the APIs Console: code.google.com/apis/console/ Under Services, enable the Analytics API Under API Access: create an Oauth 2.0 Client-ID Give a Product Name, choose "Web-Application", Domain doesn't matter Enter a Redirect URI to the GA-Page in your Processwire Installation: http://yourdomain.com/processwire/google-analytics/ Notes: The redirect URI must exactly match with the URL from the new "Google Analytics" page in Processwire. Open the Page and copy the URL from the address-bar (localhost does work too!) The project created in the APIs Console can be reused for every Processwire installation using this module. You just have to enter more redirect URIs 2) Install the module: Place the module's files in /site/modules/ProcessGoogleAnalytics Install the Module via the Admin-Panel Enter Client-ID and Client-Secret keys from the created project in the module config Load the newly created page "Google-Analytics" and click on the button "authenticate" Grant the module access to the Analytics Data Choose a Google Analytics account (Domain) from the dropdown Done: You should see the statistics. Check out the module config options for further customization In order to let other users see the Google Analytics page, you must give their role access to the "ga-view" permission. Ps. Processwire is awesome and so is this community!

Captain Hook ProcessWire Hooks Cheatsheet http://somatonic.github.com/Captain-Hook/ or on processwire.com http://processwire.com/api/hooks/ I created a simple list with a live search for all hookable methods available in the core. All methods prefixed with a "___" (3 underscores) are hookable. Methods can be made hookable by simply adding those ___ to it. ------------------------- I usually don't really need this, but thought it would be good to have an official list for reference. I used Sublime Text2 for searching and dumb a file with a search for " ___" in wire core. From this list I created a html file with a php script and added some fuzzy live search, similar to the API cheatsheet. If you use Sublime Text 2 like me you can simple use Goto Anything command super+p to show a fuzzy search for files. Enter a class name you want to search for. For example "fields" or "process page edit" you will recieve a list of files found in PW. Highlight the file and typ a @ to see the symbol list quickly or select the file and super+r the get the symbol list.

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

I am sure some of you must have noticed my stumbling around in the dark while getting used to the ProcessWire system. Someday I hope to emerge as a user who brings more to the table than just silly newbie questions. I am sitting down with a mug of really good coffee so I thought I would offer my feelings and reactions to ProcessWire thus far… Quick background: I am a photographer with a long history in photojournalism and commercial work. I have also enjoyed doing web work for years. I built quite a few static sites before searching for a CMS system that felt like home. I must have tested about a dozen or so before spending some real time with Wordpress and then MODx. I liked Wordpress but the template system was awkward for me to me customize. I then found MODx Evo. I stuck with Evo for years and found it very designer friendly. I am not a code developer at all but Evo allowed me the flexibility to design static test pages using clean HTML and then create my Evo template from that foundation. MODx uses a system of combining placeholder code using Chunks, programmed Snippets and Template Variables (TVs) for dynamic forks in the road. Forgive me: I have never been well versed in web tech jargon. One of the features (or liabilities) with MODx is that it uses its own template language. When you deploy a Snippet you need a Snippet “Call” to set parameters on how the Snippet will function. Usually you would need a special template for the Snippet as well. This process is not totally intuitive and has its own learning curve. Then along came the entirely new branch of MODx called Revolution, or Revo for short. Revo was more powerful but also more complex. The nice thing with Revo is that you could spend more time away from the root folder or using an FTP client to upload and install Snippets. The Package Management system is a powerful means of installing and updating the various Snippets and plugins. Updating these building blocks in Evo is more of a pain; manual copy and paste effort required. What I did not like with Revo is that much of the placeholder and template syntax changed from Evo. The changes were subtle but deadly if you confused the two. The main issue I have with Revo is how slow the Manager (admin) system is. The amount of stuff (very techie term here) in Revo is overwhelming. Some of my clients who used the Revo Manager sporadically would always forget how to do things. To be honest I would have the same issue on occasion. With MODx we had Evo, then Revo, then the whole cloud system and now MODx III. It sort of gets confusing. To counter this the forum now has a zillion sections that cater to all the MODx project branches. But I find doing a search on my issues or questions revealed some confusing links to information that focuses on a different branch or is outdated to the system I am working with. I guess this last year was a difficult year for MODx: growing pains and money, etc. The whole technology of Revo, the Cloud and the loss of some of its main core programmers (Shaun McCormick) has created some signal-to-noise-ratio issues. Last year was a terrible year for me personally as well. The joy of buying a new project house was crushed by the death of my father and my only sibling (in South Africa) in the space of just four months. Coming out of this fog I sought of stumbled on some interesting chatter about MODx users switching to ProcessWire. The rest of this quick moving journey has been interesting to say the least. My reaction to PW has been filled with both initial confusion and admiration. I thought my not knowing any PhP was going to be a deal breaker. I sort of had initial writer’s block with the blank page. The PW installation would go well, but then what? But after playing around with several local test installs I can see how liberating and powerful the PW API, the template system and Fields really are. I am slowly picking up some basic use of PhP statements. Doing so is more valuable and efficient than the MODx learning curve with it’s proprietary template syntax. I suspect my working knowledge of the PhP that will make using PW easier will only grow with time. That is my hope for sure. The thing I like about the PW Admin is the speed and the whole weight of the backend. Compare the jQuery Admin to the heavy, heavy MODx Revo Manager and there is no contest. It works better on the iPad as well. My clients have commented on how much “stuff” there is in the Revo Manager. I can’t wait to show them how fast and simple the PW Admin is by comparison. One of my issues is letting MODx go. The community has been great. I cant tell you all how much I admire and appreciate folks like Susan Ottwell, Bob Ray, Jay Gilmore and countless others. Susan has over 20,000 posts on the MODx forum. Just about all of them are consistently helpful and insightful. Being a heavy forum contributor can lead to one’s becoming impatient and suffering from burnout, but Susan’s helpful attitude has been amazing. But my heart tells me that I am better suited to learning ProcessWire rather than the awkward mix of MODx Evo and Revo that I have been using to this point. I think I am also trying to duplicate some MODx procedures when I work with my PW test projects. I think that time will be on my side as I become more comfortable doing things the “ProcessWire way”. Anyway, I am not sure where I am going with this, I just wanted to offer my $.02 and to say how grateful I am with all of you who have shown patience with my initial learning. Cheers, Max

We're proud to release our next and new version of ProcessImageMinimize (1.0) and the minimize.pw service. As mentioned here and on Twitter we've worked hard the last two weeks. The whole service has been rebuilt from the ground to support all the wanted features of the community. It's faster and more reliable, it works out-of-the box and has a new pricing structure. Images are processed async. behind the scenes The service works on a queue now. The service has new compressions scripts with higher quality output, especially for jpg files Build to scale: We can scale the servers in under a minute and handle thousands of images without any problems The module uploads the image and waits until the image is minimized. If activated, the module is now able to replace the original image file instead of creating a .mz variation If activated, the module automatically sends every new image to the service The module also works with apeisa Thumbnails module (CropImage), adding an getMzThumb($name) method While the image is beeing minimized, the module creates a temporary image. You can now set a quality of 100 on your image config without problems Direct link to the new dashboard at the module settings page The module now tells you if you have no volume left. The module also features the "classic" way of using the minimize()/mz() API method on PageImages. A new dashboard for customers features statistics and a quick overview You can see traffic, compression rates, saved bandwidth and more for each website using your license key. You can browse old invoices. New pricing structure The pricing is now based on a volume-based point system. Buy more volume(=images) for your license if you need them. No yearly price, no auto-renewal. And 1000 2000 images for free. A new website with an overhauled design and more feature information A new little minigame to compare minimized JPGs. All the old features like secured https connections, the fail-safe module and our image size reductions. The few existing customers are migrated with some extra volume You can read about the features at our new website. Ready to start? Download the module and read the documentation at Github For the first week, we will give all new users 2000 instead of 1000 images for free. So signup and try the service. This should be enough for alle small- to mid sized projects. If you need more than those two thousand images, you can buy another 5000 for around 19€ or 15000 for 39€. You don't have to update your license key on your module configuration after buying more volume. Paying for the service also removes the three site limit. Attached is a screenshot of our development dashboard and the new homepage. Please note, that we currently don't support a full ProCache installation. At least one PHP call on any site has to be made in order to activate the module. We have a plan to solve this problem but it's not implemented in this release. Also the stats don't display the correct amount of images sent for old customers, because we haven't tracked them before. Thanks for your previous feedback. Thanks to all the developers using our beta. You really helped us. We hope that we can provide a valuable service to the (growing) ProcessWire community. Feel free to ask any questions. Submit your first impressions of the service, the website or any other aspect. As mentioned before, we want to be open and honest.

I'm not sure what you are trying to acomplish. Anyway the folowing code prints all the roles and name of the role for the current user foreach($user->roles as $role) { echo "Role: {$role} = {$role->name} <br>"; } Or if you need the role for a specific user $u = $users->get('admin'); foreach($u->roles as $role) { echo "Role: {$role} = {$role->name} <br>"; } All anonymous visitors, loggedin users, admins etc... by default have the guest role

Sun of a Gun, It worked! Thank you diogo.

Hi @gebeer Ye, I must outline some of the features of the generator - it can definitely improve workflow! It's a little opinionated - it generates projects using our SCSS framework, our KSS Styleguide Boilerplate, an extensive Gruntfile for much awesome automation, and of course the MVC Boilerplate, all of which are fundamental to our ProcessWire projects. As a quick overview, you can expect the following structure from a newly generated project : ├── database // location for automated db dumps ├── src // PW install location ├── styleguide // KSS Boilerplate, and SCSS (style.css built to templates) ├── .bowerrc // tell Bower where to install libraries ├── .editorconfig // normalise line endings, tabs, etc for all team members ├── .gitattributes // have git normalise line endings cross platforms ├── .gitignore // default ignores ├── Gruntfile.coffee // automated deliciousness ├── package.json // Grunt dependencies ├── private.json // .gitignored - put sensitive data here (SSH keys, db creds etc) └── private-sample.json // a template private.json for other devs to add non-committed sensitive data I'd like to put together a post covering some finer details in the next 2 weeks or so - things are a bit crazy here at the moment! I'll update here to let everyone know!

You're missing the slash at the end of url.

Adrian, you have been overly helpful to my learning ProcessWire in many ways. I few likes is nothing!

Wow @cstevensjr - I am feeling the love from you tonight

Ok, so I have added support for automatic populating the video title into the image description field for both Youtube and Vimeo. Not sure how much longer this method will work with Youtube, but I think it's simpler to keep using v2 of their API for the moment. I implemented both cURL and file_get_contents methods for Youtube and simplexml_load_file for Vimeo. Let me know how it works for everyone and I'll tweak methods if needed.

Yeah, that is still working, but from a quick read I get the feeling it won't be in the future, but not certain. I did read something that suggested that maybe basic info like the title will still be available this way. Maybe I should just go with this for now and adapt later if needed. I might go with curl though to avoid issues with get_file_contents and those on hosts with allow_url_fopen disabled.

Yes...use what is best for the job. $sanitizer->name is best for ProcessWire 'name' - Name is used to build the URL hence its formatting (of course you can use it if you require such formatting...) but in your case, text should be fine...

kongondo, thank you, man! It worked like a charm! Wow, another great advance in my project. Can't thank you enough! And it was not too much of a puzzle, as it seems to me now One small note for those who would like to use this trick in a ProcessPageEdit-based module: if you construct your own form for ProcessPageEdit, then put the rendered ProcessPageList in an InputfieldMarkup (and append it to an InputfieldWrapper field if you want to): $form = $this->modules->get('InputfieldForm'); // prep the form $wrapper = new InputfieldWrapper; // a wrapper $wrapper->attr('value', 'List of available articles'); $p = $this->modules->get('ProcessPageList'); // kongondo's code goes here $p->set('id', 9999); // setting the parent page $pageTree = new InputfieldMarkup; // the placeholder $pageTree->value = $p->execute(); // fill the InputfieldMarkup form field... $wrapper->add($pageTree); // put inside the wrapper... $form->append($wrapper); // append the wrapper Because Process<something> modules do not append directly to forms, you know

I have just updated this module with better support for video links that have a start time and other additional parameters in the url. It also now supports embed links and other variations. Please let me know if you find any issues with this new version.

Why not? Almost everything in ProcessWire is a page, so this would be a good way to go. Especially if the profile information will contain more details/fields than a plain user template. I might approach it like this: Create at least two templates - member and company. Create and add your user detail fields to these templates as appropriate. Create a Page reference field with a name like owner. This should be configured to reference template=user at the very least. This is the way user detail pages would be linked to actual user accounts. When a user registers, you would create a new page with the template as either member or company. Like this: $profile = new Page(); $profile->of(false); $profile->template = 'company'; $profile->title = 'Acme Widgets'; // but most likely from sanitised POST data $profile->owner = wire('user'); // this links the new page to the logged in user $profile->save(); You can find the user profile info like this: $profile = wire('pages')->get("template=member|company, owner=$user"); I think this method has a few benefits: You don't need to modify the core user template. One user account could potentially manage multiple profiles if you wanted this to be the case in the future. A profile owner could be easily changed to someone else if necessary. Profile types can be easily changed later. Profile type can be identified by its template which should make it easier to differentiate when viewing or searching. The code examples above haven't been tested, and are just an example of how it could be used You could even mix this in with diogo's suggestion - still have a template and page with URL segments, but using different templates for the profile information.

Photowebmax: I recognize a lot in what you write and I'm sure others will also. Yes, first we are human and second we are a designer/coder. Modx, well, loved evo but ran away from that frankenstein cms revo. Yes I have to give the modx forum credit, especially to Susan Otwell. She helped countless people on the forum and also helped modx a long time ago when they were in trouble. Thanks to pw I finally fell in the process of becoming a php coder. Making websites has the advantage of making new contacts/friends world wide.

I think I wasn't trying to find the simplest way . I also remember having seen that piece of code in the API but surely haven't inserted it the right way and/or to the right place at that moment. I've done this now: <li><a href="<?=$config->urls->root?>"><?=$pages->get('/')->title?></a></li> Thank you again Joshua !

Author of JShrink here (I found you guys in my web logs). I thought I'd pop in and say hello, and talk about JShrink a bit. I originally made it as a drop in replacement for JSMin, because JSMin is technically not open source (it has the "do no evil" license, so projects that take open source seriously, such as Debian, won't bundle projects with it). Since then I've made improvements on speed, added additional features like support for conditional comments and license preservation, and have really put work into the test suite itself. Ryan Grove, who originally ported JSMin to PHP, has officially dropped the JSMin project and is referring people to JShrink on the Github page for it. Yesterday, after several years of being in the "beta" phase, I launched the JShrink v1.0 to make the API official and stable. On a tangental note, I also maintain a caching library called Stash that may be useful to you.

@OrganizedFellow MVC's not too bad, really. I was always intimidated by it, but all it really is is this: Models -> object definitions, and communication with the database (not really applicable in PW because the API speaks with the DB). Models are an interface between the database, and controllers Views -> Logicless (mostly) templates which are responsible for markup, and display of data. Views communicate only with controllers Controllers -> functional and logical aspects regarding instances of an object (in our case, instances of page templates). Controllers are an interface between Models, and Views As a side note, we have a yeoman generator which will quickly help getting an entire PW project set up: https://github.com/fixate/generator-fixate-pw I'll eventually cover this in a separate post.

You might want to have a look at this module of my coworker which does exactly what you've mentioned: It separates the "view" (mostly logicless) templates from something called "data providers" (controllers) and adds some logic to define reusable chunks. Plus: It also plays nice with this one which lets you use twig for the view templates.