Leaderboard

I have come to PW from MODx just a couple of weeks ago... before that, MODx (both Evo and Revo) was my CMS of choice and I always praised its flexibility (e.g. building page templates or adding code snippets was really easy, compared to most other CMSs). I still think that it is a good CMS (I have used it for years without finding a better alternative). Now that I have done some projects in PW, I doubt I will be going back to MODx. PW is much, much faster, has a very intuitive UI, a unique "the-api-is-everything" approach which allows instant production with just a quick look at the cheatsheet, and, very important, a small but incredibly helpful and friendly community. Thumbs up for PW!

Should we leave this one here today for public shame?

/site/config.php u set $config->prependTemplateFile = '_init.php'; editamos /site/templates/_init.php: <?php if($user->isGuest()) die('go away.now');

Yes, there has been very strong growth recently. Monthly visits in April: 2011: 5 112 2012: 12 448 2013: 48 455 Most popular countries this year: 1. United States 2. Germany 3. United Kingdom 4. Netherlands 5. India 6. Finland 7. Switzerland 8. Canada 9. France 10. Italy

Drupal & Joomla ...the movie?? Part 6?!?! Man, i have to get my hands on part 1 - 5!!!

Hi Alex, welcome to the forum. To be save: your $page->Image is a real ImageInputfield that is assigned to a template? With [FIELD SETTINGS FOR NEW PAGE] you also have set the right template (that one that contains an ImageInputField named Image) ?? Assuming the both questions answered with yes, you can pass the images filename to the exif_imagetype function: <?php $map = array( IMAGETYPE_JPEG=>'jpg', IMAGETYPE_PNG=>'png', IMAGETYPE_GIF=>'gif' ); $url = 'http://nogajski.de/_grafik/0815.png'; // a jpeg with wrong extension! $p = new Page(); // create page and assign image from url .... $p->save(); $p->Image = $url; $p->save(); $img = $p->Image->first(); // get your ImageObject, * read below ... $ext_im = $map[exif_imagetype($img->filename)];// compare imagetype against file extension $ext_fn = strtolower($img->ext); if($ext_im != $ext_fn) { // if not match, rename it $newFilename = str_replace('.'.$img->ext, '.'.$ext_im, $img->name); $img->rename($newFilename); $p->save(); } * how to get the imageObject depends a bit on your settings for the ImageField under Setup->Fields-> (your Image field) -> Details -> Maximum files allowed. If you have set it to 1 or if you allow multiple. (not really sure) but I think this could work for both situations EDIT: -> http://cheatsheet.processwire.com/ the FILES -> properties and ->methods()

I implement the PW CSRF token in my forms so a resubmit will result in a error message.

Greetings, Choppingblock: that article you mention is also what finally got me fully into ProcessWire. I had been following PW for some time before that, but was still trying to force Joomla to do what I needed (and also giving several other CMSs a try, including ModX, ExpressionEngine, and Drupal). After reading that article, I finally dove full into PW, and never looked back. A theory about Joomla -- designer/developers who want flexibility, open design possibilities, clean templating (or no templating), and like playing with code for particular goals, are attracted to systems like ModX and ProcessWire. However, designer/developers who want a more pre-defined way of doing layouts, and to just "plug in" modules for all kinds of actions, are attracted to systems like Joomla. I know lots of designer/developers who never move away from Joomla because they like to just "install" what they need. The problem, of course, is all that Joomla "done for you" stuff becomes a problem once you find yourself spending more time hacking and altering Joomla than if you just went to another system. Speaking for myself, I had a number of projects I had built in Joomla, and I was ready for something more, but it was a challenge to convince clients to move several projects to another system. I believe the most painful spot to be in with Joomla is an "intermediate" developer. You don't yet have the coding skills to hack Joomla deeply enough, and yet you are ready for more flexibility. ProcessWire is excellent for all levels of developers, but it is the best cure for the "intermediate developer blues"! Thanks, Matthew

A alternative shorter way to do the same: return $pages->find("template=category, id!={$page->parent->id}");

Well-said Matthew! I still can't believe that I can "write php" code, thanks to ProcessWire! The API - it's friendliness and power - has encouraged me to write code. I don't think I would have dared to code a single line of snippet in MODX save for echo "Hello World"; ! It's not a problem with MODX; it's just that PW makes many difficult things easy. choppingblock, I think I have said welcome before; if not, welcome to PW! Cheers.

