Leaderboard

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

I'm building up a ProcessWire boilerplate for quick starting the post-installation work. I've got a basic .gitignore which covers ProcessWire ignores, as well as other ignores for the rest of the project. You can find it here: https://github.com/fixate/pw-boilerplate/blob/master/!root/.gitignore It's based off of Ryan's SkyScrapers .gitignore: https://github.com/ryancramerdesign/ProcessWire/blob/master/.gitignore but keeps certain files, such as .htaccess (we use a custom one which extends ProcessWire's with H5BP's), in the repo so that they are available to team members. For this same reason, we never ignore .gitignore itself; it must be available to all team members. You can safely remove the styleguide and Grunt stuff if they're not part of your projects.

This would for sure be a Lennon/Chapman thing

First off, I won't stop developing ProcessWire unless I'm dead. But lets say that one of you showed up at my door and shot me, and then I'm gone for good. This is free software and you don't get any guarantees there, no matter what CMS it is or how big the community or adoption of it is. But what you do get is the source code and permission to use it and do with it what you need to. There is far more security in that than any proprietary or commercial system. We should all feel very lucky that this project has attracted such a capable development community around it (more than any project I've ever seen), and there are several guys here that are fully capable of taking over the project if I go down in a hang-glider crash. I'm always reluctant to list off people because there are so many people that contribute to the core and I don't want to forget anyone. Suffice to say, I may hold the keys to the master GitHub account, but this is a project of many developers, at least 5 of which are fully capable of taking over the project if I kick the bucket. I'm certain that some of these guys could do better than me with it. Please don't take that as an invitation to show up at my door with a weapon. But I would suggest this may be better odds than with the bigger projects you'd mentioned. Lets also point out here that ProcessWire is not WordPress–it does not need daily updating in order to keep running. Most sites I build with ProcessWire are running the version they are launched with. With ProcessWire, you do not need to upgrade your site every time a new version comes out. You can generally upload it and forget it, and it'll keep running till the site as long as the server itself is running. What other CMS can you say that for? (I can't think of any) Personally, I think adoption of something like Drupal, Typo3, Joomla, etc. is more of a risk, because you are dealing with a legacy platform – you are adopting technology from 10 years ago. You are also adopting something that is a target for hackers and spammers. WordPress is perhaps the biggest target, and something I've very apprehensive to setup for clients. Ultimately when a company chooses to adopt a legacy platform because "it's what the clients know" or [more likely] what they themselves know, it's a lazy decision. It's not looking out for the clients' best interests, and it's pursuing mediocrity. When you pursue mediocrity, you pay for it in the long run. There is no better testament to that than the legacy platforms that agency seems attached to. 1-3 years after installing [Drupal/Joomla/Typo3/WordPress/etc.] for the client, they are going to be looking for "something different" in terms of the CMS (we all know this) and they won't be coming back to the same agency. The agency that thinks it's playing it safe is really just hurting themselves when they give their clients something tired and mediocre that anyone can give them. Instead, give them ProcessWire, and they'll know you are different and better (a secret their competition does not have), and they'll be a lifetime client.

