ryan

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!

Thanks, I think I've got this fixed. Try out the latest dev commit. Your best bet is to use no language segment for your default language. So when you edit your homepage, on the "settings" tab, make sure the default language field is blank rather than "en".

I'm really liking CKEditor in usage, but admittedly don't know how to do a lot when it comes to extending it yet. But if you guys figure out how to do this, let me know what config options I can add to the module and I'll be glad to.

I like what you are saying about the dependent validations, and something that validates a whole page sounds interesting. Though since fieldtypes and inputfields are of types that may be completely unknown to the page (since they are plugins), and independent from one another, the core has to keep the validation connected with the fields. But as an external validation option I think it sounds interesting.

This is something I'm adding.

Makes sense to me. The only thing is that PW core doesn't come with an Inputfield that does this, so it would be an external 3rd party dependency... something I'd like to avoid. So what I'll probably do is make the Inputfield type configurable so that you could tell it to use some future code-editing Inputfield instead of InputfieldTextarea.

The modules directory has been updated so that it talks a lot more with GitHub behind-the-scenes. This provides the following new features for modules that are hosted at GitHub (which is the majority): It keeps your module version up-to-date automatically. You no longer need to go in and edit your module listing to bump the version number. It performs this check on every GitHub repo linked by the directory, once per day. So once you update the version number in your module's PHP file (getModuleInfo), and have it committed to GitHub, that's all you have to do, as the directory will detect the change in a few hours. When you add a new module, it is able to pull in most of your module's information automatically from GitHub after you specify the project URL. As a result, the add new module link asks for your project URL before anything else. The directory now displays the contents of your README file at GitHub, and keeps it up-to-date automatically (checking it once per day). Because of this, you may no longer find it necessary to use the directory's built-in Extended Description or Instructions fields. I recommend that you have your README in either Markdown (README.md) or Textile (README.textile) format, which just looks better, but plain text is of course supported too. Hopefully this makes it a whole lot easier to keep your modules up-to-date in the directory. Please let me know if you run into any issues with it. Please note: Your module must have the same name as the repository. Meaning, if your repo is named MarkupTwitterFeed then your module must be named MarkupTwitterFeed.module. This appears to already be the case with all the modules in the directory, so I'm not sure this even needs to be called out, but figured it was worth mentioning just to be sure.