Leaderboard

I wasn't talking about the frontend lazy loading, but the fact that in processwire fields are lazy-loaded from the db by default. So you load a page (+ autoloaded fields; 1 query) then you access the first field in the page (1 query), then you access another field of the page (1 query) and so on. That's why autoloading fields can be so useful, as it can quite quickly drop the query count and therefore improve performance. Using fieldtype matrix makes it sounds like it's still just one page, but with 30 blocks it's more in line of loading 31 pages, the parent page and all the blocks are also pages. Now if each page lazy loads their fields you're basically in a n+1 query situation.

Those are some sweet updates Ryan! Seeing as you've been working on transferring the blog posts over to the new processwire.com site, do you think you could add a feature so that blog posts automatically get anchors on every <h3>? There could be an automatic table of contents from those anchors if you think that would be good, but having anchors is the main thing. Because there is so much useful documentation of features within the blog I often want to save references to specific sections within a blog post, or provide a link to a section in a forum reply. Having heading anchors would make it possible to do this.

Because that is how browsers render the del tag. Most (all?) display the contents within del tags like this and the contents of insert tags underlined. IMHO, using the del tag for that typewriter animation script is a poor choice since DEL is a very semantic element. You could work around this by following @horst's suggestions or switch to a different typewriter script that lets you specify your target element dynamically (through a class or id).

Did you check your site for the query count. ProcessWire generally uses quite a lot of queries and given you seem to have quite a lot of nested stuff + probably some loops over the content types it might just be that the lazy loading of fields results in your code constantly talking to the database. Adding some auto-joins here and there might already make things faster.

Those sound exactly like the migrations / helper functions my Migrations module does provide ?

Nice, "pw-optional". Right now I'm finally back in ProcessWire re-building some websites and Markup Regions is a breeze to work with.

Yes! And a prev/next link on each post ? Great updates! Love them ?

Hi all - I've just committed a pretty major update to the Console and File Editor panels. 1) Adds all ACE editor themes with a config setting to choose the theme 2) Options to set the font size and line height 3) I have refactored the sizing of various divs in both these panels that should solve lots of minor layout bugs especially when resizing the panels. *Be sure to do a hard reload to get the latest CSS/JS files. 4) Updated the core SplitJS library which now adds support for dragging by fixed increments which lock to the code line height - before I was hacking this on and it wasn't anywhere near as nice. 5) Various bug fixes for the keyboard shortcuts for resizing the console panes. Also, just a quick note to say that this version doesn't yet include the PW variables code completion. That will come in the next version. I am on a semi-vacation at the moment so haven't had any dedicated blocks of time to get that quite as I want yet. Please let me know how this new version goes for you!

Thanks Macrura. I just tested and it looks like you can do this: // in site-settings.php // note the toolbar line and inlineMode line [ 'name' => 'ckeditor_test', 'label' => 'CK Editor Test', 'type' => 'InputfieldCKEditor', 'width' => '100', 'description' => 'Some Formatted Test', 'collapsed' => 0, 'value' => '', 'toolbar' => "Bold, Italic", 'inlineMode' => 1, ], Doing that will only show the Bold and Italic buttons in the CKeditor toolbar. It will also use inline mode. I'm not sure about the other stuff yet. I found those settings in wire/modules/Inputfield/InputfieldCKEditor/InputfieldCKEditor.module Hope that helps someone.

I'd say develop locally (use local database). To me, having a permanent ~70x2=140ms round-trip delay at every operation would be a frustrating experience. Using custom git hooks you can export & import sql databases from local <-> remote setups. Once the template & field infrastructure is complete you can utilize page import export feature to exchange pages between local & remote as well.

Table Tools plugin is another possibility, but you have to purchase it. Another point to mention is that it could be confusing for customers. My experience is that the more possibilities you offer the more problems customers will have. I always tend to make it as simple as possible (ASAP). Dont offer to much settings or possibilities - every additional setting is often a challenge for them. But for better experienced users it will be a very useful plugin to create really complex tables in a quick way. So you have to decide depending on the pros and cons.