Greetings, Choppingblock: there are a lot of (former) ModX people here. Seems that the kind of people who want high flexibility are attracted to ModX, and the fact that so many ModX people then see ProcessWire as a higher level of flexibility really tells you something about ProcessWire! After using ProcessWire for several months now (I came from Joomla -- a very inflexible system), I am impressed over and over again how every kind of development challenge can be achieved with such concise, neat solutions using the ProcessWire API. Thanks, Matthew

WP Same initials - other way round!

Processwire is a perfect load balanced template/code system. If that fact is recognized and experienced by more people it can really boom drupal and wordpress away from cms land. But then again, strangly enough, it doesn't work that way. You can be the best and yet other wanna be designs get more credit and more fame. I am in the repair/service field for computers for more than 15 years and I know of tools like deepfreeze and shadow user that can recover a pc fool proof from any software problem/attack/virus/mis-installs/wrong driver installs/dumb users/user mistakes/ etc. etc, simply by rebooting the pc. And yet is everybody knowing about it and buying it ? No ! Why ? Beats me ! Same for tools that can make a pc with 8 Gb of ram or more start to fly and run your programs in high speed mode by using a ramdisk or supercache. Doesn't everybody want his pc to run your programs super fast ? Make IE / FF / Word / Photoshop / etc. etc. run fast ? Yes ! Do people know and use ramdisks and supercache ? No ! Why ? Beats me ! I guess people are sometimes hard to understand.

Yes, this is basically what Pageimage does internally. You can use PHP's copy() command.

Local Audio Files - MP3-DB The Local Audio Files DB is a combination of a Module and a SiteProfile. It is intended to import MP3-files from your filesystem into ProcessWire, read ID3-Tags and pull coverImages from it to feed the DB. It is thought as a starting point for your own site creation. A sort of comfortable aggregated reuseable code for PW-lovers. How to Install Grab a copy of the latest ProcessWire. Replace the install, modules and templates directories with those in this profile, as shown below: /site-default/install/ /site-default/modules/ /site-default/templates/ With SiteProfile-Installs normally that is all there is to do. With this Profile you also have to copy the file LocalAudioFilesImportShellScript.php (for simplicity) to your PW-rootfolder, (where the index.php reside). If you are on Windows you also should copy mp3_import_starter4win.cmd to the same location. Now install ProcessWire as per the instructions included with it and it will install the LocalAudioFiles profile automatically. After that you find a Quickstart Guide at the homepage of the profile: Follow the 3 steps and you are done! How does it work? The Site has 4 sibling Tree Branches: genres - artists - albums - songs. Each of them hold child-pages: genre - artist - album - song. The logical relations are nested parent-children ones: a genre hold artists, each artist hold albums, each album hold songs. To support both, slim and fast data relations & the logical hirarchy, the module extends the ProcessWire variable $page with some additions. It uses the addHookProperty mechanism to achieve that. It uses an own caching mechanism for large lists, that can be prebuild when running the importer-shellscript, or it build the cache on demand. Also it comes with a FrontEndHandler class that provides a lot of functionality, for example fully customizable FormSelectFields of all genres, artists or albums. More detailed informations and code examples are collected in a demo section of the site. The extended $page variable together with the LocalAudioFiles-FrontEndHandler gives you comprehensive tools to work with your music collection. Download Modules Directory LocalAudioFiles-SiteProfile_v0.1.5.zip LiveDemo I have uploaded a small LiveDemo with only 7 truncated songs. But it's pretty fine to view all Demos and the additional $page->proterties. demo song page demo album page demo artist page demo genre page Graphical overview Screencast of installation https://youtu.be/-qYyppvEF1k History of origins http://processwire.com/talk/topic/3322-how-to-setup-relations-for-a-mp3-db-with-pw/ http://processwire.com/talk/topic/3462-pages-get-return-nullpage-but-page-exists/

