Macrura

i think using this sort of structure is going to be inevitable on a lot of projects, especially where you don't need/want the users to even interact with the page tree - for example a shop or product catalog; in those situations, you may use a bucket approach, putting all of the products into a 'folder' and then when the user creates a new product they need to set it up from the editing screen - meaning they may need to specify a product type, family, category, or even a combination of those things. Product categories may be just options that need to render lists of items in those categories. In Ryan's CMS critic case study, he demonstrated a hook to rewrite the path of any page based on it's template. I use that method, but depending on how complex the setup is, it may have a series of cascading implications that need to be accounted for system-wide, such as page title, section, breadcrumbs, and the actual page that is supposed to be rendered. I setup a WireData container ($config->segmentData) where i can set those items so that the system can work with whatever virtual page needs to get rendered based on the request. So in the end i was able to get a complete URL routing system by 1) adding the page paths in a hook in ready.php for the relevant templates 2) adding a custom WireData() ($this->wire("config")->segmentData = new WireData();) in ready.php 3) setting up some blank vars in that $config->segmentData in the template init, like $config->segmentData->page = ''; 4) setting up a router template which handles the segment requests, and setting a page in the tree to use that template. 5) i also use a getVirtualPage function that simplifies the code in the router there are a couple of other concerns depending on how you render the content, but nothing that difficult...

@gRegor - not sure if you already tried the Admin Help module, which is basically a documentation system that runs inside PW admin; one of the sub-modules is a process module that displays all of the documentation in an accordion page view...

wow super awesome, i will get this into the new version asap

yes, you can create the shopify_embed field for example, a textarea (can use plain or ACE Extended). Then for each product you have you just need to grab the code and paste in that field. then you can just echo the embed code... <?php echo $product->shopify_embed; ?>

actually looks like this is related to Codemirror refresh, so the fix is all about being able to call the refresh() method on the codemirror instance based on a js event, such as the wiretab click, or the inputfield collapsed. Other option which is out there is to have an interval refresh running on the page, which is an addon for codemirror which helps in situations where you have a lot of instances where the codemirror does not init; @ethfun your fix doesn't work actually because then any non-visible fields on the content tab (like if they are collapsed) don't get initialized till you click a tab... to be continued

yep - ok thanks for checking that - will have this all in the module asap. @tpr thanks for the advice, yes, will add the the data attribute so it doesn't keep initing

@ethfun - cool yeah I tried to work on that yesterday, but didn't get far. Though I did move the init function into a variable so it can be called from any event now; also the new version updated the core css and js;

are you sure the value is blank? Mine works on the closed field, you just can't see the content until you click into the field; The field is still initialized when you open it; not sure if the fact that you can't see the content in the field is due to some initialization issue, or is something specific to how this component works. I'm not sure this can be fixed, so for now i think your options are to either tell the editors to click into the field to see the content, or don't use collapsed fields. In some future iteration of this module, the eventual aim is to have it operate more like CK editor, so that the config takes place from the admin, and each instance can be individually configured; also support for some sort of image input. But i think it will take a while till it reaches that stage, and also would depend on demand...

thanks @ethfun for the report, i will update the core SimpleMDE stuff to latest. In terms of the init for closed and tabs, i will check it out and post back here.

it depends - a lot of times if you are talking about a logo, that is a really specific image that might be precisely sized and optimized for display, may have light/dark versions, smaller icon version for mobile, maybe a version with a tagline, as well as possibly retina versions; it could be something you don't want the client to have access to change. On the other hand if you did want the client to have access to it and be able to change it, you might need a multi-image field with tags, so that you could upload all of the versions of the logo and tag them (light, dark, retina, icon or whatever). This is why i would recommend using the system's native image fields for images...

i would think that a general site settings module should just store settings, and not any files or images - if you need those just add a custom field to your settings template (?) alternately ftp upload the image to a specific folder and then reference that file's path in the setting...

I don't think ckeditor natively supports definition lists, and they would be hard to implement because of the structure. If I needed to support definition list for PW, these would be the options i would consider: 1) have somewhere on the editor where users can define the definition lists, for example a repeater with a text area and a field for the reference name of the list. Then they would title their list and in the textarea would add term/description pairs with some delimiter like a pipe. then in the editor they would put in a token to represent the definition list, like {{definition-list-1}}. Then on output of the body field you would need to setup search/replace array for each defined list in the repeater and then do your string replacement of the body field. 2) Similar to above but using ProFields table within your repeater, allowing you to have separate inputs for the term and description. 3) If you were doing complex definition lists with multiple terms or descriptions for each list item, you might be able to use the structured data or yaml modules for more complex structures...

