BitPoet

A feature request here in the forums prompted me to shape a piece of code I had been tinkering with into a usable module. Template Parents What it does: The list of possible templates for new pages in ProcessWire is purely based on other templates in parent/child relationships managed in the involved templates' family settings. This is most often okay, but sometimes you want to limit creation of pages with a certain templates to individual spots in the page tree, and there's no clear parent/child relationship to go with. The initially quick solution would be to duplicate parent templates for the different spots, but then any change on one of these templates has to be made to the others too, which gets tedious and error prone. Template Parents adds an entry in the Setup menu where you can assign allowed parent pages to templates. These rules are enforced after the regular family settings have been executed, so it builds upon instead of replacing PW's built-in mechanism. There's also an option in ProcessTemplateParents' to enable inheritance, then entries in the Template Parents assignment are inherited down the page tree and also grant template permissions to children, grandchildren and so on. The module can be downloaded from the GitHub repository. It has been tested with PW 2.7 and 3.0.

Haven't tested it in 3.x yet, but I'm about to. Update: tested with 3.x and worked like a charm.

You mean something like this?

Have you tried disabling ACF in the field's settings? If disabling ACF makes it work, you'll probably have to add rules for the elements and classes in your custom styles in the Extra Allowed Content field.

DaveP, is user_agent set in your php.ini? Github's api rejects requests that don't have a user-agent header.

Just use httpUrl instead of url.

A hook won't get you far, as frontend editing is done through Ajax calls and any redirect would just redirect the Ajax save request, not reload the whole page. The redirect has to happen in Javascript.

Option b has been done before, so maybe you could try the solution in that thread (on a copy) before going the "hard way".

From a glimpse into PageFrontEdit.js, I don't think there is, but it might be worth a feature request to let inlineSaveClickEvent fire a custom jquery event on completion.

Inexplicable 403 errors in CKEditor's dialogs are 99% of the time caused by apache's mod_security.

Replace the fuel() call with wire('all') or wire('*') should get it working in 3.0, as LostKobrakai pointed out in this thread.

Both "manufacturer=$optiontitle" and "manufacturer.title=$optiontitle" should work, unless you have separate values/titles configured and want to search for the value, then "manufacturer.value=$optionvalue" is the way to go. Both .value and .title support text matching.

@adrianmak, is it just a copy&paste mistake that your code accesses $category while you set outputFormatting to false on $page? @gebeer: Additionally, there are two other methods to get a page field's value in another language (with the first one being my favorite): // 1. Directly from the page: $title_en = $category->getLanguageValue($eng, 'title'); // 2. A bit more circumspect: $titleField = $category->getUnformatted('title'); $title_en = $titleField->getLanguageValue($eng);

It already does that - or, to be more precise, PW's default behavior takes care of that.

While 2500 queries per page load is quite a bit, it isn't completely unheard of for a complex multi-language site (though it cries for a bit of caching). Two connection per view is normal. The SQL_NO_CACHE keyword is only added if $config->dbCache is disabled, which is enabled by default, and this definitely puts a heavy load on the server (data for every query has to fetched anew). So I'd enable dbCache in site/config.php again and test if the problem is still present, then also make sure that $config->debug is disabled for the live site.

foreach($grandparent->find("template=product") as $product) { ... } should do the trick.

Update: I've added a "Media" admin page with a quick create option for new library pages.

I don't think checking it by default would be sensible. Usually, access is managed by template permissions and hidden/published status on the selectable pages. Any widening of access rights should have to be done explicitly.

There's a point though. Perhaps a ISO language code dropdown could be added to the language template together with a checkbox to allow automatic installation of language packs by new modules according to the selected value. This would keep backwards compatiblity yet allow for automatic installation (through module install). Adding a mechanism to query installed modules whether they provide translation packages for newly added languages could be accomplished by hooking Languages::added. The only problem I see are languages that differ quite a bit in ISO 639-1 groups, which, for example, captures all variants of Chinese under the lable zh. Yet ISO 639-3 may be too fine-grained. A two-part solution like Unix and Windows use would IMHO be better (e.g. zh-cn, de-de, with fallback to the first two letters).

The api runs as the logged-in user, or as guest if you're not logged in.

Can you make sure it isn't a permissions issue (e.g. /styles/base/black being hidden)?

#1) For debugging purposes it would be good if you could also show us the rendered line 7. #2) The #-Links are probably added by the slider. Are you using a PW module or a third party library to generate your slider?

Try wire('fields')

Make sure your hero_image field is set to "Single item".

I don't think any changed wording will completely solve the problem of people leaving out vital details, but the line in question could be easily ammended to include the PHP keyword: Easy-to-use, jQuery-style API for PHP