ryan

You have a couple of options here. First would be to make it a "global" field, which should make it appear on the first screen when adding a page. But not all fields support that, like files, images and repeaters for instance. The other option would be to copy /wire/modules/Process/ProcessPageAdd/ into /site/modules/Process/ProcessPageAddCustom/ and rename the file name/class name consistent with the directory name (ProcessPageAddCustom). Modify the module to do exactly what you want. In the admin, edit the page Admin > Pages > Add Page. Change the "process" field to be your custom version. Anything is possible, but this might be too abstract/vague of a request to provide a tangible answer. But it does potentially sound like you want a hook, or a custom Fieldtype or Inputfield to perform some automated actions.

Not sure I understand the question. For the most part, ProcessWire's API works the same no matter where you use it from (whether a template or a module, etc). If you'd like, post a code sample of what's not working?

You might also want to check out the new Foundation site profile, which is a variation on the Basic Site Profile included with ProcessWire, but a good one to look at next to see techniques that can scale.

Looks good to me too! Alessio, do you want me to go ahead and point http://it.processwire.com to it? Or do you want me to setup the account here?

That syntax is valid–I think when I replied before that the morning coffee hadn't quite kicked in yet. But, if you need to access the first element, I think it's better to use first() rather than get(0) just because there's always a possibility that the item at index 0 was removed somewhere else, or that the PageArray was at some point sorted so that index 0 was no longer the first item. If you don't have any other manipulations going on with your PageArray, then accessing get(0) is probably just fine though.

Most likely repeaters aren't what you want. You can create any structure with pages so that opens up your options, even if it makes input less convenient. But for specific needs like this, you can us the API to automate any input challenges. You could also make a spreadsheet that contains your data and use the ImportPagesCSV module to import them (or your own import script). Another option is to create your own SeatingChart Fieldtype an Inputfield. Fieldtypes are designed to represent potentially very complex data, and are the most efficient way to create a reusable complex data type. But creating a Fieldtype does require getting into database schema and more PHP than usual site development.

I actually thought this Foundation 3 to 4 Migration Guide was really helpful in that regard. Even though I never technically knew Foundation 3 very well, it served as a good starting point for Foundation 4 in general.

I always liked Foundation 3, but it just seemed slower (on my computer) than other frameworks. Foundation 4 doesn't seem slow at all anymore. I was initially confused by the syntax with class names like "small-4 columns" and "large-8 columns", etc. But it's actually very simple: if you want a div to have 4 columns at small (mobile) and at large (desktop) then use "small-4 columns" ...Foundation is literally mobile-first, so the "small" settings inherit through to the large settings, unless you override them. But if you want it to only have those 4 columns on at large (desktop), and 1-column stacked on mobile, then use "large-4 columns" ... which would be like the behavior of Foundation 3. If you want to define different column amounts for small and large, like say 2 columns at small (mobile) and 4 columns at large (desktop) then specify both in the class, like "small-2 large-4 columns". I never got far enough in Foundation 3 to say for sure, but I don't think it had that distinction...I think it just stacked everything at small.

I just posted version 2 of this profile, which makes typographic tweaks to several styles. It also adds support for photo captions, seen on the typography tests page. Also, there is now a demo site of this profile. I'm okay with only supporting IE9 and newer for the desktop view. IE8 and lower can have the compatibility mobile view. It's not like IE8 and older are blocked. They just simply get a view that works consistently in older browsers (which is basically the mobile view). I think this is smart, and better than trying to make old browsers display like new browsers. Supporting old versions of IE always means extra bulk and shenanigans in the code. The less legacy-IE monkey business, the better, IMO. But if you are building a complex desktop grid for an audience using old IE versions (like inside a government office that has standardized on IE7 or something) then Foundation is probably not the right framework for that. Here's what this profile looks like in IE8 if you are interested. The rule is that you have to start and end an attribute with the same style quote. Otherwise, they are interchangeable. I prefer to use single quotes myself. But if I'm copying/pasting something, I'm not going to bother going and changing double quotes to single quotes either. But ultimately the biggest reason is what Teppo highlighted: what makes the most sense in the context where they are used.

ProcessWire Site Profile Using Zurb Foundation 4 This is a drop-in replacement for the default ProcessWire site profile. See the live demo at: http://processwire.com/foundation/ It is mobile-first and fully responsive, capturing all the benefits of Zurb Foundation 4. Ready to be expanded upon with built-in support for deeper levels of navigation nesting in the sidebar. Pagination ready with Foundation-specific pagination output, when/if you want it. Improved search engine, relative to the basic profile. Library of Foundation-specific markup generation functions included, primary for generation of navigation (in _nav.php). Uses ProcessWire 2.3+ prepend/append template file settings making it easy to work with. It is largely stock Foundation 4 in terms of look and feel, with a few tweaks. To Install Download this profile from GitHub or mods.pw/4u. Start with a copy of ProcessWire 2.3 or newer, and its default site profile. If starting with an uninstalled copy of ProcessWire Replace the /site-default/templates/ directory with the templates directory from this profile. Replace the /site-default/config.php file with the config.php file from this profile. Run the ProcessWire installer. If starting with an already-installed copy of ProcessWire Replace the /site/templates/ directory with the templates directory from this profile. Add the following two lines to your /site/config.php file: $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; Desktop Screenshot Mobile Screenshot

