Leaderboard

I've gone ahead and committed the Inputfield dependencies to the dev branch, for anyone that would like to help test. I've also posted a documentation page that explains how and where to use them, current limitations and examples. There are a near infinite number of potential scenarios on how these things could be used, so it's not possible for me to test everything locally. As a result, expect bugs and please report them when you find them. Thanks in advance for your help in testing. For non-default admin themes, some updates have to be made in order to support field dependencies. As a result, unless you are an admin theme developer, it's best to stick to the default admin theme when using field dependencies, temporarily. Field dependencies can also be used in FormBuilder. Though I've not done a lot of testing in FormBuilder yet, so don't recommend using field dependencies in front-end production forms just yet. Though in my initial testing, they seem to work just fine. Thanks again to Antti/Avoine for sponsoring field dependencies!

A customer wanted to disable save ( $config->demo ) for users with a specific role. I created a module for that. If you need it, it's over here. To select the role(s), go to the modules config settings. download at github

Honestly, I think it's a bit soon for considering this. I can certainly make a one to one relation with the time that I spend here helping people (two modules and one language pack are not very impressive to refer ) and the working time that I economize because I use PW and not another tool for my work. I feel that I owe so much to Ryan and to this project (community included *), that I wouldn't try to get a compensation for contributing in the present or in a near future. If someone deserves a compensation for all his time, that someone is Ryan**, and he told already that he wants to get it from his payed modules and not through donations. * I may not ask lots of questions, but I profit a lot in silence from the answers to questions that others make ** I feel that I should open an exception to refer Soma also. The work he has already done for PW is huge (https://flattr.com/profile/philipp.urlich)

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.

Phone Number Fieldtype A new fieldtype to enter phone numbers with 4 integer values for country, area code, number and extension and format the output based on predefined or custom options. StyledOutput The most common usage option will be: echo $page->fieldname //eg. +1 (123) 456-7890 x123 This provides a fully formatted phone number, based on the output format chosen from module's configuration page, or with the format override option (if enabled), when entering a phone number on a page. This is a shortcut that produces the same output as: echo $page->fieldname->formattedNumber //eg. +1 (123) 456-7890 x123 Alternate styled options are: echo $page->fieldname->formattedNumberNoExt: //eg. +1 (123) 456-7890 echo $page->fieldname->formattedNumberNoCtry: //eg. (123) 456-7890 x123 echo $page->fieldname->formattedNumberNoCtryNoExt: //eg. (123) 456-7890 echo $page->fieldname->unformattedNumber: //eg. 11234567890123 echo $page->fieldname->unformattedNumberNoExt: //eg. 11234567890 echo $page->fieldname->unformattedNumberNoCtry: //eg. 1234567890123 echo $page->fieldname->unformattedNumberNoCtryNoExt: //eg. 1234567890 Of course the actual output is determined by the selected format output Raw Output You can output the values for the component parts of the phone number like this: echo $page->fieldname->country; echo $page->fieldname->area_code; echo $page->fieldname->number; echo $page->fieldname->extension; Output for mobile compatibility To get iOS and other mobile platforms to recognize numbers and be able to automatically dial them, use something like this: echo '<a href="tel:+'.$page->fieldname->unformattedNumberNoExt.'">'.$page->fieldname->formattedNumber.'</a>'; Selectors for searching The component parts can be used in selectors like this: $pages->find("phone.area_code=123"); Field Settings There is a field settings for the width of the inputs in pixels. There is a field settings for the width of the inputs in pixels. You can also choose whether to display the country and extension fields for input. Off by default. There is an additional checkbox that determines whether there is an option to override the default format option on a per entry basis, which will be useful when styling phone numbers from different countries on the one website. Off by default. Custom formatting options On the module's configuration page you can choose from predefined formats, or create custom formats using syntax like this: {+[phoneCountry] }{([phoneAreaCode]) }{[phoneNumber,0,3]-}{[phoneNumber,3,4]}{ x[phoneExtension]} which generates: +1 (123) 456-7890 x123 Each component is surrounded by { } The names of the component parts are surrounded by [ ] Two comma separated numbers after the component name are used to get certain parts of the number using php's substr function, allowing for complete flexibility. Anything outside the [ ] is used directly: +,-,(,),x, spaces, etc - whatever every you want to use. There are lots of complicated rules around numbers changing when dialed from different locations. A simple example is for Australia. When dialing from within Australia, area codes start with a 0, but when dialing from another country, the 0 must be omitted. You can write a simple format to handle this. The following truncates the first number from an Australian two digit area code: {+[phoneCountry] }{([phoneAreaCode,1,1]) }{[phoneNumber,0,4] }{ [phoneNumber,4,4]}{ x[phoneExtension]} which generates: +1 (7) 1234 5678 x123 even though the full "07" is stored in the area code field. Where to get Available from github: https://github.com/adrianbj/FieldtypePhone And the modules directory: http://modules.processwire.com/modules/fieldtype-phone/ To Do Need to increase the number of pre-defined formats. There seem to be so many options and no real standards, so I thought rather than create a huge list of options that no-one will use, I thought I'd wait and get you guys to contribute them as you need them. Either post your formats here, or send me a PR on github and I'll add them. How to install Download and place the module folder named "FieldtypePhone" in: /site/modules/ In the admin control panel, go to Modules. At the bottom of the screen, click the "Check for New Modules" button. Now scroll to the FieldtypePhone module and click "Install". The required InputfieldPhone will get installed automatically. Create a new Field with the new "Phone" Fieldtype. Choose a Phone Output Format from the details tab. Acknowledgments This module uses code from Soma's DimensionFieldtype and the core FieldtypeDatetime module - thanks guys for making it so easy.

My fieldset behave perfect, hiding with selectfieldvalue=something. I really like that you can just say "required" for all the fields inside fieldset, and if the fieldset is hidden, then those fields inside that aren't required. Logical and powerful.

oooooh weekend just started! I'm in!!!

You make it complicated where it isn't. I agree it can be confusing if you're not experienced working with PW, but it's as Ryan said we hardly ever need to think about it. But I have to agree with Peter that Ryan mentioned something above which add to the confusion of the confusion even more in that it isn't exactly true or not including all infos (which seems natural to him or us) This is not really the case: echo $pages->get(1733) . "<br>"; echo $pages->find("id=1733")->first(). "<br>"; Will both return pages from the trash! Event the find. No include=all needed. BUT, what what Ryan maybe wanted to say there is that when using get or find with a selector like a usual: $page->get("template=basic-page, isactive=1"); or a $pages->find("template=basic-page, selected_page=1002") ... will never return a page from the trash, unless you add a "include=all"! A $pages->get(1733) is much like saying "SELECT * from pages where pages_id = 1733", will return the page no matter what. So is a find("id=1733")->first(); It feels kinda natural and after using PW API for some time you'll never ask again. But have to agree it can be confusing for people... wait till you start coding modules where there's also no outputformatting and not access aware! If you have some case where you really want to make sure you don't want a page from the trash, just add a check like ryan showed above, or add a status selector.

In case you want it a little more simpler $pages->setOutputFormatting(false); $pag = $pages->find("template=basic-page"); foreach($pag as $p) { foreach($languages as $lang) { if($lang->isDefault()) continue; $p->set("status$lang", 1); $p->save(); } }

Thanks! Just in case anybody else searches for similar things, here's a simple example $en = 'status' . $languages->get('en'); $us = 'status' . $languages->get('us'); $fr = 'status' . $languages->get('fr'); $pag = $pages->find("parent=1072, template='product'"); foreach($pag as $p) { $p->setOutputFormatting(false); // not sure if necessary here - I made it a habit to always include it, just in case... $p->$en = 1; $p->$fr = 1; $p->$us = 1; $p->save(); }

For us it is pure business: it is great to have possibility to buy (or support) development from outside of our company. To get it directly from Ryan is great bonus. To share it open source and make ProcessWire even better is of course superb. The better and more popular ProcessWire is, the stronger our development framework is. It would be great to see fundraising projects for module development. Building open source modules is fun, and I don't believe anyone hates the idea to make few bucks at the same time. But I think there are plenty of real money making opportunities coming now that ProcessWire is gaining more popularity: paid modules, paid profiles, site building, paid support, books, learning videos / tutorials, consulting... Currently PW has still relatively small audience, so I don't believe any module or book can get super high sales. But this is growing audience and very little competition. I would love to see more people trying to make money this way.

In some previous posts, I demonstrated a simple proof-of-concept CRUD “application” for PW using jTable. I really wanted to use DataTables since it is older, wiser and with a huge fan base. One thing I wanted was for the CRUD system to be as simple as possible and possibly be Excel-like (more below). With DataTables plugins, you can perform stuff like inline-editing and Auto-fill. The latter works just like in Excel and allows you to quickly populate cells (quick copy). But that’s as far as it goes. Google led me to other Table management systems. Some of the front runners include jqGrid and SlickGrid. SlickGrid is nice and using virtual rendering can display millions of rows with ease. Its support for displaying data delivered on demand (Ajax/server) is minimal; it requires you to download all your data before it starts manipulating it. Someone has created an Excel-like extension for it allowing copy-pasting between SlickGrid and Excel. Awesome! But, it still didn't rock my boat completely, especially the Ajax content issue. Then I stumbled upon Handsontable, a new kid on the block that describes itself as “a minimalistic Excel-like data grid editor for HTML, JavaScript & jQuery”. Though relatively new, it is as Excel-like as you can get. You can copy-paste from/to Excel [single to multiple cells and multiple to multiple cells], use the usual shortcuts (Ctrl-A, Ctrl-X, Ctrl-C, Ctrl-V, Ctrl-Y, Ctrl-Z - i.e., undo/redo, etc., and tab navigation, etc.), use Auto-fill (vertically and horizontally), freeze cells/columns, make cells/columns read only, Right-click context menus, insert/delete rows and columns, perform inline-editing, etc. Double awesome! Handsontable (HoT) is minimalistic but comes with a rich API. However, most of the implementation is down to you (sounds familiar?). It will render the Table and provide you with Methods/Events/Options to manipulate it. You just have to provide the data as an Array or JSON defining your columns and containing your data. Soma has a DataTable module that is currently read only; you cannot edit the displayed data directly in the table. It is also in lazy development . So, I started toying with the idea of using HoT as an Excel-like CRUD system (module) for PW. I wanted something that could quickly and easily do mass editing (Batcher-like). Imagine quickly creating basic pages/records by copy-pasting from Excel. Or quickly changing records by dragging (Auto-fill) or pasting new values over old ones. Well, the result can be seen in the screencast below. I’d like to hear your thoughts whether this is something that I should consider developing into a module; something that could be used by Superusers. Depending on implementation, it could be used by other users as well. All HoT needs is data. What you do with that data is up to you (the developer) and your code! This can be very dangerous if not implemented correctly, of course! You could easily delete important records! However, HoT does not touch your database! Deletions, insertions, etc., will not alter your database unless you specifically write the PHP code to do that. All it does is send data to the server via a method your specify (post, get, Ajax, etc.), and even that is your implementation. You do not need to implement deletions or additions. You can use it for updating content only or as read only, but where’s the fun in that ? In the screencast , apart from the table itself, all the other implementations are custom - the buttons, selects, auto-save (can be tricky? can DDOS your server?). The current implementation is not perfect; it is a demo after all. Certain stuff would need to be implemented differently . I didn't want to spend too much time on something that would not be useful in the end. All CRUD operations are via PW API and/or vanilla PHP. Deleted pages are Trashed and not permanently deleted. If there is interest for a module of this kind, I would request all the help I can get to develop it please. I would put it up on Github of course. In the demo, this is running off Diogo’s ACP module. Let me hear your thoughts please. Should a module like this see the light of day? Thanks Wasn't sure in which forum to post this...

Edit: durr... I forgot fieldset tabs! http://processwire.com/talk/topic/1592-problem-with-fieldset/ Feel free to delete this post / thread altogether... ===================================================================== Is there a method or module to group a certain number of input fields in a template (backend, edit mode)? I have basically two input field categories - product features and product description. Both categories have 1-2 dozen input fields. Together with all the other fields, it can get messy in the backend, even if I reduce the input field width to 25%. Is there a way to a) move a bunch of input fields to dedicated tabs? or b) include those in a collapsible group that are closed by default? I thought that field groups were the tool to use for this, but I'm not sure if or how.

Just spotted a PW on Nginx installation tutorial on how-to-forge. I quite like that site - find it useful from time-to-time - so big thanks to Falko Timme for taking time to write it up. Nice

I promised I would share my summer-project when I got a bit further along and now most of basic design is up on the test server (still just test content though, only some of it will be there in production). Two pages remain to be styled and some minor touch-ups are left for sure, but the gist of the simple design should be visible. Clean Scandinavian has been the motto. Will update to publishable version over the coming week/weeks. I will also clean up the code and do some validation fixing etc during that time. Any suggestions, pointers and tips from you pros would be much appreciated (tough love is the ticket). Keep in mind that I am not a pro and that apart from a sole static site I helped a buddy with 10 years ago, this is my first attempt at any of this (html, design, php, cms etc), so spare me the sharpest ax. A testament to the Processwire excellence - and to all of you helpful souls on this page - is that I have been able to get at least this far with no prior experience, so I would like to extend a heartfelt thanks to Ryan, Soma, Teppo and all the rest of you that have helped form this product in general, and taken the time to help me out on specific questions. You truly rock! re le vo DOT se/en

Yeah it is, and it's with what I feed my family ( I actually don't get the involved part, as I find ST to be the opposite of most other tools and IDE where I constantly failed to get involved)

