ryan

Pages would work just fine for this. But that's a pretty specific need and Oliver's recommendation is a good one. If you wanted something quick 'n dirty, you might also use a small text field and spell out what I was wanting from the site editor in the field's description. During output, if the value doesn't match the expected format then you skip it or substitute a default.

Darn, I just wrote up a long reply and accidentally closed the window trying to do a screencap. I've run out of time to redo it, but going to try and summarize: You can sort of use repeatable fields for this now, but they won't look like a spreadsheet Repeatable fields aren't ideal for this because they can support ANY fieldtype. In a grid/spreadsheet view, you only need to support limited data types. I think it would work best as it's own FieldtypeMulti, where it manages it's own data with columns in a table… more traditional database style. PW API supports searches in anything that has it's own column in the DB schema, so long as an index is defined for it (in MySQL). This would be more efficient in this case because the limited set of data types you'd need to support line up nicely with how you'd define a DB table. Pages are of course a lot more flexible, but you don't need that flexibility here. I've built fieldtypes like this for managing property availability and rates. It's not hard to do by making your own FieldtypeMulti. This is exactly what the FieldtypeMulti class is designed to do. (FieldtypeComments and others are based on it). The main challenge in this Grid Fieldtype would be in making the schema configurable per field, but I still think it's well within reach. Sorry, I missed that before. I fixed and committed it over the weekend. Repeater fields are meant to be iterated like any other group of pages, and they are technically no different. That means you have to foreach() them and output them in the manner you want. I will probably include some default render() method in there in a future version, but it would mainly only be useful for testing/debugging. There is also an example of how to output repeater fields on the first page of this thread. I'm glad to report that Template>Field contexts are now completed and working. I'm going to be testing here more before committing to the core source, but wanted to let you guys know you'll be able to use them in the next week. I'll be posting a video in the next day or two. Also, I have limited the field properties that can be configured per-template to include just these: Label (including all languages) Description (including all languages) columnWidth Visibility (collapsed settings) I think these are the most likely ones to be configured in this manner. Though technically, the core can support configuration of any field property (including all custom ones defined with an inputfield or fieldtype). But I've specifically disabled those for now as it makes me think I'd need to do a lot more testing before putting this out there. I'll probably enable it as an advanced mode option for anyone that wants it, after confirming that everything works well with these basic settings in lots of different contexts.

This single vs. multiple has come up several times with images. I should probably have the Pageimages (multi) class look for size() and throw a specific error that answers it. --- Edit: I also recommend adding this: if($tdobject->icon) { /* then resize */ } or if a multi-image field: if(count($tdobject->icon)) { /* then resize */ }

Slkwrm, it looks like the problem is in the first translation. You just need to translate "en" to "ru". That text is yellow is a note for the translator about what that field is for, not text that needs to be translated. So if you replace the first translation with just "ru" it should start working.

PawelGIX, great job and great first post! Thanks for taking the time to make this translation and welcome to the ProcessWire forums!

If you want a really simple captcha that's very effective, add a dummy field near the top of your form like this: <textarea id='my_message' name='my_message'></textarea> Then have your CSS stylesheet hide it: #my_message { display: none; } Then on your form processing, add this check: if($input->post->my_message) { // message is very likely spam so skip or send it to your spambox mail('your.spam.email@company.com', $subject, $message); } else { // message is good mail('your.email@company.com', $subject, $message); } Other captcha solutions would be to add a "What is 5+4?" and verify that they entered 9 (using a method like above). Or add in a captcha service like Recaptcha.

It's true that the htaccess doesn't change very often, but when it changes, you want to be sure to get it. So I think it's best for people to include that (and /index.php) in addition to replacement of the /wire/ directory, when doing an upgrade. If you look in PW's htaccess file, you'll see it's very clear about where the ProcessWire directives start and end: ##################################################### # START PROCESSWIRE HTACCESS DIRECTIVES # @version 2.2 ##################################################### ...and all of PW's htaccess directives go here... ##################################################### # END PROCESSWIRE HTACCESS DIRECTIVES ##################################################### So when I'm customizing an htaccess, I either place my custom directives above ProcessWire's, or if they need to go somewhere in the middle, I add a comment to make it clear that it's specific to the site I'm working on, and I indent it more than the others so that it stands out even more: # THIS DIRECTIVE IS FOR DI.NET ONLY: RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] This makes it really easy to manage a customized .htaccess file through upgrades.

I think it makes sense for us to not keep around empty directories. I'm planning to make an update that will provide a config option to disable automatic directory creation, limiting the creation to when a file needs to go there. If all seems good after trying that out for awhile, we'll probably make it a default.

PW guarantees a directory for each page so that module developers always know there is a dedicated space for every page on the disk. Though I'll take a closer look, perhaps I can modify this, as it may not be that important. You could go in and manually delete the empty directories if you wanted to, but PW would re-create one for the page the next time the individual page is saved. I'll see what I can do. We can't use a common directory for a template just because PW wipes out the entire contents of the page's directory when the page is deleted. In this manner, PW will ensure the page really is deleted and not have leftover files from some module or something else. Keep in mind that a page's template can also change, which adds more variables to the mix, so it's best that we don't mix files from multiple pages into the same directory. The cache files are kept separate from the page's files just so that the cache can be wiped out in one shot.

