ryan

The LanguageSupportPageNames on dev core (2.3.5) is much farther along (and more stable) than the one on stable core (2.3.0). If you want multi-language support, you would benefit a lot from using dev. There are still bugs being worked out here, but most of them are ones that only affect Soma and his advanced usages but they are all issues that will be fixed before dev becomes the stable 2.4.

Thanks Diogo! That did the trick. I've posted the latest update to the admin theme on dev and this includes the bundled Arimo fonts. I'm curious if this makes it look better for you guys on Windows? This update also includes several other tweaks and minor fixes.

Adam, the LanguageSupport modules can't be pulled from dev and put into another version. There are many upgrades to the dev core in order to support the features of LanguageSupport. The LanguageSupport modules wouldn't work if you tried to take them from the dev version and use them in an older version of PW. If you want the features provided by the latest LanguageSupport modules, the best route is just to use dev. If you find it to be stable for your site's needs, then you should feel comfortable that it'll be as stable as the actual 'stable' branch. Just test thoroughly. The main thing you have to pay more attention with on dev is when upgrading from stable to dev or from dev to dev–you just want to test a little more than if you were upgrading from stable to stable. But once you have it up and running, you can generally expect the stability to be the same as the stable branch.

Thanks, I have fixed that in the latest commit to dev. Not a bug per se, as the template context settings don't currently accompany the clone. But maybe they should. Thanks, this one is also fixed in today's commits (though not sure that one is yet up on GitHub, but it will be shortly). Most likely because PW doesn't validate the selections when PHP code is used to find selectable pages. It does validate them when using a regular selector string, and this validation was implemented recently on the dev branch. The "has_parent" is a database-specific selector option, while our validation is done in memory (not by the database) so this is most likely why it's failing there. I think the solution is for me to add "has_parent" as one supported by our in-memory selectors. This should be as simple as just adding has_parent as a property recognized by the Page class (which would return the result of $page->parents). If you have a moment, can you try out the attached /wire/core/Page.php replacement to see if that fixes it? Page.php