I go off to build stuff, come back and get floored with new PW stuff. Man it just keeps getting better! This will be super handy on some sites I have in the queue! Looking forward to 2.4! @Ryan Thanks for your hard work. A big shout out @Avoine and @Antti!

Without knowing or testing it must be status1015=1 (where id is the language)

My bad - I was only thinking front end. On the one PW site I maintain that has thousands of pages, the backend search comes into play - knowing the structure well, I can hop to any page quickly that way.

@Peter, Isn't that what selectors are about? Including and excluding things? If I am getting results that include things I don't want, I have various options to exclude them. PW provides various means to exclude them by very finely tuned selectors - name, parent, child, etc...I would add the trash check; it's simple and effective and will give me the peace of mind that trashed pages will not be returned ...then again, this is just my 2 cts.

There is no different method. The same field can't be repeated on the same page because of how the database is built. The fieldset doesn't take any part on structuring the fields on the database, so you should consider it merely like a cosmetic thing for the admin. Right now, the only way to group fields as you want is the repeater, but I think that in your case the best would be to have independent fields like "group1_title", "group2_title" and edit their labels to read only "title". On the admin side it will be no different from your first idea.

I'm not an expert, and probably others will have better ideas than me, but it seems like you could achieve much of this with URL redirection. You could simply have http://example-secondsite.com/processwire/ redirect to http://example-first...om/processwire/ . Then PW has a user system. You could set up different users and have them access specific things. (I've never used it myself but I'm pretty sure) This way, there's only one core, AND you can "share content". I'm not sure if this is the best way, but you could even have different page trees in PW dedicated to the different sites.