Just thought I'd share this module which I modified from the PageEditPerUser module by Ryan Cramer. I needed page-specific edit access by roles, not by user. So... Overview Assign edit access to roles on a per-page basis. Description The user must already have page-edit permission on one of their roles in order to get edit access to assigned pages. Otherwise, they will only gain view access. This module is fully functional as-is, but intended as a proof-of-concept for those wanting to go further with adding custom edit and/or view access. How to install 1. Copy the PageEditPerRole.module file to /site/modules/ 2. Go to Modules in the ProcessWire admin and click "Check for new modules" 3. Click "install" for "Page Edit Per Role" How to use 1. Create a new role called "editor" (or whatever you want to call it) and give the role "page-edit" permission. If you already have a role in place that you want to use, that is fine too. 2. Under "Access > Roles" locate the role you want to assign edit access to. Edit this role. 3. For this roles's "Editable Pages" field: select one or more pages you want users with this role to be able to edit. 4. Save the role. 5. Under "Access > Users" locate the user you want to apply the role to. Edit this user. 6. For this user's "Roles" field, select the new role you added - "editor". 7. Save the user and your are done. 8. To test, login as the user you edited to confirm it works how you expect. Download http://modules.processwire.com/modules/page-edit-per-role/

hi everyone:) i stumpled across ProcessWire on my way to learn ModX. It draws my attention because of it's fast backend, and the chance for me to connect it with my big wish to learn php (atm i know just very basic stuff :- ). PW seems to enable me to use some php-funktions with an easier layer on top of it. so, i can be productive at the beginning here are some questions, that i came up with at my exploration of the PW-wonderland in the last days: search: afaik there is the possibility to integrate a search function to the website. is it possible to combine a searchfield with checkbox filters to search and filter pages in a specific branche of the page tree? blogging: it's possible to build a tag-cloud for a blogging sections with PW. this hole filter possiblities-thing is somewhat unclear for me atm comments-module: the comments containing a name and an e-mail field, but i like to extend it with a "twitter" and "your website" field. is this possible without a lot of complicated "core hacking" ? forms: from what i have understand, it's possible to create a front-end form that collects data for the content of a page. are ther possibilities to get form entries per mail with csv-file attached or csv-styled text inside? demo page: maybe i've just overlooked it, but i was not able to find the skyscraper siteprofil on the download page. i realy like to have a look at it, to learn from the api usage there. does someone have experience with forums and newslettersystems, that go well along with PW ?(same userbase/passwords) (i hope my english was understandable, since i normaly don't write a lot in english myself. but i'm able to perfectly read and understand it). greetings, chris EDIT: a questions to the modx users in this his forum: is PW now your primary cms and modx a fallback for some special usecases? - PW made me desinterested to learn modx, but maybe i miss something

They Are Back with New Adventure and Action, So All Fast & Furious lover, Get Ready to Enjoy Fast & Roderigo Meat Boat Movie, Biggest Action Power Pack Only on Fast & Roderigo Meat Boat (2013) Movie. ----- links deleted -----

According to the cheatsheet remove() takes either a key or an object. Maybe I'm wrong but when you write a page-id like 1040, this is considered as key which doesn't exist. So you could try this: // Remove 1st item $demo->product_group->remove(0); // Remove 2nd item $demo->product_group->remove(1); // Remove object $p = $this->pages->get(1040); $demo->product_group->remove($p);

I remember using XAMPP years ago. I don't remember why I stopped using it. WampServer2.2 has worked well for me. I just figured out (needed to) how to create subdomains for a site project I was using Arch as my primary OS and Win7 as the secondary. But my wife hated to stand by to press 'down' and urged that I remove Linux, so I did. I'll give Journal a shot ... VirtualBox to the rescue!

#1 - XAMPP Tried Linux various times but always went back to Windows - as a matter of choice

I prefer the 4th, but I understand that you have some things that force you to be with Windows. I think running an OS on a virtual box for production is not ideal, depending on your Windows needs, you could also dual boot. Have you considered that? I have http://elementaryos.org/ on my PC and, although it's still in beta, it's super fast and stable (more than Ubuntu and Fedora for sure). Maybe you can try that one Edit: For me it's a great advantage to be running the same system as I have in the server. I installed Elementary some days ago, and Had a Lamp stack running in some minutes, and installed it ad tweaked exactly as I would do in a VPS server.

If you use PW form API, it will get validated if you call processInput() $form->processInput($input->post); I think the CSRF doesn't get reset if the CSRF was valid, but you can do it manually with $session->CSRF->resetToken(); after validating the form. Or if you do manual form and not use InputfieldForm you can generate and validate the token $session->CSRF->validate(); // will throw exeption if invalid And get the token name and value with it respective methods $session->CSRF->getTokenName(); // name for input hidden $session->CSRF->getTokenValue(); // token value Also the trick renobird mentioned is also very good to prevent double click submission errors. Of course you can still use redirect method and as you may found the $notices errors and messages are transported through redirects.