Field dependencies are coming in ProcessWire 2.4, and I just wanted to give you guys a little preview of it. The development of this new feature is being sponsored by Avoine, the company where Antti works (he also specified how it should work). Field dependencies are basically just a way of saying that one field depends on another. It dictates which fields should be shown in a given context. In our case, it also gets into whether a field is required or not. This short video demonstrates how it works: (switch to the 720p and full screen version, as YouTube's default settings for this video make it impossible to see): // Edit @Adamkiss: Here's link for those on mobile: youtu.be/hqLs9YNYKMM The implementation here is done both client-side and server side. Javascript handles the showing/hiding of fields and the required vs. not required state changes. On the server side, it doesn't process any fields that aren't shown, and honors the required rules. A separate processing occurs both client side and server side, ensuring that the user can't make their own rules by manipulating the markup or post data. These field dependencies can be used with any Inputfield forms. That means you'll be able to use it not just in ProcessWire, but in FormBuilder, and via the API too. It's very simple to use from the API. All you have to do is specify a ProcessWire selector to either "showIf" or "requiredIf" to the Inputfield, and ProcessWire takes care of the rest: // show this field only if field 'subscribe' is checked $inputfield->showIf = "subscribe=1"; // show this field only if 'price > 0' and at least one category selected $inputfield->showIf = "price>0, categories.count>0"; // make this field required only if 'email' is populated $inputfield->required = true; $inputfield->requiredIf = "email!=''"; This feature will be in the 2.4 core (rather than as a separate module), so it will also be ready and available for things like module and field configuration screens.

ProcessWire is fast. With ProCache, ProcessWire is insanely fast! ProCache provides the ultimate performance for your website by completely bypassing PHP and MySQL and enabling your web server to deliver pages of your ProcessWire site as if they were static HTML files. The performance benefits are major and visible. Using ApacheBench with the homepage of the Skyscrapers site profile, we completed 500 requests (10 concurrent) to the homepage. The amount of time occupied to complete each of these was as follows: 29 seconds: no cache enabled 6 seconds: built-in cache enabled 0.017 seconds: ProCache enabled As you can see, the performance benefits are substantial. ProCache gives you the ability to drastically reduce server resources and exponentially increase the amount of traffic your server can handle. This is especially useful for traffic spikes. Beyond measurements, ProCache makes your website feel faster to users, respond faster to search spiders (which can help with SEO), and helps to conserve server resources for requests that actually need PHP and MySQL. ProcessWire is already very fast, and not everybody necessarily needs what ProCache delivers. But regardless of whether you need it or not, there is little doubt that you can benefit greatly from ProCache. For an example of ProCache in action, visit processwire.com or the skyscrapers site. Look in the lower right corner of the page (in the footer). If it says "ProCache", it means the page was delivered via ProCache. We did this for demonstration purposes (ProCache does not put anything in your markup unless you tell it to). More information about ProCache can be found on the ProCache documentation page. Please note There is a known issue when using ProCache with the LanguageLocalizedURL module. I hope to have this figured out soon, but for the moment you should not use ProCache in combination with that module as it doesn't appear to work in full. ProCache does not yet support multi-host capability (i.e. cache and delivery of different content per hostname), but it will very soon. How to get it Like with Form Builder, ProCache was produced as a commercial module to support development of ProcessWire. It is now available for purchase here. ProCache is in a beta test period. As a result, it's being offered with introductory pricing that may increase once we're out of that period. During the beta test period, I just ask that you let me know if you run into any bugs or issues during your use of ProCache. I also recommend that you follow the usual best practices with regard to backing up your site and testing everything before assuming it's all working. Beyond the introductory pricing, you may also use coupon code PWPC-BETA for 10% off the listed prices at checkout. This code will expire as soon as we're out of beta. When you get ProCache, you'll also get 1-year of access to the ProCache-members support and upgrades board, available here in the ProcessWire forums. Upgrades to ProCache will also be posted there for download. Disclaimer: At the date/time that I'm writing this, I think that I am currently the only one using ProCache in production use. That's why I'm providing it with the lower costs and coupon. If you are running production sites where everything must always work perfectly, you will either want to: 1) wait to install on important sites till it's out of beta; or 2) test thoroughly on a staging server or localhost before taking it to production use. In either case, always make sure you have good backups anywhere you install new modules, and always test to double check everything works how you want it to. Get ProCache Now ProCache Documentation Below are a few screenshots that show the configuration screens of ProCache. Have questions about ProCache? Please reply to this topic. Thanks for your interest in ProcessWire ProCache!

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

You can do it even in the site. Just go to the file you want to change and edit it. They will ask you if you want to fork the whole project, you just have to say yes and edit the page to make a pull-request.

Thanks, and sorry for not getting back to this thread sooner. Jonathan's suggestion worked, and Ryan's reply was enlightening. I had a feeling ignorance was the problem. Obviously I had some catching up to do on PHP namespaces. I also had a nagging feeling of what Ryan said, that you are better off avoiding globals. Eventually I rewrote the code to avoid them. Thanks again for your help. I am new to this community, and relatively new to Processwire, and I am very impressed by both.

Thanks for the help and info. Really appreciated. apeisa. I feel the effects already