Well, they're also running on a VPS with about 20 other PW sites . But no, it's not the same VPS Antti is talking about. The company actually was the same a year ago, but not anymore.

Kongondo:totally missed that last time. Now I see your comment and agree, that is pretty much same comment

Your first non-working code block doesn't foreach through the $languages array and so $language is probably never defined. As for the variables being printed in the double quotes - that is how php works. In double quotes it works as is. In single quotes you need to do something like: echo '<li><a href="'.$page->url.'">'.$language->title.': '.$page->title.'</a></li>'; Hope that helps.

OK, I just have deleted my fork complete, and then GitHub has created a new one, like the first time. That new one I was able to modify and send as a PullRequest. So, yes I know, - that's not the recommended way to do it, but I need to go to bed and want it solved before.

The next version of PiM will be able to enhance the Thumbnails module (after I have successful send a pull request to apeisa and he have had time to check and implement the code, - hopefully) While writing on the (optional) support for PiM with Thumbnails, owzim has written the js-code that rebuilds the crop rectangle, - and also he has tested and forthrightly commented my various tests with that. Thumbnails will recognize if PiM is installed and use a different routine then. And without PiM the Thumbnails Module will use the PW core ImageSizer. Since dev-version 2.3.3 the ImageSizer uses automatic sharpening after resize. So - once after updating to the new module and a newer PW version (dev 2.3.3 or stable 2.4) everyone has sharpening support. We both (owzim & me) want to have the coords & data stored and pre-selected when coming back to a previous created thumbnail. We use a wrapper class with a read and a write method on a session basis to achieve that. (After closing the browser or otherwise destroy the session, all data is lost) But together with PiM the coords and options can be stored permanent! It can be stored as metadata in a IPTC custom field (2#215) with the original imagefile. If you want enable permanent storage you have to create a config array named imageManipulatorOptions in your site/config.php and create the key thumbnailCoordsPermanent and set it to true: $config->imageManipulatorOptions = array( // ... 'thumbnailCoordsPermanent' => true ); So, - if you don't want permanent storage, you are still able to use Thumbnails Module and PiM together, but without permanent storage. https://youtu.be/IHwjL7YSfRo EDIT: PullRequest is send https://github.com/apeisa/Thumbnails/pull/13 (the unorthodox way)

Ahem...this is what I said in my post above ; (#50)

Sublime Text 2 with plugins: + Package control + Emmet + JavaScript + jQuery + DocBlockr + PHPcs + PHPTidy + Prefixer + SublimeCodeIntel + SublimeLinter + SFTP + SideBArEnhancements + BracketHighlighter + TrailingSpaces + Alignment + Goto Documentation + Search Stack Overflow

Yes, it does work with Fieldsets. The first version doesn't work with tabs (FieldsetTab) though. I think this seems like a good idea Pete. I'll look into how best to implement in the next version. The first version I need to get committed to the dev source tomorrow (30th), so not planning to expand the scope of it this week, but moving forward, would like to continue expanding the dependencies system everywhere it makes sense. And your ideas here do seem like they could be very useful, and may not be very difficult to implement. Something to keep in mind is that dependencies are assumed to be things that can change during the course of filling out the form (i.e. if this field is populated, then this field is available, etc.). So when we get into things like user roles, we're talking about things that don't change during the course of the form. So these would be an entirely different kind of dependency. These would be dependencies that would be applicable before the form is actually rendered. They wouldn't need to be considered by the javascript dependencies at all. As a result, it really might make more sense for this capability to be something separate, at least from the code perspective.

OK...going by your explanation, are you suggesting two separate dependencies here? One for required fields (as per Ryan's post) and the other for Access? Isn't the latter somewhat related to Ryan's module Page Edit Field Permission?

Just wanted to mention some updates I was recently working on. 1. The Cheatsheet is now a ProcessWire Site (since couple months already). This allows for easy updating by team members. Also it allows for implementing stuff that wouldn't be easy with a static html. So all entries are now pages. This was very easy to setup and import the html data via a simple script. 2. Since we now got all the power of PW there, my idea was to create a API doc Site that would serve as a alternative extended sort of cheatsheet. Similar to php.net where you can see more details along with simple code examples and further information like what version introduced or if it's depreciated, related links to other API's. Also there's possibility to add comments. This opens great possibilities to give more information to you, add a "social" aspect, and at the same time also open it for indexing by search engines . You can see the current (not finished) version of the extended API doc here: http://cheatsheet.processwire.com/pages/built-in-methods-reference/pages-find-selector/ We are currently adding content and examples to the API's so this will take some time. Also there will be added some cross linking from the Cheatsheet to the extended docs when ready. Hope you like it. (edit: just realized that this was the 100th response in this thread! great coincidence)

Martijn, This is a good topic. I would be open to contributing (without extra consideration) to module development — especially if the idea was well documented. We would need something like Kickstarter, so contributers would get refunded if the goal wasn't reached.

I understand and know this, but why do you need to get the translation when it is just already there. It will output in the language the user views the page ($user->language) This works just fine in the language the user view the page. echo $fields->get("body")->label; Edit: ah, hm it does not? Ok it doesn't get translated as with page fields. Since it's meant to be used for backend context there's no language value for fields settings. So you either use a $lang variable like this: $lang = $user->language->isDefault() ? "" : $user->language->id; // Default needs no id echo $fields->get("body")->get("label$lang"); Or a little hook to add method to the $fields template API var. // from template or a autoload module $fields->addHook("getLabel", null, "getLabelLang"); function getLabelLang($event){ $field = $event->arguments(0); $lang = wire("user")->language->isDefault() ? "" : wire("user")->language->id; $event->return = wire("fields")->get($field)->get("label$lang"); } // now we use it and it will recognize user lang echo $fields->getLabel("body");

Thanks. I'll try that tomorrow morning. The reason I need it in the frontend is simple: The various fields generate product specifications in the frontend, as lists or tables. Having to hardcode the field-labels for each addtl. language in the template, when it is already defined in the backend, seems unneccessary, tedious duplicate work. Most values are numeric, but the titles (labels) are always strings. I don't think it's that much of a rare / exotic situation. After all, an english speaking visitor wants to see "weight", not "Gewicht". A French guy expects "poids", etc.

I like Ryan's take on that problem, because it seems flexible and clean. The only issue is that the client or CMS user won't be able to see the image he needs, o even worse, won't be able to find it if there's not a descriptive page name. I've been have the same issues that @suntrop describes. I think some kind of visual queue would be more user friendly. The thing is PW won't guess anything about what's in you page (that's great) so it won't classify or make a distinction between a regular page or an image page. This falls somehow short in this kind of situations where you want to select an image page from an assets parent page and it will be hard (for the CMS user) to find it based on a select or text string. Maybe this kind of usage needs another kind of input field. Instead of an asmSelect (and multiple select), there could be an assetSelect, which could display images or uploads to a page in a modal window. Kind of what know Wordpress is using when selecting images attached to a post. I guess this doesn't contradict PW treatment of the data, but enforces the input field concept, which is more presentational and imposes a way of displaying/selecting data. From the distance this would look like an assets manager, but instead the input field turns any page into a an assets manager, without changing any data. Is this making any sense??

Or you could use my ImagesManager module to centralize images. Then use a select to add them to pages. Images are saved as a page. Look in the forum as it's not in the modules repository.

Perhaps I don't know what exactly you mean by 'the easier pw way', but I guess it'll be more time consuming and more difficult to configure all sliders on different pages and connect them with a plain drop-down select field (if there are more than a couple of them). TinyMCE isn't a good choice either here, because it is just a matter of time when there is HTML code in it that makes things messy Thanks pideluxe! Don't get me wrong guys I like what I see here in PW, but I am used to manage assets a different way and have to find the best solution for now. So … thanks again for your help!!

This is my first attempt with Processwire. I must say that I am impressed with this CMS. I know Drupal, Wordpress, Liferay, Concrete5, and so far, PW would be certainly on top of the list now (perhaps at the same level as Concrete5). My mother had made her own website with FrontPage. So all photos are from her, and I did only structure it with Processwire. The site use basically four templates. 1) Front 2) Front-mosaic 3) Mosaic, and 4) Basic (used in the timeline). The site is not finished. It was done in 20 hours (5 hours for the design process, 5 hours structuring the site, 10 hours creating pages and dumping the photos (there are a lot!). http://irenegiguere.com

Hello all, So I've been asking way too many stupid questions on forum to turn an idea into reality. I've finally launched a basic version of the drama booking website. Still many important things like Payment & sms gateway are remaining but that too will be added soon. Allow me to present you Ticketees.com (Credits: http://ticketees.com/humans.txt) It's been out & being tested and used by drama producers for almost a week now. We've got some very positive response. It wouldn't have been possible if I hadn't learnt so much from Ryan & ProcessWire's community and ofcourse, ProcessWire itself. I've very very thankful to each & everyone who made it possible. There's a long way to go, many many things are left to be done. I'd like you all to see and give me your honest feedback, good or bad, help me improve it. Thank you all once again.

Hi Peter, That's because all the API variables like $users, $page, $pages... are not known to the function. PHP - scope problem. The solution is to use the global wire() function from Pw to get the API variables: $vista = wire('page')->vista; // ... if (wire('user')->language->title != 'no')) { // ...

WOW!!! It works! Wanze, thank you for help! - I've started to think that problem doesn't have elegant solutions in PW. But you proved that PW has such solution! P.S. hope to see this kind of hints documented sometime by core PW team!

Hi valan, I've found a solution. The translations of the labels (not default) are stored in the 'data' field in the 'fields' table, as JSON. Example: {"label1012":"Weight"} where 1012 is the ID of the language. You can try this code: $label = 'label'; if ($user->language->name != 'default') { $label = "label{$user->language}"; } // Output label in correct language echo $user->fields->get('field')->$label;

There's at least one somewhat similar topic here. Piece of advice: forum search isn't very trustworthy, do a Google search and add "site:processwire.com/talk/" instead. Works so much better As for your question, I'm an Emacs user. If I had to work with something else, it'd probably be NetBeans. Both of those are simple yet configurable and extendable -- very important features for proper IDE. Most Windows IDE's (don't really know anything about Mac-specific ones) have way too much bloat right from the start. I simply can't stand all that noise.

Can anyone like a post of mine? 666 is evil edit: thanks Wanze

How much time per day do you spend looking at the light of the screen? I would guess too much... I prefer to stay away from it as much as I can, and reading on paper is great for this. Plus, you can do it on a coffee table outside or on a bench by the river Now I bought a kobo e-reader. With the e-ink technology It really feels like paper and I recommend it to everyone.

Regardless of whether handling this with processwire you should change your server variables to handle such a request. Your php.ini should be adjusted for it (at least): upload_max_filesize = 350M post_max_size = 350M And your apache should be configured too: memory_limit = 400M Update (thx Wanze) You should also adjust settings like max_execution_time max_input_time in your php.ini... I don't know if your clients host has such capabilities (-> memory limitations for such one vhost) but you should consider to convince your client to upload such files with ftp (not with http) and it is less error-prone for you and him with ftp...

I've set memory_limit same as post_max_size and upload_max_filesize to recreate the case on test server. In conclusion, memory_limit is the cause of upload failure. Memory_limit should be increased to accommodate upload and other functions. It is why small files upload just fine, but large files not. Problem solved.

Result of 50MB file upload via InputfieldFile ---------Firefox upload test----------------------------------------------------------- Progress bar stalls at 99% ---------Console output----------- [22:28:41.797] SyntaxError: JSON.parse: unexpected character @ .../wire/modules/Jquery/JqueryCore/JqueryCore.js?v=162:16 ----------PHP error log---------- [00:28:41] PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 50000001 bytes) in Unknown on line 0 [00:30:10] PHP Warning: Unknown: open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (/home/pws/:/home/pws/store/openssl/) in Unknown on line 0 [00:30:10] PHP Warning: File upload error - unable to create a temporary file in Unknown on line 0 ---------Chrome upload test------------------------------------------------------------ Progress bar stalls at 100% ---------Console output----------- Failed to load resource: the server responded with a status of 404 (Page Not Found) Uncaught SyntaxError: Unexpected token < JqueryCore.js:16 e.extend.parseJSON JqueryCore.js:16 $.parent.each.fileData InputfieldFile.js:171 ----------PHP error log---------- [01:15:41] PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 50000001 bytes) in Unknown on line 0 --------IE upload test------------------------------------------------------------ Upload doesn't begin; Ajax doesn't function.

