Leaderboard

I've been working on making repeatable fields for ProcessWire for a couple weeks and actually now have it nearly ready. I need to do some more testing before releasing it, but wanted to give you a little preview. (please view the full screen version for better quality) Accessing repeatable fields from the API is super-easy. They are fully searchable/selectable with the API just as easily as with any other fields. So if you wanted to find all pages that had a buildings field with a floors value of 50 or more, you'd do this, for example: $pages->find("buildings.floors>=50"); Lets say you are on the page with a 'buildings' field and you want to print out all the building names and number of floors. It works exactly the same as page references: foreach($page->buildings as $p) { echo "<p>{$p->building_name}</p> has {$p->floors} floors.</p>"; }

Here's my first draft for the Spanish translation. Please note that: It's fairly complete, but not quite ready for production. Spanish is not my mother tongue (I'm French), but I've been living in Spain for 10 years so it should be acceptable. Contributions and suggestions are welcome. I will post updates as necessary. This is Spanish for Spain. Some parts of the translations might not be appropriate in South American countries for example. In particular, I've used the less formal, more direct version of "you": "tú" as opposed to "usted", which is much more common in Spain. I love ProcessWire and I'm glad I can contribute to this awesome project. UPDATES: December 10, 2013: Translation files updated for dev version 2.3.8 (see "spanish-spain-december2013.zip" below) March 4, 2014: I've created a Github repository that I plan to update whenever possible. All updates will be posted there from now on. June 16, 2014. Update to 2.4.4. spanish-spain.zip spanish-spain-december2013.zip

Continuing from the Repeaters thread about the field-template context… This video demonstrates how you can adjust the admin context of individual fields according to the template they are placed in. When you adjust the context in this manner, it only changes the settings for when a field appears in that template. This expands the reusability potential of fields across different templates, hopefully preventing the need to create another field if all you really needed was a different title, description or width. You can do this same type of configuration when editing a field in a repeater too. View this full screen which should put YouTube into HD mode, where it's much easier to see.

fix here.how is, welcome

Go to Admin->Setup->Fields, then edit your images field, choose Advanced and look up for valid file extensions field.

Yep, that would be good solution. Other thing that people do is to have more deeper structure: /1/1001/image.jpg /1/1002/another_image.jpg ... /2/2001/filedump.zip /2/2002/image.gif ... /10/10201/file2.jpg /11/11390/fileX.zip ... /23/231021/file3.jpg ... /191/1912621/scalesforovermillionpages.jpg ... etc Changing file structure might be hard thing to do, but it would prevent scaling issues with pages where you host large amount of files and use pages as containers for them. Deeper folder structure combined with "folders created when first file uploaded" would be best solution, I think.

This is correct. My own sites depend on it.

If your content structure is well thought, you will automatically have a logical structure for the frontend as well as for the backend. What I'm saying is that you don't really have to think about it as "navigation1" and "navigation2", but as "products" and "articles" instead.

Got it done. Some folks wanted WordPress on this site. But I'm glad it will be ProcessWire! Will keep you guys posted on the project. I am confident everyone here will be pleased after we complete the site. Thank you all for your input!

Thanks for testing. Can you try clearing cache again? I also once thought it isn't working but then it suddenly worked.

unless they decide to quote some funny code that they have seen on a blog

Happy to hear the love is more than surface deep! I'm extremely happy with it so far.

Hi Everfreecreative, I remember having a similar reaction to you when I discovered PW. I have been thoroughly battle testing it on two projects recently and that eureka feeling still hasn't worn off yet. PW is just a dream to work with - especially for designers who like to write their own semantic HTML and not have a CMS generate for you (badly). The new repeating fields and field contexts being worked on are going to be a huge help in delivering a usable admin environment to clients.

Hey Ryan, thanks for the welcome. And thank you for all the work you've put and continue to put into this wonderful application! Whatever I can do to help!

ReCaptcha used to be a bit easier to read for humans - now I usually have to get it to refresh a few times before I can read one as it's got a bit silly lately.

Great, thanks for testing guys. Realized now, that probably no need for "image-crop" permission. Would it be enough to just use page-edit and set cropping permission based on that? Or do you think there could be need to disallow cropping, but allow editing? (vice versa is not even possible, since you need page-edit permission to view that editing page)

Yep - that can often be a worry. The good thing about PW is that whatever hooks your module hooks into will still be here for the foreseeable future, as will the current API. I'll leave it to ryan to confirm, but I don't see the current API calls ever changing to be honest (except in terms of new ones being added) as they're nicely abstracted from the functions themselves, so even if the core code for a $pages->find() call were to change (say something can be refined when PHP6 becomes the norm on webservers in a few years' time) then I still imagine the $pages->find() call in the API will be exactly the same even though the underlying code might get a tweak for performance purposes. Similarly, the hooks that modules use are logically named enough that I can't see them changing either - at least the ones I've used so far. It's this attention to detail - that I'll admit I've only just really thought of in this context - that makes PW considerably more future-proof than other CMS packages. None of this guarantees that modules won't break with new upgrades, but I would say that for most basic module needs that simply use the API to perform certain functions that they would be pretty future-proof.

No, you're not dreaming, but it's like a dream!

Just commited an update to this module fixing an issue with brand new repeater field, where the lock message would appear after saving page.

OK! So I solved everything, and its all working perfectly. I ended up building one hell of a template page. All the javascript and php is contained in this one template page. The javascript ajax resubmits the information to itself, which clears the form, and spins out the email. The action goes to the payment processor's page. All of it works beautiful. Thanks for all the advice. I didn't think about just building it all into one template. I am so so at php, very beginner to advanced things. This is my first site with processwire and I love how smooth things are.