Leaderboard

The Google Trends analysis IMO isn't of much help, it doesn't show the inherent "value" of PW as a CMS/CMF, it just throws hard to analyze numbers at the wall. In sheer numbers, WordPress should be the "B357 3V4R" solution out there. WP also benefits from having a LOT of marketing and PR involved, which the PW community doesn't really have (yet?). Look at the ecosystem around Laravel.. Laracasts, dedicated podcasts and blogs, training sessions and communities all over. It didn't get to be known with no effort, there has been a lot of time (and money?) put into it, the creator and his team have explained this numerous times. On another note, I actually have a two-pager to introduce PW to clients, unfortunately it's in French and heavily branded and I don't have much time to translate it right now. But it might be of interest. The main selling points I see and discuss in it — and I'd be very interested to know what's your opinion on this and what has worked well or not so well for you — go like this: Ease of use (for users and devs alike) — self documentation, data validation, fast development cycle Extremely fast — w/o caching, it's fast. With caching, it's fast as hell. Still need moar speed?! Throw ProCache at it and bingo! Static websites with all the benefits of a dynamic system and none of the pain of static generators. And fast websites mean better SEO, better visibility and better conversion rates! Win-win-win! Scalability — Does small and large scale sites really well. Hierarchical structure, when necessary, make it easy to manage content (plus it's built-in search system). Stability and security — Costs less to maintain and isn't very prone to attacks due to its inherent architecture. You don't need to update it every other day. Efficient development — Up to date development paradigms, easy to maintain and develop with growth in mind, content "agnostic" (i.e. it not targeted at one kind of use/market). Most things are already in core, no need to extend the core to do things I consider basic in this day and age, and pay annual fees for them on top of that.. I prefer to invest that time and money helping PW the best I can, that's how open source is best IMO. Relational content — It's hard to explain to clients, but it's seriously what generally cuts in when I need to select a platform for a client and really, PW wins hands down on this. Everything is a page and a page can be related to any other page in the way that pleases you. This enables really powerful contextual information, advanced "member" sections and such. I think that sums it up, then I usually add one or two paragraphs at the end that describes further why PW is a good choice for this project. Most of these arguments have been working well so far.

Hi Henning, I had similar problems with 1&1 and fixed them by installing PW locally, then moving everything to the server (db via phpmyadmin), changing the config.php with the 1&1 db-credentials and finally adding the following line in the config: $config->dbSocket = '/tmp/mysql5.sock'; Not sure where I found it, but worked for me

This is a topic I check out every now and again because, especially on photo-heavy websites, some "seamless" way of resizing images before they are uploaded is something I've always wanted. You know the scenario - someone shoots a bunch of images with their 21 megapixel camera, tries to upload them not thinking about file sizes and the page hangs for ages whilst the image is resized. Or, worse, it times out because you didn't give PHP enough memory or increase the max execution time. I've tried a few PC-based tools to make like easier for clients - some in Windows are part of the right-click menu even, so they just need to remember to right-click and resize. But wouldn't it be nice to have something that does it automatically? Well this might just be the answer: https://github.com/blueimp/jQuery-File-Upload/wiki/Client-side-Image-Resizing - which is part of a larger library: https://github.com/blueimp/jQuery-File-Upload My question, because I just don't have time right now (lame excuse, but I've got a lot on and this may be of interest to you guys anyway), is whether anyone else has tried this particular set of scripts out, or if the image manipulation gurus amongst us (I'm looking at you Horst ) have considered something like this (canvas to blob conversion on-the-fly before upload seems to be what's happening here) or whether something like that seems simply too volatile - I imagine on huge images it could consume a lot of memory on the person's PC, which is still quicker as a smaller file is uploaded, but may have other side-effects. I have used a Java applet in the past primarily to handle huge files, but that also had some client-side image manipulation built-in, but Java is such a security issue nowadays it's unbelievable. Plus it requires Java to be installed in the first place, so something JavaScript-based, using browser features like canvas if they're available seems ideal, with fallback to simply uploading the large file and letting the server resize the image. One to think about anyway. I'm sure the W3C will eventually roll out a recommendation for browser-side manipulation, but as we know update and implementations are always guaranteed to come quickly or work consistently.

Do you get paid for the sites that you would with PW? When you come to the forums to get help, do you limit your questions purely to development work that you are doing for free? I originally developed PW to help us all create better sites in less time, and with more fun. I'm hoping that PW is helping others to be more competitive in all ways, including financially. But recognize that PW did not come into existence on its own. Years worth of time and money has gone into making ProcessWire happen. If you are using ProcessWire to develop sites you get paid for, then you are profiting from ProcessWire. And that's fine with me, no ROI is expected or wanted--I've never asked anyone for anything. But it is disheartening to hear a user make a statement with the implications yours makes. Form Builder is not about making a profit. I don't expect that I will ever make enough on it to offset the actual time investment on it. My hope is that eventually it will be something where the community and myself have split the cost to create. If I wanted a profit, I would go make a Form Builder for WordPress or Drupal where the user base is large enough for that potential to exist. Form Builder is a tool that wouldn't exist if I had to fully self fund it. It's also an experiment to determine if I can reduce my client workload and substitute some of it with ProcessWire-related development that benefits all of us. But I can't substitute something that supports my family with something that doesn't. Form Builder is here to benefit you, not me. If you build sites for a living (or even a hobby) it's going to pay for itself the first time you use it. If you previously spent half a day building a form, now you can spend minutes and get a better, more secure and capable result that can do all sorts of things with the results it collects. Also want to note that Form Builder is something completely different from the original subject of this thread and I don't view them as similar products at all. Likewise, Form Builder is completely different from something like Zend Form or others like it. One does not preclude the use of the other and we should all keep more than one tool in our forms toolbox. I fully support Clinton's project and any others that benefit forms in ProcessWire. Forms are one of the most diverse and important aspects of web development. I feel very confident about the value of Form Builder in your toolbox, so have made it 100% refundable if you find it isn't for you (this type of return policy is pretty rare with digital products).

Today I had to output notes in a form at the frontend. This little code snippets show you how it can be done via the API: 1) One language site: $notesofmyfield = $page->fields->get("myfield")->notes; echo $notesofmyfield; 2) On a multilanguage site if ($user->language->name != 'default') { $notes = "notes{$user->language}"; } else { $notes = 'notes'; } $notesofmyfield = $page->fields->get("myfield")->$notes; echo $notesofmyfield; Happy coding!!