For US hosting I can't recommend Liquidweb highly enough. For cloud hosting, which suits me better on one of my higher traffic websites, I use their other company Storm on Demand. I use them because I've never had any real problems in the past several years with them, and it's managed VPS so I don't have to spend time installing modules or upgrading things. They're always happy to install modules for you on your VPS and do pretty much whatever you ask them to do. The bit that I really like though is that they proactively monitor their servers. Once when there was actually a problem and the server hit a fatal issue in the middle of the night, their monitoring software sent me an email saying there was an issue, had automatically rebooted the VPS less than a minute later and I was emailed once again once it was back up. Then a technician sent an email a little while later saying it was a hardware fault (this is on Liquidweb, so not the cloud hosting) and the faulty hardware was replaced very quickly. All the tech support emails to me occurred overnight and my site was down for no more than a few minutes at most - on other hosts I've experienced hours of downtime and it's often only when you get a client calling you that you even realise there was a problem to start with - that obviously doesn't look professional! They have their own datacentres too, with a new one finished recently and are showing no signs of slowing down, so I'm not worried they're going to disappear off the face of the planet one day either. For hosting my UK sites I use EUKHost. My experience with them is mixed on the support-front (seems to depend who you speak to at this company which I've experienced many other places too), but generally positive on their VPS offerings and the prices are very hard to beat. Their VPS packages are also managed and their staff are also happy to install anything you need - I even have several caching modules and FFMPEG on one VPS, the latter being something that not a lot of hosts will install as it can eat up quite a lot of system resources, but from what I can tell EUKHost don't oversell so it's not a problem. Another great company I've used before in the US is Site5. They're still going strong and the only reason I moved away from them and ended up at Liquidweb is because I needed a VPS at that stage and they didn't offer them at the time.