I think it can be set with CSS, but CKEditor apparently doesn't take the <textarea> rows attribute into account. We may be able to approximate it in the module initialization. I mainly use the inline mode with CKEditor, which always makes the height of the editor the same as the height of the content within it.

Thanks Soma, I've fixed that regex so that it ignores comments on the same line. I'm still seeing a few issues with Nico's module versions since they are using a different format from all the others, but not sure there is anything I can do about that yet.

Alicia, what PHP version are you using locally and on the server? There can be password issues when going between PHP 5.3 and 5.2 since PHP supports stronger password options than 5.2. Does the pass stop working just during migration from server to server, or is it happening randomly?

I would go ahead and create your new translation and post it as a follow-up reply to the existing one. If there's no response from the original authors (like pulling updates into the existing one) then we could just make your new version the current version linked by the directory. We don't usually break the API with new releases, though did have to in the 2.0 to 2.1 release. It may also happen in the 2.4 to 2.5 release when we switch to namespaces. There isn't any end-date to support of past versions. If some security issue turns up, It'll go into all current versions that we offer as downloads. For past versions that don't have active development branches, we would provide a file replacement or patch. To date, there have not been any security issues, so it's never been up to test. But it's always good to have a plan. We are very shy about changes that break things, so would version the API if behavior of some core functions changed from version to version. This is one reason why I think PW is a good/safe long term solution. The problem that I've run into with WordPress and Drupal is that I can't leave old versions of them running because the site is only as secure as it is up-to-date. Old version of WordPress/Drupal = insecure (not to mention the plugins). An installation of one of these products becomes a permanent relationship with the client as you have to continually keep it up-to-date, in the same way you have to keep filling up your car with gas or it stops running. This is not the case with ProcessWire. I still have 7+ year old versions of ProcessWire (aka Dictator CMS and PW1) running sites perfectly fine. I could upgrade them, but there isn't really any need to unless the client needs some new feature present in a newer version of ProcessWire. Being able to install a software and trust that it's going to keep running on it's own for a decade or more, without my intervention, is worth a lot.

I've not seen syntax like $page->ref->get(0) before. Are you sure you don't mean $page->ref->eq(0) or $page->ref[0] ?

Since this is a recursive function, you might want to pass your $level as a second argument so that you aren't relying upon external factors for the recursion. That way you control the value of it in your own function. Also note that it is possible for $page->parent to be a NullPage, which would have no parents. You might be better off checking the $parent->id to make sure that it is 1 or higher. ID 1 is always the homepage. ID 0 is typically a NullPage (or a new page that's not yet been saved, but that wouldn't be applicable here I don't think).

Does each row have a different cost, or is each row completely independent in terms of cost? If there is some redundant data here, it might make sense to associate rows to cost-categories separately. I'm also not sure that a repeater is ideal here, because doesn't that prevent you from re-using the same seat chart for other shows? I like repeaters for some specific things, but never for anything that can be re-used as references among other pages.

I dont think either 'autojoin' or 'init.php' would be applicable to the question, so not sure I understand the mention. All that you need to do is add your keywords and description fields to the page templates where you want them... perhaps that means all of them. Then when you output your page: <meta name='description' content='<?=$page->meta_desc?>' /> Make sure you have the "HTML entities" encoder as the textformatter for your meta_description field. Also I would not bother with keywords if the intention is to use them as meta keywords, that's a waste of effort. I usually keep my "site" description on the homepage. Though I think it's better to have a blank meta description than a duplicate one. But if you wanted to pull a site description when the page description was blank, you could do this: <meta name='description' content='<?php echo $page->meta_desc ? $page->meta_desc : $pages->get('/')->meta_desc; ?>' /> The logic is: if this page has a meta_description use it, otherwise pull the meta description from the homepage. The "default" is whatever you want it to be. Meaning, the only place you have to change it is in your mind. You may be interested in the new LanguageSupportPageNames module on the PW dev branch. Be sure to follow the thread in the multi-language board if interested. There is no $user->language if Language Support is not installed.

All date/time formats are configurable. Where are you seeing 13:30 pm? I can tell you where to change it. Looks cool–I like it!

I'm not sure if we're talking about Page fields that are set to store just a single value (via their field settings) or Page fields that simply contain one value (and are able to contain more). But you mentioned the problem was with multi-value selects like select[multiple] and checkboxes, so I'll assume we're talking about multi-page storage. Meaning, the "dereference in API" setting is PageArray, not not Page. If this is the case, it should not matter whether there is no value, one value, or multiple values, as they should all be treated the same. So if you are seeing different behavior in 1 vs multiple, then the first place I would look is in your field settings to see what they are set to be on the API side (single vs. multiple).

Looking good Kongondo! I look forward to reading your tutorials.

Just pushed a fix for this on the dev branch. Please let me know if you still run into any odd behavior with the page numbers off root.

I'll change that "leave the existing contents as-is, but feel free to add to it."

As far as I know, the two cannot coexist. But not positive on that, TinyMCE is always full of surprises.

This is now fixed in the latest dev branch. Thanks for the nice module!