I know... old... This is why I bought form-builder and actually never use it ...

me too! i did some testing on blueimp back in my joomla days and liked it. unfortunately the budget for this job was too small so i didn't realise it and have no "real world experience". it is also capable of uploading very large files in smaller chunks (eg videos). would really be great to have a client side resize in PW 2.7

(Added by Soma) Note that this module is deprecated. The newer and more maintained version is found here: https://github.com/somatonic/Multisite/ You can get the current dev version here https://github.com/somatonic/Multisite/tree/dev (Original Post) Just pushed simple multisite module to github: https://github.com/a...ultisite.module What this module does? It allows you to run multiple sites with different domains run from single install, using same database. While you can easily do "subsites" like www.domain.com/campaign/, this allows you to turn that into www.campaign.com. This is nice stuff, when you have multiple simple sites, that all belong to same organisation and same people maintain. How to use it? Just create page with name like www.campaigndomain.com under your homepage, then edit this module through modules menu and add same domain there. If your domain resolves to same place where your main domain, it should just work. Please notice that if you have editing rights, it allows you to browse the site from www.olddomain.com/www.campaigndomain.com/, but users with no editing rights are redirected to www.campaigndomain.com (this is because session cookie is otherwise lost). Any problems? Not any real problems, at least yet known. Of course think twice when deciding should the site have own install instead of this. There are few benefits, like getting data from other sites, one admin view for all sites etc... but it can easily get out of the hands: number of templates, fields etc.. It is harder to maintain for sure. Isn't there multisite support in core? Yes, kind of. It is very different from this. It allows you to run multiple pw-installations with shared core files (/wire/ folder). This is totally different: this is single pw-installation which has multiple sites running from different domains. This is basically just a wrapper with one config field for this little snippet Ryan posted here: http://processwire.c...ndpost__p__5578 (so most of the credit goes to Mr. Cramer here). What it also does is that it manipulates $page->path / url properties to have right subdomain value.

FrontendUser The FrontendUser module provides a frontend login, logout and user registration functionality. Features See module documentation for details. login with error handling and value sanitizing Plugin: ProcessForgotPassword core module integration Plugin: LoginPersist module integration user registration with username and email address already in use check email adress pre-register validation (email verification) Extendable with additional fields and by PW hooks forms generated by PW form api Custom style / script Requirements FormHelper (0.7.1+) Usage Documentation / examples Repository PW module repo GIT repo ToDo / Issues Issues I hope it will be helpful to the community and I would be glad to get feedback or suggestions for improvement!