Great site AnotherAndrew! Seems like it showcases the art very nicely, and encourages you to browse a lot. The text-based pages are also very readable and nicely done.

The ones in /site/assets/cache/Page are optional, as you can disable the cache on any templates where you don't want it to create cache files. But the ones under /site/assets/files/ are required at present, as every page is guaranteed to have a directory placeholder on the file system. So if every one takes up 4k, I'm estimating that's about 109 megabytes (?) that will be required to maintain the 28k pages on the file system.

I have this setup and working, so should be able to commit it to the source here within the next few days. While I think there are a lot of good ideas here with regard to how to go about it (and possible future directions), I'm taking the quick+simple route for now. This will solve the majority of adding-page-reference needs for me at least. So the way this is setup, you could paste in a few hundred pages to add if you wanted to. Also, this works with all the page reference inputfields (checkboxes, selects, asmSelect, radios, autocomplete, PageListSelects, etc.) This was easy to do, because InputfieldPage is already serving as a container Inputfield for all the others, so it was just a matter of having that module append to the output of the selected inputfield module. Check out this brief demo: In order to use it, you check the box on your page reference 'input' tab settings, like shown in the video. Your page reference field has to have both a parent and template defined with it. It also has to use the 'title' as the label field (which 99% of the time I'm sure we already do). If the user doesn't have access to create new pages in the parent or with the template, then the option to add new pages won't appear. If used with an inputfield that only allows selection of a single page (rather than multiple pages) then it gives you an <input type='text'> rather than a <textarea>, since you can only add/select one page in that scenario.

I agree with everything that Oliver said. 1. Importing should be no problem. 2. Currently you can't do exactly what you've mentioned in #2 without getting into some custom module code. Depending on the scope of what you want to do, I would probably suggest building a front-end to do what you want, and use ProcessWire for it's API to manage the data and users. Since your access needs fall outside of the typical role-based situation, you may want to just name the pages they can edit to be the same as their user ID or user name and then perform your access check at the top of the template file. Basically checking that the page name is the same as the user name before you let them view and/or modify it. 3. This is not planned for the form builder. Though Oliver is correct that you can do this now at the API level.

Looks like there is a blank line at the top of /stie/modules/Shop/ShoppingCart.module. Delete that blank line (so that <?php is the first thing in the file) and that should fix it.

Yes--they are actually both OSCommerce (ZenCart is an upgraded fork). My opinion is I would avoid OSCommerce and the forks. I have had a lot of experience with OSCommerce, but very little with ZenCart. However, my experience with OSCommerce left me feeling that I probably would not want to use a fork of it.

I think we're going to be adding this to the planets tutorial and presenting it as a 'planet_type' variable, like another person suggested.

Thanks. I agree this does have potential to reduce the number of fields you might need, or at least, allow you to be more specific and contextual with the information you present with the fields. Ultimately it should lead to a better experience either way.

Thanks Hani, I have updated the module to add a new 'recurring' option which is set to true by default (and translates to singleevents=true' in the URL).

Alchime, I actually have not tried out that tutorial yet, so need to take a closer look at that. However, attached is a template file (basic-form.php) that is ready to use as a basic contact form with the default site profile. Let me know if this is helpful? basic-form.php.txt Note that you'll have to rename this to basic-form.php, place in /site/templates/. If you want it to email to a specific address (rather than the superuser) than edit the file and enter your email address in at the top where it says to.

That applies to PHP4 which did actually have OO bolted on. But PHP5 is a different beast that's been built around OO. PHP4 and PHP5 are like two different languages when it comes to OO. I can't say as though I agree of being jealous of Python (or Ruby) syntax. Nice languages, but we just didn't make a connection despite a lot of effort. Ruby especially left me tired... felt like working in a cubicle. This is my experience, but I know everyone is different. PHP is such a workhorse and seems to be the language of people who get stuff done, more than any other. Something about PHP also seems to drive creativity that the others don't. Still, it's not for everyone and thankfully there's much to choose from.

I agree, responsive sounds great. As far as I know, Kickstart is not responsive (or at least not built in)? Outside of that desire, it seems pretty fantastic... I'm going to be experimenting with it here on another project.

Welcome to the forum! I'm on a mobile phone, so have to keep it short--Those 'defaults' settings are really only good for when the field is first created. Your best bet is to edit the settings of the field using tinymce instead. You'll find this by editing the textarea field, clicking to details, then editing the tinymce advanced options'.

I agree, it would be very handy and I've been wishing for this on many occasions too. Most likely we'd just add it to InputfieldPage, which is the container Inputfield for all Page selection inputs. I will put some more thought to this to see how we might implement it.

In earlier versions of PW it was possible for usernames to be email addresses, but when users were switched to being pages, the usernames had to be compatible with page names. That pageName function you mentioned is the way to go, and username() should probably be deprecated or redirected to the pageName function, like you mentioned (something I need to do).

Soma, Diogo: you'll be glad to know I've taken a close look at field template context and how we might support it in the core. It'll be simpler than I thought, so there's a good chance I can get this in version 2.2, relatively soon. Now that I understand how we'll do it, I think we'll be able to provide template context of almost any field setting (custom and internal). So it will likely go beyond just title, description, collapsed, width, etc. To change the context of a field within a template, you will edit a template, then click on a field name or edit icon (in the asmSelect). It'll open a modal window with all the field's configurable settings, all within the context of the template. I think this will be pretty cool.