kongondo

Quick by the ways first.. Are you sure you don't want to limit? If you are, then no need to add 'limit=0' in your selector. The easier path would be to copy renderNav(), modify that to your liking and save it as a function somewhere in your site (if you will be reusing it throughout), or in you blog-categories template file. You would then call it (if function is called renderNavCustom) as: $category_list = renderNavCustom('', $urls, '', false); $content = $category_list; Your $urls is a already a PageArray so you should be able to loop through that to grab each category Page's blog_category_image. Hope this helps.

Yes, you are right. Regarding security, I was responding to the issue about root paths in general, but now I realise what you were really after is having the field's folder as a default. Anyway, this is resolved with having the third option I mentioned. Yes, the error messages are for the dev. Maybe I misunderstand; did you have a suggestion regarding error messages? You already have this option . OK, two options, one each for JS and CSS. So, rather than having one option "JavaScript and CSS included automatically", we have split that into two for JS and CSS respectively. The second options under JS and CSS "JavaScript/CSS file has identical name to this field". That will do what you are after, but with the errors of course, if there is no file present. I think that's a good reminder about missing files. Maybe we can add an option to suppress errors about missing files (..a leave me alone I know what am doing option .). That and the identical file name options should get you your wish (of coming back later to add JS/CSS). What do you think? On the contrary! I value your honest and helpful feedback! . Exactly .

Added security...similar to wireRenderFile(). Yes you can specify a filename . FieldtypeRuntimeMarkup/fields/my-file. OK. I'll add that as a third option (or as the first option). Sure. But some people may prefer to create include folders in /site/templates/ and /site/modules/ that are shared across the site. Adding a third option above should cater for both worlds. We can't assume everyone will want to include a JS/CSS file . I don't like automating things TBH. I prefer for users to expressly declare a choice. OK. Imagine you are working on a runtime field and want to do some 'minor' JS changes. You are in your IDE and you would just have to create a new js file with the name of your field. But then you have to leave or you forgot to fully test your changes with other Inputfields present on the page and you lock up the whole page edit (yes, that's what JS will do...) . Or...you or a colleague renamed your field and forgot to rename your files... Please see above point. IMO, this is a minor inconvenience compared to the damage automation could cause. OK, maybe I exaggerate but I am not convinced automation is the best approach in this particular case. The field settings are just a click away. Yes, I could include an option to suppress errors but that's no good either. Errors need to be seen so that they can be rectified.

Hi @onjegolders, Thanks for your purchase. Apologies about the issues you are having with the module. Probably. Please try and re-install. Check for any missing files using the Network Tab. The error you see in the console is a pesky one that I've never been able to decipher/get to the root of. For now, we live with it; it doesn't affect anything. Please check your email. Thanks.

Hi, as you've noted in your other post, it is a Comments module issue. However, we can work something out, sort of. As you can see here, Comments module allows for preset values (not exactly HTML placeholders) for cite, email, website and text inputs. We can use those. In the next update, I'll make it possible to pass those as part of $options (third argument) to renderComments().

Update: Runtime Markup Version 0.0.3. Changelog Added support to render PHP, JavaScript and CSS files Thanks to @bernhard for the ideas. Please note: Please read the notes that accompany the field settings. For PHP, you can choose to render files (recommended) vs paste code. JavaScript and CSS work with either PHP rendering method (above). These are optional to use. For each of the 3 file types above, if you only have one file and this is named identical to your field, you can select an option to have those rendered/added. For example, if you have a RuntimeMarkup field called 'my_field', you can have a 'my_field.php', 'my_field.js' and 'my_field.css' automatically rendered/added. However, if you want to render multiple files and/or these are named differently, select the option that indicates the files have different names. In that case, enter comma-separated file names. For example, for CSS: my_css, styles/my-other-css-file. Using this option, you can include external JavaScript libraries for use on your page if you fancied it. The above can be mixed and matched, e.g. PHP file could have name identical to field but JavaScript are multiple files with different names and CSS multiple file names, one of which could share a name with your field. All files must descend from either of the root paths /site/templates/ or /site/modules/. It is OK for files to be in sub-folders, as long as those descend from one of these root paths. There is a setting to indicate root path. Only one root path can be used at a time, i.e. it applies to all file types. .php, .js and .css extensions are assumed and do not need to be specified with the file names. PHP files such as .inc will need to be input as such, e.g. my_code.inc,includes/my-more-code.tpl. Errors will be shown if files not found. In your rendered PHP file, you have access to $page and $pages. This means you do not need to get the page being edited first to use it as the current page. For frontend, only pasted PHP code option is supported. My take is that this module is primarily used for the backend. Use of the render files option is geared for creating complex and/or more flexible backend apps as opposed to frontend usage. I have no intention of changing this behaviour. Currently available on dev branch only. Please test and let me know (with Listers, etc as well, thanks). Screenshots Backend Settings Backend Output