Rather than querying by page titles (or some other thing), why not just query by page name? That is probably going to be a more reliable indicator of whether a title is actually taken. And since the goal is to have unique page names, you might as well start with that in the first place. $name = $sanitizer->pageName($title, true); $test = $pages->get("/path/to/parent/$name/"); if($test->id) { // page name/title is already taken, make user choose another } else { // page name/title is unique, so good to go... $newPage = new Page(); $newPage->template = 'something'; $newPage->parent = '/path/to/parent/'; $newPage->title = $title; $newPage->name = $name; $newPage->save(); }

I don't think there is technically any need to have global variables, and you are better off avoiding them. But on the rare occasions where it seemed worthwhile, I'd usually use the $GLOBALS PHP superglobal anytime I referred to it, just to be really clear about what it was. i.e. $GLOBALS['cd'] = 'this is a test'; function roo() { print $GLOBALS['cd']; } That makes use of any global variables stick out like a sore thumb, reducing the potential confusion that comes from using global variables. Btw, the reason why just defining $cd outside the function doesn't make it a global is because ProcessWire templates are actually running from the namespace of a function in the TemplateFile class, not from the global namespace.

You'd need to use URL segments. See the CMS Critic case study (section on template file structure) for an example of doing this.

I haven't been able to duplicate this one yet. You might want to see if updating your dev branch version helps at all? We're in a bit of a transition with the admin theme, so you might also see if using the new admin theme (copying /site-default/templates-admin/ to your /site/templates-admin/) makes any difference?

Thanks guys, I have updated the module to 1.0.4 with these fixes in place.

Pete already said it well, but I'll put it another way too. URL segments don't have anything to do with queries or filtering or anything like that (unless you choose to make it do that with your own code). They are just something your code can look for to do something, like Pete's example above. It's no different than checking the value in a GET or POST variable for instance. The benefit of using URL segments over GET vars is that the URLs look prettier (and probably more search friendly), and they are cacheable.

"today" is something you could use within a ProcessWire selector, like below (so long as you are querying a datetime field): $garagesales = $pages->find("town_select=$town, Date>today, sort=-Date"); …but it's not a PHP language construct, so you couldn't do this: if($c->Date>today) { Like maba mentioned, you'd want to use the time() function instead, which returns the current unix timestamp. You'd also want to retrieve the "unformatted" version of "Date", as you may have it configured to output a date string rather than a unix timestamp. And you'd nee the unix timestamp (which is an integer) in order to properly compare it with time(): if($c->getUnformatted('Date') > time()) {

The double click thing was annoying me too. I removed it on dev.

Thanks for the PR on this. I will go ahead and implement it. Glad to see you moved the hook to a separate function, as __toString() is a native PHP thing that we can't change the name of. But this is also a high-volume function, so one that I might need to add a little extra bits to keep things running fast.

I plan to collapse them to a "=" icon (pretend it has 3 horizontal bars rather than 2). But I'm also not sure how important it really is, as the navigation remains fully functional either way. I think it'll be fine to let the content tabs (WireTabs) wrap this way at least. I thought they looked pretty good the way they were, but if you guys think they look better on top, I'll switch it. It should be translatable from /site/templates-admin/default.php, at least it does appear in our translation list in that file. I'll test it out to be sure though. Thanks, I'll try this one out. I was able to test on Windows Chrome this week, and can now see the font-rendering issue. Though from my perspective, all fonts looked pretty poor, including Arial. Maybe I'm just used to the antialiasing in OS X, but wondering if Chrome/Windows just has issues here in general. Not sure how far we should go with it if even the native fonts look bad. Fontsquirrel says that the font's license doesn't allow them to create a webfont version of it, so it has to be done manually. If they can't distribute the webfont version, i'm assuming we can't either. When we put something in ProcessWire, we're distributing it. However, I'd love to be wrong about this, as I'm really enjoying the look of Arimo (on the mac at least).

We could do that, but I'm not sure it would matter in this case. The time you spend waiting is not for animation. It is the time spent generating and processing the ajax request (multiple requests, if drilling down multiple levels). I'll test it out to be certain though.

$form = $forms->get("reconocimientos"); echo $form->render(); $form->get("reconocimientos")->addHookAfter("processInput", null, 'hookEmail'); A couple things to mention about the above code (quoted from above). You are adding a hook after the render(). You would need to add the hook before the render. That's because processInput is triggered from render(). Secondly is that you are hooking the wrong thing, as I don't think there is a 'processInput' method on $form (since it's not an InputfieldForm). What you'd want to do instead would be this (in your form-builder.inc file): wire()->addHookAfter('FormBuilderProcessor::processInput', null, 'hookProcessInput'); function hookProcessInput(HookEvent $e) { $processor = $e->object; if($processor->formName != 'reconocimientos') return; $inputfields = $processor->getInputfieldsForm(); // your code here. }

I'm not able to duplicate this one. Anyone else seeing it? I've tried on both PW 2.3.0 stable and 2.3.5 dev, with both TinyMCE and CKEditor. "No Alignment" is not intended to be a CSS class. It sounds like somehow the option label is ending up as the CSS class in your case rather than the option value.

Diogo, would the Pages::added hook be what you are looking for?

Being able to link to hidden pages is important. Often times we make pages hidden specifically because we'd rather make our own contextual links in text rather than have them in the site's navigation. As for unpublished pages, there are situations where we may be working on a group of pages that get published together, so not sure it's good to prevent linking. I think the best thing to do here is inform the client what it means when a page has a strikethrough. If it's a strong need there, I can show you how to accomplish it now with a hook. I don't know if it's a bug in CKEditor or not, but I couldn't find another way around it. DIVs aren't acceptable replacements for <p> tags, so that's why I put in that fix. Hackish I know, but solved the issue here. I'm always on the hunt for a better solution though.

Thanks for testing it out. 2.3.5 is the current dev branch version (soon to be 2.3.6)

I'm guessing it doesn't have anything to do with the spiders, other than that they tend to make a lot of requests in a short period of time. It sounds like your web host is limiting the number of DB connections to a number that's not appropriate for your site. It may be helpful for you to enable template caching (or better yet ProCache) to reduce the amount of time spent on each request. Or ask them to increase the resources available to your site (which may be futile if it's a large/budget host).

I'm not positive on this one and not at a place where I can check it just yet, but LanguageSupport does repeat several function calls for each language, and this may be one of them. Though not immediately sure why it would be (I would think it would be FieldtypeTextarea's wakupValue that gets called 3 times, not FieldtypeTextareaLanguage). It's also possibly the result of something to do with a repeater? If you add another language, is it then called 4 times?

I'm confused because you can't change the default language per-se. You can change what you consider to be the default language, but it still has to have the name "default". In fact, ProcessWire doesn't (or isn't supposed to) let you change the name of the default language at all.

Sorry, I should have clarified that the text-shadow should be added to the body tag... body { text-shadow: 0 0 1px transparent; /* google font pixelation fix */ }

For you guys where Arimo is looking bad, can you try adding this to your /site/templates-admin/styles/main-[colors].css file and see if this fixes it? I found this in HTML Kickstart's stylesheet, so was thinking maybe Joshua already figured this one out for us: text-shadow: 0 0 1px transparent; /* google font pixelation fix */ Horst–thanks, I'll check out Muli too.