I think this idea has come up a couple of times in other threads, but this is just to rationalise it a little. Currently, the Page Table works rather like a repeater in that it is a way of adding and arranging new content in sections via a field. However, because it works in a more public way (the pages created can be arranged within a publically accessible part of the tree rather than buried under admin), the potential for the field is greater than with repeaters. Primarily, there is the opportunity for the field to have the characteristics of a page field. Take this case: A complex, technical article about using Processwire will be much improved by the use of additional information in the form of asides. Using a page table, it is possible to create the five or six asides needed, sort them into the right order and then insert them into the right places using hanna code. (the hanna code could either call them using their key in the array, or by title or by page id, even - if it were displayed) However, in such an article, it would be also very useful to use an existing aside. For instance, the nice aside "what is php?" might be very useful. But that does mean that it needs to be selected from the existing stock and that is not currently possible with a page table, though it is possible with a page field. What it looks like If the functionality were added to the page table field, this is how I would see it being used in practice: On the creation of the page table field, under the option for selecting a parent, a check box is added "allow selection of existing page" When using the field on a template, where currently you have "Add New" at the bottom of the field you now have a second button "Select" This opens up a lister in a modal window where you can select one or more Asides from the given parent as set in the field. These are then added to the list of asides in the field. Preventing Editing One of the dangers of such a system is that the content of a page called by a page table might be edited out of context. Back to our field! A third checkbox says "prevent editing if used in more than one page." Basically, if our aside is used in more than one page it can no longer be edited from the page table field. The only way it can be edited is by going to the page directly as normal via the page tree, and that might be subject to permission restrictions. There may also be a situation where asides are created in their position within a page tree and the ability to edit them via a page table is completely removed for everyone. Perhaps that is an automatic feature where the aside is created via the page tree and not via a page table field. However, in this case where an aside is not editable, another option may be available: Cloning Another possibility is the idea of New from Old. for instance, I want to use that very good aside about what is PHP but I want to add my own relevant information. In this case I can choose my starter aside and click on "Create New from this aside" in the lister modal. A new aside will be created using the same template and the same content which I can then edit. Limiting Inclusion There are situations in this case, however, where an aside has content that is really limited to that one article and should not be reused. (Legal reasons, perhaps, or just simple editorial context). Back on the field settings there would be another check box "allow limited use" Now, when as Aside is created, on the modal window in the Settings tab it has a checkbox that says "Limit to this article only?" This Aside can now not be selected for use by another article. Other Uses Using this modification as an aside is a very basic example, but there are probably hundreds of others. For instance, product variations or attributes in e-commerce where certain variations need to be available to a range of products. With e-commerce, the various restrictions about editing and limiting inclusion would become very important. So there you go, a lot more power and uses. (Note: this might be the wrong starting point, of course, as it could be argued that this should be a modification of a page field!)

Hey, The Form API has CSRF protection build in, but if you for some reason don't want to use the API you can however use the CSRF protection. Its very simple but it took some time for me to find out, so i figured i share my findings with the rest. What is CSRF? First you need to create a token and a token name you do that as following: $tokenName = $this->session->CSRF->getTokenName(); $tokenValue = $this->session->CSRF->getTokenValue(); Very simple. Now what you want to do is create a hidden input field like this: $html .= '<input type="hidden" id="_post_token" name="' . $tokenName . '" value="' . $tokenValue . '"/>'; Now this will generate something that will look like this: You are done on the form side. You can now go to the part where you are receiving the post. Then use: $session->CSRF->validate(); This will return true (1) on a valid request and an exception on a bad request. You can test this out to open up your Firebug/Chrome debug console and change the value of the textbox to something else. Basicly what this does is set a session variable with a name (getTokenName) and gives it a hashed value. If a request has a token in it it has to have the same value or it is not send from the correct form. Well I hope I helped someone.

this is a work in progress... needs testing. in this module the edit links are added to the green boxes using 2 methods: jquery for the page list select and page auto complete, and the native asm select feature for asmSelects (thanks to Soma). Since the PageAutoComplete and PageListSelect are using the hover and icon from asmSelect, the asmSelect assets need to be loaded now on every page edit, in order to make the links look right. if you downloaded this before, please replace with the latest version, as there have been many changes, corrections/bugfixes and improvements. Please report any issues. Updated 12/6/14 at 10PM - please delete earlier versions due to issue with links being added on template editor. Updated 5/7/15: Module removed in anticipation of new official version release: https://processwire.com/talk/topic/9857-module-page-field-edit-links/?p=94599

