BitPoet

Nice article. Made me remember the good old days of Perl golf.

Good to see I'm not the only one scratching my head over the current jQuery-is-bad movement. To me, wiring in a full-fledged MVsomething framework only makes sense if the complete data exchange is abstracted away, otherwise backend code and frontend (speak backend UI) logic will get even tighter bundled (or bungled?). This would mean that all backend calls would need to be some kind of RESTful using JSON, XML or something along these lines, and plainly, PW isn't at that point right now and getting there would need quite a bit of work. I'm not a real wiz when it comes to MVC/MVVM frameworks, but I do have some experience building complex RIAs, starting by building everything on top of ExtJS (2 and 3) in the good old days and later rolling my own two-way bindings for nested data structures. I've recently delved a bit into the currently trending frameworks, and I was utterly appalled by the unnecessary complexity, semantic mumbojumbo and lack of essential features each of those exhibited in varying degrees. Don't get me started on the massive breaking changes introduced in major frameworks I see every year. I've got one really complex app that needs a larger overhaul next year (warranted after 8 years, I feel), and I've come to the conclusion that it will be simpler, faster and more concise to build everything without any framework besides a lean CSS library and perhaps jQuery, especially if I want it to run the following 5+ years without finding myself using an orphaned framework. If the PW backend could be completely JSONified, I'd be all for that, but even then, I'd currently prefer a framework-less default interface. Any MV* solution could then be an alternative, just like current admin themes.

Why not use a repeater field with title and body instead of one single CKEditor field? You could then just iterate over the repeater items, render the anchors when outputting the titles and then iterate again in your TOC to render the links.

You need to have at least one image field on the template, then you'll see an "Upload Image" button on the insert image dialog.

I could reproduce the problem with a clean install. It seems that all event listeners on the page list select items get attached twice. I didn't have time to check with different browsers though. I might be able to do some more digging tomorrow when I'm back at work.

It's just a question of proper naming. See this working example: <?php // MyModule.module class MyModule extends WireData implements Module, ConfigurableModule { public static function getModuleInfo() { return array( "title" => "MyModule", "description" => "Adds a button to the module config that executes the foo() method", "version" => "0.0.1", "autoload" => true ); } public function init(){ $this->addHookBefore("ProcessModule::executeEdit", $this, "foo"); } public function foo(HookEvent $event){ if($this->input->post->foobutton) { $this->session->message("foo() executed!"); $this->session->redirect($this->page->httpUrl . "edit?" . $this->input->queryString); } } } <?php // MyModuleConfig.php class MyModuleConfig extends ModuleConfig { public function __construct() { $this->add( [ [ 'name' => 'foobutton', 'type' => 'InputfieldSubmit', 'value' => 'Fire Foo Method', ] ] ); } }

Does this also happen on local installs? I'm asking because your demo site uses cloudflare's rocket loader, which may break some javascript.

It's not impossible, but the approaches may vary a bit depending on what your module exactly does (and is). The most direct approach would probably be to hook before ProcessModule::executeEdit, if $this->input->post->foobutton is set then execute your method and immediately redirect to the current page, optionally showing notifications via $this->session->message(). executeEdit is the method that outputs and processes the form with the module settings. Make sure that your button's name is valid (no blanks) since this needs to be access as a property of $input->post.

Thanks for spotting that, @Robin S. That if somehow got lost in translation.