right, i will probably switch to that way, since it's definitely more efficient.

COMPOSER ELLIOTT CARTER (December 11, 1908 - November 5, 2012) is internationally recognized as one of the most influential American voices in classical music, and a leading figure of modernism in the 20th and 21st centuries. https://www.elliottcarter.com/ This site was launched some months ago, and was one of the larger projects I completed so far. It took about 4 month to build. (PW 2.7.3) This was the first project I used the wireRenderFile() pattern on, and it consequently allowed me to reuse a lot of output code, as well as do a lot of markup/object caching with wirecache. The site uses DataTables for all of the major listing pages, Works, Discography and Events, allowing users to filter and search with no page reload. This probably has the most advanced caching setup that I've done so far, and one example of how it works is on the discography page: https://www.elliottcarter.com/discography/ That page has to hold all 264 albums (json object which is rendered by dataTables), and each album takes a bit of processing to render (formatting of works, artists etc.). The json for each album's list view is wirecached individually and is generated on visits to the individual album pages, so that they never get generated all at once when visiting the discography page. The complete json object containing all of the albums is also wirecached, then the final page is pro-cached. The album covers are lazy loaded so as to not affect page size or load speed. The selects on the left are also all wirecached as page or regular arrays. This results in a 1.6s page load time and a page size of 1.12 MB. Without the data being wirecached the load time is around 9 seconds to generate the page, probably longer if it had to regenerate all 264 albums, but the album info never changes, so they are permanently cached unless someone edits one. Also should note that since there is so much use of wirecache, @Soma's Clear Cache Admin was pretty much indispensable for managing all of the caches. Other features of the site include extensive use of Schema.org microdata, an events submission system, and a lot of custom stuff in the admin for managing the content, such as automated fetching of album covers from Amazon, converting formbuilder submissions into events, a custom admin dashboard etc.. There are probably 60 modules in use overall, but these in particular saved the day: MenuBuilder AdminCustomFiles AdminPageFieldEditLinks All the Selectize modules URL checker PrevNextTabs WireMailMailgun SetupPageName Changelog AdminCustomPages Twitter Feed Social Share Buttons RSS Enhanced Chosen Select Runtime Markup Batch Child Editor Tracy Debugger As well as all of the pro modules (ProFields, FormBuilder, ListerPro, and ProCache). More info, screen shots etc will be gradually posted here...

@DL7 no i think you may be confused about the standard cropping built into the core. this module allows you to define various crops and you have to call those by name in the api output code. It does not replace or affect the original image at all.

great, many thanks!

i had that problem also, and could never figure out how to fix it or what was causing it; from what i remember it was only happening in FF did you try chrome?

thanks for correcting me; i was going by what I've seen on the majority of sites, as well as the HTML5 boilerplate, so i was blindly following the crowd, and i think google changed their instructions at some point also.

usually you put google analytics in the footer since it is a script tag

@jacmaes any advice on placement of the rules, i tried before/after the PW directives but couldn't get the eval test to return 403 (pw returned 404)

i usually do this in the head - you will need to echo these directly on the php output, because your .js files won't be processed server-side. <script> var site = { "urls": { "templates": <?=$config->urls->templates?>, "root": <?=$config->urls->root?> } }</script> then you can do site.urls.templates for your var inside your main.js

thanks - i'll re-enable the AOS on Wednesday (and test/report) when I'm with the client so they can know how to manage it/disable in case of something else. thanks again for the fix.

I figured out what it was, it was an embedded Constant Contact sign up form that had the words: Please enter your email address in name@email.com format this is actually inside a <script> tag. In any case your suggestion about the execution method would be really great, because when you know you only need the script to operate on 1 page, and leave the rest of the site untouched, it's really the safest way on a large project where you don't want things to break...

i can look into it later this week - thanks!

Hi Sorry for not being clear, and the image may not be obvious - the browser whites out, there is no way to click anywhere, in other words any modal was freezing the interface.