Please have a look a the actual source-code and not the dom representation of the devtools. They sometimes hide things all together if there's a issue with parsing. The "include=hidden" selector shouldn't matter, as it's only part of getting the page. If your image is shown, then your selector is working. With you stating that it works for logged-in users, could you please post what this shows you if you're not logged in? var_dump($logo->description); Also please make sure $config->debug is enabled, so errors are shown.

I found the solution: you have to include $user->userimage->removeAll(); // wirearray before this line of code $user->userimage = $upload_path . $files[0]; This removes the image array in a first step and then loads the new image in the database.

A shot in the dark: Probably this form is not generated by Fredi, but it just reuses ProcessPageEdit. Therefore you'd need to have a look at this, there are already some topics here about removing the settings/delete tabs there.

I really like this project, but something that i got annoyed is that there is no uniformity how command name:action pair is formed. I don't personally care which way they are but currently there are: mod:enable backup:db I would like to see that it's either of, where it's name:action or action:name pair, so i can rely on some logic. Not a biggie but still Cheers

Hhm, it is still the same as before Have tried with IE, what I don't use normally and have the same behave. Also the site was newly setup today as a new (formerly not used) virtual host on my local machine. With FF I have cleared all browser cache and everything else, - completly and multiple times now. Wirefolder was switched, not merged. The old templates-admin folder was deleted after the first successful request with the new wire folder. That old colors came from a custom css file what was loaded with AdminCustomFiles module. But I have disabled that option and now it isn't loaded and the color isn't overwritten, but the behave is still the same. Hhm, so, what else can I check? EDIT: when hovering over the [ uninstall ] header I get lots of JS console errors: passing empty string to getElementById(), but now I can open it by click and can access the uninstall checkbox! But the behave of the pagination is still weird. EDIT 2: FINALLY SOLVED after dropping / refreshing all from browser cache and double checking the sites and wire folders etc. the only logical thing was that it must be something in the DB. And after dropping once all rows from the caches table it works fine now.

Ok, all new features have now been merged to the master branch. I have changed the release state from Stable to Beta for this release. Really just as a precaution for the Update mode options until I have had more feedback on this. Please let me know how this new version works out for everyone. It will probably take you a while to go through all the new configuration options, but I think it's worth the effort. You can use this module as a simple replacement for the Children/Subpages section of the Children tab (which allows for much quicker editing of child pages), all the way through to a fully customizable CSV import tool for site site editors to create and update pages. Feel free to send through any other ideas along with any issues you come across.

Great discussion everyone. In a hurry, but just wanted to mention that I have used that blueimp uploader on a site for several years now and found it awesome, so these guys definitely do good work!

at the end fo a day a joke keeps the pain away.... http://www.googlefight.com/index.php?word1=Processwire+&word2=Joomlapress sorry no real argument but since we here in "Pub"....i wish a good week.