Adrian, thanks for your work on this. I am super busy at the moment, but I have great plans for this (reusing common templates etc..). Will definitely give this good ride soon.

https://support.google.com/drive/answer/55244 http://office.microsoft.com/en-001/web-apps-help/share-it-embed-an-excel-workbook-on-your-blog-HA102029502.aspx https://zohowikihelp.wiki.zoho.com/Embed-Zoho-Sheet.html

I can confirm the inflexibility. I even translated the newest version of the extension SEBLOD CCK to Finnish and now I will never use it.. I also used Yootheme's Zoo, which was ok at the time. What's interesting is that Yootheme just announced a new CMS built with Symfony: http://pagekit.com/ It uses their front-end framework: http://www.getuikit.com/

wire('pages') is equivalent to $pages. You use it exactly in the same way: $day_shows = wire('pages')->find("show_datetime={$this_date}"); Same goes for the other API variables: $page = wire('page'), $input = wire('input'), $session = wire('session'), etc... Happy Diwali!! (just checked on wikipedia ) --------- edit: speedy nik

Yes, $pages is not defined and thus the error. Replace this: $day_shows = $pages->find("show_datetime={$this_date}"); with this: $day_shows = wire('pages')->find("show_datetime={$this_date}"); And the same goes for other PW variables listed in http://processwire.com/api/variables/. So $page --> wire('page'), $templates --> wire('templates') and so on.

I would add a JS object to the page in your <head> tag, from your template file. For example: <script type="text/javascript"> var user = {}; user.lang = "<?php echo $user->language->title ?>"; </script> Here, I have specified that user is an empty object, and setting the "lang" property of it to the value from PHP $user->language->title. This way also allows you to add other properties to this should you wish to use more user attributes in the future. You can then access it from javascript as any other object/variable: if (user.lang == "no") { // one thing } else { // another }

Hi! Just a quick suggestion: is that block of code inside a function? If it is, then variable $pages is not accessible there but you need to use wire('pages') instead. This is because of variable scoping in PHP, see for example http://processwire.com/talk/topic/3056-cant-use-input-urlsegment1-in-a-function-is-this-my-php-weakling-status-showing/ for some more information.

I'm not sure why it wasn't working in my case, but will try again. Good to know how the capability is provided (collagePlus), I like it so much you have me thinking this should be the default output.

Greetings, I felt a needle-like pain in my head, and wondered where it was coming from... Ah, there it is -- Joomla and Artio. All jokes aside, it is true that in Joomla there are ready-made components that take care of a whole range of actions. But then you have to override what you don't want or need, wage mortal battles where various pieces of baked-in Joomla code conflict with your modules and plugins, and spend hours trying to get a developer's attention long enough to figure out where in the world they placed the code for a particular action you need to customize, and why they put it there. And let's not forget that no Joomla component can be used without... Joomla! Which means you are also inheriting its migraine-inducing template system, admin area, lack of custom fields, mind-numbing dummy menu entries and plugin ordering (Joomla people will know what I mean by these last two). OK, let me take a breath... I understand the idea of using something that has "been done already." But since I started using ProcessWire, in all seriousness, it takes me less time to create something from scratch than to wrangle with any of Joomla's "ready-made" code. Two better ways to go: 1. Get part-by-part help from the community 2. Find ready-made JQuery, PHP, and other components that can hook into ProcessWire Thanks, Matthew

In your field settings, for your TinyMCE advanced settings under "theme_advanced_buttons1" you currently have this: formatselect,|,bold,italic,|,bullist,numlist,|,link,unlink,|,image,|,code,|,fullscreen Try changing it to this: formatselect,|,bold,italic,|,bullist,numlist,|,forecolorpicker,forecolor,|,link,unlink,|,image,|,code,|,fullscreen Note I added "forecolorpicker" and "forecolor". They are two versions of the same thing, so you'd probably remove one or the other after trying them out. Also google them and it should bring up something at the TinyMCE site for other color picker options, like one that would handle background colors. These are just the two that I know off the top of my head. Next in your "valid_elements" setting, you'll want to enable use of the "style" attribute. I won't post the full valid_elements because it's quite long, but here is just the first part as it would appear currently: @[id|class] You'll want to change it to this: @[id|class|style]