BitPoet

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

Yes, there's obviously a danger to add too many files to a library and make things convoluted. There's a point where simple dropdowns aren't practical anymore, but then, structuring information always is an ongoing task. That's a reason why one of the next points on my todo-list at work is a small module to show file usage (i.e. which pages' html fields link to a given pagefile), though that's probably going to be less pratical as I'll use a custom link and image url extractor in our OpenSearchServer to get quick results and avoid parsing multiple fields in a few thousand pages in the database for every file. I haven't read that book, but getting acquainted with tool sets and release procedures before forming bad habits sounds like a good plan, even if not everything (like e.g. composer use) can be used for every project. It's often harder to un-learn a bad habit than learn it the right way first.

I don't want to dig too deeply into circumventing PW's default behavior, so doing things in steps is the way to go for me. This way, I can use PW's default behavior in a lot of places. As for lots of images, it's the same as if they were added to the page itself, so with enough images the pwimage dialog will get sluggish (when depends on the client machine). While it doesn't scale infinitely, it should work in most common scenarios. The file links scale better performance wise, as only one is previewed at a time, though there's definitely a limit too when editing the library pages themselves. It can be a sub page of any ancestor, so a child of a "grandparent" or higher up works too. I'll probably not add much functionality besides what is already there in the short run. I see where you're heading, but that would be counter-productive to what I'm trying to accomplish (at least, where I'm planning to use it). I'll keep the idea in mind, and I won't rule out implementing it if a short, clean solution jumps my mind, but I've got too many other things already on the backburner. If you or somebody else uses my code to as a building block for something like this, you're welcome though.