Just tested this and it works really well. I'm sure there's a more elegant way of changing the settings, but if you put this package on your server, edit js/main.js and change this near the top: $('#fileupload').fileupload({ // Uncomment the following to send cross-domain cookies: //xhrFields: {withCredentials: true}, url: 'server/php/' }); to this: $('#fileupload').fileupload({ // Uncomment the following to send cross-domain cookies: //xhrFields: {withCredentials: true}, url: 'server/php/', disableImageResize: /Android(?!.*Chrome)|Opera/ .test(window.navigator && navigator.userAgent), imageMaxWidth: 800, imageMaxHeight: 800, imageCrop: false // Force cropped images }); Then open the "Basic plus ui" tab on that package with Firebug on in Firefox then you can see it's sending image data rather than a file, so is resizing client-side really nicely. I just tested it on a massive image from my PC and the upload was really quick - I added a 3.5mb photo to the upload queue, it generated a tiny thumbnail instantly and told me it was going to upload just 171.24kb and it did EDIT: 7mb file worked just as quickly. This is like magic!

Haven't tried it and can't provide any real expertise here (sorry!) but the problem is quite familiar. If this solution (or something similar) works, and if we could benefit from it right within ProcessWire's Admin, I'd be very, very happy "ecause you didn't give PHP enough memory or increase the max execution time" tends to be the problem with server-side solutions. There's always finite amount of memory, and vastly increasing memory limits in order to account for some specific memory-intensive tasks means that one can no longer count on the memory limit as a safety mechanism.. and that is just asking for trouble. Same thing goes for max execution time.

There's even this for the multi-language one: $user->language->isDefault() // true or false

Macrura and I have put together a more definitive version of the editable page field which I will post to the module directory as soon as I get a chance. I agree, however, that a "page table meets page field" field is a must down the line. I have a scenario with a client right now where this would be the only ideal solution. The scenario: Client adds a company page with details about the company. Each company can have several contacts associated with it, such as a primary contact and an administrative contact. The user should be able to see some information about each contact at a glance (like a PageTable), and needs to be able to select a contact that already exists (like a Page field) but needs to be able to create and populate new contacts and have them automatically selected (like a PageTable).

Major feature enhancements currently available on dev branch - https://github.com/adrianbj/BatchChildEditor/tree/dev The new config settings rely on the new "OR" options for inputfield dependencies, so this new version requires the dev branch of PW. Please test carefully and let me know if you have any problems or suggestions! Thanks to ideas, testing and feedback from @mr-fan this module now supports the following new features which mostly focus on enhanced, customized CSV importing for page creation: Custom configurations on a page by page basis (on the Settings tab) - you can set up a default config in the module settings, but override these for any parent page. Ability to set up custom titles, descriptions, and notes so the interface can be tailored to the exact needs of your editors with page/template specific examples. Option to have editing tools in a new tab, rather than in the Children Tab. Alternatively, you can now replace the current Children/Subpages list in the Children tab. CSV upload and link to external URL, in addition to the existing textarea manual / paste entry. Ability to predefine "field pairings". This means that editors can upload/link to CSV files that may contain more fields than you want to import, or there are fields in your template that are not included in the CSV. Think of it as a predefined version of the "Connect the Fields" functionality in Ryan's "Import Pages from CSV Files" module. This makes complex imports foolproof for non-tech site editors. I think in most cases this could now replace the need for custom scripts for editor friendly, regular CSV importing. Despite the added options, it should be just as simple to setup as before if you don't need any of the extra features. Here are some screenshots to give you an idea. Shows a very simple, restricted CSV upload setup with custom title, description, and notes fields. Note that it is in a custom labeled new tab, rather than under the Children tab. All the new parent page specific config settings. Note in particular the "Field Pairings" section where you define CSV column numbers to match PW field names. The only thing I am having some issues with is persistence of some error messages - if you have setup some options that conflict or otherwise cause a specific error to be sent, you may need to save the settings a couple of extra times to make the message go away - not sure if this is a PW bug or what at the moment, but it shouldn't affect functionality.

Raymond Geerts, has pointed me a way to swap templates folder based on the hostname. (His post is somewhere here on the forum.) You need to place this code in /site/config.inc Here's my variation: /** * Switch ProcessWire templates directory on $_SERVER['HTTP_HOST']. Type the * Hostname as key and the name of the new templates folder as value. * */ $config->templates = array( 'sub.domain.dev' => 'templates-dev', // domain => templates folder name ); if (isset($_SERVER['HTTP_HOST']) && isset($config->templates[$_SERVER['HTTP_HOST']], $config->templates)) { foreach ($config->templates as $host => $folder) { if ($_SERVER['HTTP_HOST'] === $host) { $config->urls->templates = "/site/" . $folder . "/"; $config->paths->templates = dirname(__DIR__) . $config->urls->templates; } } } Here is Raymond's post.

I think commercial modules are appropriate and should be encouraged. I suspect there are a large number of us that utilize Processwire (and other open source products) to make a living. I think collectively we are fortunate (and spoiled) by the myriad of software available at no cost. Processwire has made a massive impact on my productivity and ability to deliver complex products. If Ryan can develop some commercial modules that allow him to spend more time developing PW (and make a profit on all the work he's put into this truly amazing system), I am happy to support that effort — and if there's a place to donate to the cause directly, I'll be glad to do that as well.

You knew it but you did it anyway... there are many occasions when it is good to shake things up, but I honestly think you didn't choose the proper place, time or words. Ryan already said on the forum that he plans to dedicate more of his time to PW, and that he just has to compensate the loss of money that it would mean for him and his family. He is not forced to discuss this kind of things with us, but he does, and even asks for the others opinions. Code is as good for selling as any other product or service, and I would say, a very honest choice for taking some profit of such a great work as PW is. And hopefully he does. Maybe this discussion will also interest you http://processwire.c...-in-the-future/

Pete, how can i dislike a post?