You are probably right about Joomla... but I think even for experienced developers the time is spent better working with PW than trying to hack or extend Joomla. That is (for me) the absolute best thing about PW: the api is actually helping me to get things done quicker and easier, instead of forcing me to learn a new language or "hack the core".

Thanks for the welcome... I noticed that a lot of people here came from MODx... there has been some discussion in the MODx community about where the CMS would go in the future. The reason for me to try PW was this article by Marc Hinse. I also had to do some projects with Joomla (hated every bit of it, and that was even before i learned about PW). I still don't understand why this is so popular... its un-flexibility is only matched by its un-intuitiveness.

Hi choppingblock, Do you mean preventing the user from clicking submit multiple times? If so, I usually just handle that with JS. $("form").submit(function() { $(this).submit(function() { return false; }); });

Welcome choppingblock.

Flashdata thread http://processwire.com/talk/topic/970-flashdata/

u try edit /index.php file comment.out this line ini_set("session.save_path", rtrim($config->paths->sessions, '/')); so like: // ini_set("session.save_path", rtrim($config->paths->sessions, '/')); fixed ?

hi Marco Angeli http://modules.processwire.com/modules/maintenance-mode/ http://processwire.com/talk/topic/2475-quick-tip-for-testing-on-live-website/

No Portugal?? I have to spend more time on the forums

There aren't any core security issues that I can find here. But Khan is right that the email address really should be unique, just as a general security principle. Not enforcing unique emails does lead to potential security issues, or at least plenty of ambiguity when writing login/password related stuff. We should spare people from having to think about that in their own API code, and think the solution has to be at the database level with a unique key on the email field. That way if you are writing your own front-end login and/or password reset capability, you don't have to consider the implications of email addresses not being unique. If you have the core "forgot password" module installed, then realize that your account is only as safe as your email (which I think is safe to assume for any such function). That means that you should only put in email address you have access to, and if you ever lose that email, then make sure you update your account with your new email address. But of course, that would be a problem whether in ProcessWire or anywhere else. But there is a reason why the "forgot password" capability is not installed by default, and that's because such features always reduce security, even if they are written in a secure manner. So as always, leave the forgot-password capability uninstalled unless you absolutely need it (whether in PW or anywhere else). Yes, you'd basically be giving the other person access to your account. Or at least the ability to reset your password. But it doesn't really matter if that person has an account or not, so long as the email has a recipient. But this is the nature of the beast, whether in ProcessWire or elsewhere. I suppose making email addresses unique doesn't really matter all that much in this case. But I still agree on the value of having emails be unique. It just makes for a more bulletproof/less ambiguous user system.

Hi alex, <style> tags are normally inside the <head>, as far as I know. You can set the chosen color inline: foreach($page->repeater as $p) { echo "<div style='background-color: #{$p->colour_picker};'></div>"; }

Well done Horst! Sorry didn't have time to test the last version. Will make some time for this

Codemagic is even in the core tinymce plugins in PW. Just have to add it in the field configuration. It even has hightlighting and search replace and autocomplete.

If you do want to stay with TinyMCE there is a plugin to take care of formatting code in the editor: https://github.com/tinymce-plugins/codemagic

The notices system actually doesn't have anything to do with jQuery UI other than that the default admin theme makes use of jQuery UI class names when generating the markup for notices. But for your own front-end, you can make use of the $notices API variable to output them however you want. It can be as simple as this: echo "<ul>"; foreach($notices as $notice) { $class = $notice->className(); $text = $sanitizer->entities($notice->text); echo "<li class='$class'>$text</li>"; } echo "</ul>"; Then you would want to style the two type of notices in your CSS: .NoticeMessage { color: green; } .NoticeError { color: red; }

Maybe, but as of Thumbnails is a visual Tool, I wish to have it like in my dirty Hack. plus one additional feature: If you have created a Thumb and quality isn't what you have expected, when you go back to recreate it, the CropRectangle should be placed automaticaly at its place, so you have only to select a different quality and / or sharpening pattern. (Just a dream, - but sometimes they become true)