Media Manager version 011 (released 20/07/2017) Happy to announce the latest release of Media Manager. Changelog Fixed bug that caused required Media Manager fields to still be labelled as 'missing required value' even when they were populated.

Interesting solution. On my local/dev setup I use Symlinks as I need to easily test my modules in different PW installs.

Queries locking code be about not setting a 'reasonable' limit to number of pages to return. It could also be about too many joins. Hard to say without know exactly what's going on. These threads should be useful:

Hi @bernhard. Sorry been caught up in other stuff. I will implement your suggestion, albeit slightly differently. Thanks for the docs suggestions as well.

Update: Menu Builder Version 0.1.9. Changelog Added support for multi-lingual menu items (both PW pages and custom ones)! Thanks @Michael van Laar for 'reminder'. Note Multilingual feature only applies to multi-lingual sites. You have to choose the languages you want for your menu items (in menu settings). Multi-lingual feature only applies to menu items. This means menu titles themselves remain as normal. The feature only applies to menu item title and URL If other language's item title or URL are left empty, in the frontend, these fallback to default language's title or URL respectively. This means, for other languages, you can have, for example, a German menu title but leave the German URL blank. In that case, assuming the default language is English, the German menu item will get the English URL. Currently available in dev branch only. Please test and let me know, thanks. Screenshots Backend Frontend

Dynamic Selects version 005 (released (16/07/2017)) Glad to announce that the latest release of Dynamic Selects is now available for Download/Purchase. Changelog Dynamic Selects is now fully multi-lingual! Thanks @eelkenet for reminder . Relevant fields and labels now shown in user's language if available, with fallback on default if not. Screenshots Backend Dynamic Selects Fields Demo Backend Dynamic Selects Page Edit Frontend Dynamic Selects

Maybe a namespace issue?

How are you including it? What's your code? Where is the location? For a file in the same location as the module, the following should suffice: $dir = dirname(__FILE__); require_once("$dir/FileToInclude.php"); #require_once("$dir/someFolderName/FileToInclude.php");// if in a folder This way, __FILE__ will deal with paths rather than you.

Hmm. What version of PW? It shows for me in 2.7 and 3.0.62.

Another trick as mentioned by @Robin S somewhere I now can't find...Hover your mouse over the field's collapse/uncollapse arrow...the name of the input usually matches the API...

Hi @eelkenet. Thanks for the purchase. Yes I am. This will be added in the next version. I'm working on it for the next couple of weeks. Thanks

Welcome @Mirza, If you are talking about the backend, only supersusers have access to setup/template/. No other users can edit templates, fields, modules or admin pages.

I think it should be easy enough to just create a new menu item, no? I see no easy way of automating this so will have to let the idea go.

Hi @Sahil, Sorry I never resolved this. It's difficult to give an answer without getting more information about your pages tree structure.

Sorry for late reply @CodeCoffeeCode, In addition to the suggestion to use the custom menu render strategy as suggested by @elabx, I think the options: include_children and current_class_level should also cover what you need. https://github.com/kongondo/MenuBuilder/tree/dev#options Please let me know if this solves your issue.

Hi @alan, Hope it's not too late to reply. Sorry I missed this! It is possible but the how would depend on the condition you want to check for to decide whether to output the whole menu or just part of it. There are at least two solutions: Using their IDs, remove unwanted menu items from the array or object returned by getMenuItems(). This would probably cost a bit more in memory, but probably nothing to write home about Modify the menu function in the gist you've linked to, to filter out IDs of unwanted items. It should suffice with creating an array of unwanted parent IDs. The, in the recursive function, check, for example if(in_array($m->parentID, $arrayOfParentIDs)) continue;. This is pseudo/incomplete code. You would also need to account for menu items without parents, etc. If you gave us more info (condition to check for), I can give you a more clear answer.

Hi @LMD. Sorry about that; forgot about it. Pushed a fix to the dev branch. Please check and let me know if it works for you. Thanks.

Update: Menu Builder Version 0.1.8. Changelog Added support to disable menu items + related (required for this) permission 'menu-builder-disable-items'. Thanks @cjx2240 Support not to show menu items (pages) not listable to current user. Needs option 'check_listable' => 1 in $options Array. Thanks @Peejay 'current_class' now also applies to Breadcrumbs as well. Thanks @Jonathan Lahijani Note Disabling a menu item cascades the status to all its descendants. In Build Menu view (backend), disabled items displayed with strike-through. Currently available in dev branch only. Please test and let me know, thanks. Screenshots

Technically, nothing is stored in a page, but a field. 10,000 rows of entries in one field is nothing really. MySQL can easily handle millions of rows. The crucial question is usually how you are going to query those rows in a fast and efficient manner. One can't and shouldn't query all the rows. Instead, it usually boils down to using a combination of limit (number of queried rows) and caching. Welcome to the forums .