ryan

/site/templates/categories.php <?php if($input->urlSegment1) { // you'll have to enable urlSegments in your categories template $s = $sanitizer->pageName($input->urlSegment1); $category = $pages->get('/products/categories/$s/'); if($category->id) echo $category->render(); else throw new Wire404Exception(); } Let me know if this is what you were looking for?

I tried Magento as well before going with Drupal UberCart. I felt like there is probably a lot of great stuff there, but wasn't accessible for me to learn it in the time I had to setup a store for the client. I contacted Magento to assist, and they wanted $30k USD to get the basics going. Perhaps that's a good deal for some, but it was out of reach for me. It made me think that Magento was probably too complex and expensive for me. After successfully getting Drupal and UberCart setup and running (which is somewhat complex in its own right) I was glad that I didn't continue with trying to get Magento going.

Thanks Soma, tested here and all seems to work well! Thanks for resolving this issue.

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.

You guys are right about that. Looks like I removed a check_access=0 from the selector to make sure it was working and neglected to add it back. Sorry about that. It is fixed in the latest commit.

Christoph, it's hard for me to tell for sure how to locate the error without actually seeing it. If you have an admin login you can PM to me, that might help me to see what's going on. Another thing to look at is: Pages > Admin > Repeaters > [your field name] > for-page-5799 (this is where it stores the repeater pages), and see if there's anything there that doesn't look like the others. As for displaying the repeater pages, could I see the block of code you are using to display them?

Soma, I actually did run into the issue where I couldn't change a URL for an existing link recently. It happened on a client's site. Then I couldn't reproduce it locally, but clearly there's an issue. Thanks for your work in helping to resolve this. If you think it's ready, I will go ahead and commit your solution to the source (unless you prefer to do a pull request). Or let me know if you think more testing is needed here and I will plan to work on it as soon as possible.

Welcome everfreecreative--Thanks for your great feedback. But you guys are way too kind. Still, I was having a bad day yesterday (got stuck attempting to fix a client's server issue all day) and these posts turned it around for me--ended the weekend on a positive note--thanks for this! I appreciate the enthusiasm and it is contagious--makes me want to work on PW all day.

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.