A quick&dirty piece for site/ready.php. The collapsed status still needs some working on, but it appears to also be working in ajax mode: wire()->addHookAfter("Field::getInputfield", null, "hookGetInputfield_lockCheckedRepeaters"); function hookGetInputfield_lockCheckedRepeaters(HookEvent $event) { $thisPage = wire('page'); // Only run our locking logic if we are editing the page in the backend if($thisPage->process != "ProcessPageEdit") return; // We don't want to lock the repeater itself (or do we?) if($event->object->type instanceOf FieldtypeRepeater) return; $repPage = $event->arguments(0); $context = $event->arguments(1); // The backend retrieves the field within the repeater context, otherwise something else // is happening we do not want any part of ;-) if($context != "_repeater" . $repPage->id) return; // Set collapsed status in the input field (the event's return), could be made a little // more elaborate $event->return->collapsed = ($event->return->collapsed === Inputfield::collapsedNo || $event->return->collapsed === Inputfield::collapsedNoLocked) ? Inputfield::collapsedNoLocked : Inputfield::collapsedYesLocked; }

Or just move the function to site/ready.php or, if that is still too late, site/init.php.

Yes, add fields for all the settings you need (e.g. with @Soma's ColorPicker module). Then add the styles inside style.php like you quoted above. body { background:<?=$page->bgcolor-field ?> url(<?=$page->bgimage-field ?>) no-repeat; } /* ...any other styles, with or without PHP code */ Then, in your regular template file, include the CSS settings page. <link rel="stylesheet" href="<?= $pages->get('/your/css/page/')->url ?>"> Basically, you've now created a separate PHP file for all the CSS so you don't have parts in a regular stylesheet and others in your template file. Once everything works, you can go into the style template's settings and switch on caching. Enter a cache time (like 86400 to regenerate the CSS only once a day) and you have performance close to a flat file stylesheet.

If it's one page meant to be used site-wide, you might consider creating a template file (let's say styles.php) for it that outputs the css (in the Files tab, set content-type to text/css and tick the box to not append the standard file). Then you can link to that page just like you do with every other stylesheet, and you can even use template cache. That way, your regular templates are kept tidy and you don't send unnecessary styles over the wire with each request. To be able to select the text/css content type, you need to add the following to your site/config.php first: $config->contentTypes = array( 'html' => 'text/html', 'txt' => 'text/plain', 'json' => 'application/json', 'xml' => 'application/xml', 'css' => 'text/css' );

When you need the full URL, use ->httpUrl instead of ->url.

Adding to what @abdus said: make sure you haven't got a name resolution issue that slows down database access (it often helps setting 127.0.0.1 instead of localhost for $config->dbHost to work around IPv6 issues). If you still want an additional boost, consider enabling opcode caching (e.g. with PHP's opcache module).

Actually, that's quite similar to the breadcrumb dropdown I built for our new intranet layout, so I totally agree . I don't think there's a good place to hook into, but making AdminThemeUikit::renderBreadcrumb hookable shouldn't be too expensive. It might be worth adding a feature request in the issue tracker.

You can add a RewriteCond that checks %{HTTP_HOST} for a match on mini-project.com.

A database corruption is highly unlikely. I noticed that even the request to your login page returns a 404 status code while still delivering the login form. In fact, any request to a page in a path below / returns a 404 status code, which is wrong. My bet is also a broken rewrite rule. I'm not familiar enough with LiteSpeed to venture a guess at where exactly to look, though.

Just in case you still have a minute, have you tried deleting the FileCompiler cache and clearing your PW cookies in the browser?

This seems to be a different problem as you get a 404 http status code instead of 200. Does the cited line contain the whole path (there should be something in front of "?id=1...")? Does the body of the xhr call contain some more information? Does the web server log show any PHP error messages? Is $config->debug enabled in site/config.php?

Move the output of the continent div tag (and its end tag) outside of the loop over its countries.

You need to either put the call to count() outside of the string or use curly braces. So both of these should work: // outside of string $out .= "<a href='$item->url'>$item->title</a> <span class=''>" . $item->children->count() . "</span>"; // or with curly braces $out .= "<a href='$item->url'>$item->title</a> <span class=''>{$item->children->count()}</span>";

I don't think there's a way to call ukNav and have it include the page count without modifying the function itself. From what I see (I'm not familiar with the UIKit3 profile) the lines where the links are generated are either 135 or 153. So you could clone (probably, since ukNav is rather generic) or modify (with a third optional argument that indicates that page counts should be displayed?) the ukNav function, retrieve $item->children->count() inside the loop and insert that count into the link.

It's likely just the current PHP instance in FastCGI or the Apache child reaching its maximum lifetime. Depending on the web server and how PHP is invoked, a new PHP instance is spun up every so often. The new PHP instance gets loaded, and if error reporting is active, it just coughs this warning into the next output stream. So it has nothing to do with calling soap methods.

My personal opinion is that database layers like dibi tend to make some things a little easier while making corner cases complicated and taking clarity away by re-using existing keywords in a sometimes non-intuitive way. Then, they don't support application features like PW's multi-language fields or status flags, so one has to reign in expectations. And, often overlooked, PW already has a nice extension to the DB layer in the DatabaseQuery* classes. Perhaps that should be put into the spotlight a bit more (and added to the API docs)? A working example: <?php $q = new DatabaseQuerySelect(); $result = $q->select('templates.name') ->select('count(*) as inuse') ->from('pages') ->join('templates on templates.id = pages.templates_id') ->where('templates.name != :tplname') ->groupby('templates.name') ->bindValue(':tplname', 'admin') ->execute(); echo $q->getQuery() . PHP_EOL; foreach($result->fetchAll(\PDO::FETCH_ASSOC) as $row) { echo $row["name"] . " => " . $row["inuse"] . PHP_EOL; }