Assuming I understand the need correctly, what I usually do add this to the <head> section of the main markup include: <head> <!-- all your typical <head> stuff --> <?php $file = "styles/$page->template.css"; if(is_file($config->paths->templates . $file)) { echo "<link rel='stylesheet' type='text/css' href='{$config->urls->templates}$file' />"; } $file = "scripts/$page->template.js"; if(is_file($config->paths->templates . $file)) { echo "<script src='{$config->urls->templates}$file'></script>"; } ?> </head> Using this method, if you have a template named 'product', then it could have dedicated CSS and JS files in /site/templates/styles/product.css and /site/templates/scripts/product.js, when you need it. The nice thing about this is that it's just a system rather than hard coded file. If you determine you need something unique for the CSS (or JS) on pages using some template, the you can just create the CSS (or JS) file and have it start working automatically. You can take this further too. For instance, you could use the same technique with page IDs to assign custom CSS/JS files to specific pages.

My way of handle it was to create a textarea field and insert the code there directly. In the head.inc I had something like this: <?php if($page->additional_css != '') { echo '<style type="text/css">'.$page->additional_css.'</style>'; } ?> So no extra files were needed.

MODx is a great tool. No doubt. However when I compare the code and work required get things done in it versus PW, PW comes out ahead as a winner for the types of sites my shop builds. We are busy converting three content heavy sites from MODx. These were due for upgrades from MODx Evolution. There are another dozen that will be in the switch over queue before too long. I worked with MODx Revo and deployed a few sites on it, but honestly there was a lot of extra overhead and a new API to convert our custom modules (snippets) to. I could not justify the work to upgrade as I did not see enough benefits. Clients will pay for new features, just usually not for the coding required to update the backend. I felt a sense of dread, instead of excitement, when I heard the news of MODx V3. The API has completely changed once already and I was not excited to start over again, again. Not knocking MODx here, built some well performing sites with it. Even donated $. I wish the team continued success. I decided to keep looking around for a better solution. I have used EE, Drupal, Wordpress, Pyro CMS, and a few others. Each with different strengths and weaknesses. Luckily came across PW. Lurked for a while, kicked the tires, built a few mockups. Discovered that all the things I typically need to do, are simple calls to the API, and some logic coded in PHP. Everything is an extension of the API. The front end, the back end. I love the whole concept of leveraging the document tree, getting parents, siblings, children, and the whole ancestry easily through the API. This matches with the type of highly structured sites I usually build. The selector logic make it simple to pull content from wherever it lives. I can park any kind of structured content wherever I see fit. Usually the CMS interferes with the IA. Not with PW. The PW API is very clean and so is the logic. I am very productive with it so far, and it has exceeded my expectations. The content editors like the backend and find it easy to work with and publish / update content. PW has moved front and center in the shop and will be the basis for most all CMS projects going forward. No going back. Kudo's to Ryan and the forum participants, who are generously sharing here. Welcome to PW.

I think you'd need to be more specific in your question and give this context: What will you sell (products, services, e-books, etc)? Will your store need to handle taxes and/or shipping? What payment types do you want to support? What countries are you selling in? Are you subject to PCI compliance? Have you ever managed an e-commerce site before? There is a ProcessWire ecommerce module that @apeisa has built and is building, as discussed in this thread. While I am not an expert on that module, your answers to the above questions may help others to make suggestions as to whether that module would be good for your needs. If you find you can't answer all of the questions above, or don't yet have any e-commerce experience, then my suggestion would be this: Regardless of what CMS you are using, use an e-commerce service rather than trying to run your own. It's one of the most complex online applications, especially with PCI compliance, shipping, and taxes. Personally, I use http://shopify.com and am happy with it. Another user here mentioned they are happy with http://lemondstand.com . Many of these services (Shopify at least) include web hooks that allow you to trigger actions on your ProcessWire site (like creating subscriber access, for instance). This opens up a lot of power without requiring a lot of work or expertise about ecommerce on your part.

I never knew the name for it. It's good to hear that, "flashdata". This was mainly setup so that modules could queue messages that would only be seen on a follow-up page. Since many modules do a session->redirect() after a save, there needed to be a way to queue those messages to be seen on the following page load rather than the current (where they would never be seen). I don't think that you actually have to call $session->message(), as I think any notice sent through message() or error() gets queued. Though calling $session->message() is a good way to make that intention clear from the code side.