Leaderboard

I can see a few issues, mostly relating to your formatTags setting: 1. The Format plugin is for block-level elements and the <a> element you have included is not block-level. 2. Normally list formatting is applied with the dedicated <ul> and <li> buttons and not via the Format dropdown. 3. You are configuring format tags but you haven't included the Format dropdown in the toolbar, so the format tag options aren't going to be available the user. 4. If you specify format tags beyond those configured by default in CKEditor (p;h1;h2;h3;h4;h5;h6;pre;address;div) then you have to configure corresponding "format_(tagName)" settings. This is the cause of the JS error. From the documentation: 5. Usually you don't want TextformatterEntities applied to a field that is going to contain HTML. If what you are trying to do is remove the heading options from the Format dropdown then you can set Format Tags to "p" only and the NumberedList, BulletedList and PWLink toolbar settings will allow those corresponding tags also.

Hey, I've tried a search but couldn't find anything about this precisely. Is there any explicit setting to add images to the start of an image field rather than the end on upload? I'm assuming I'll need to figure this out with hooks. Please ignore. Noob mistake asking a question from a client, they weren't drag dropping and I had a brain spasm.

Thanks for your thoughts @teppo - I agree it's not a simple problem to solve and that there are some gotchas for sure. However I feel like if some assumptions are made, it could be made to be functional. Firstly, if only supported first level pages (those directly under home), we could simply strip off everything after the second forward slash and assume those are urlsegments and simply find the page that matches the ID of the page whose name was changed and then re-append all those segments as they were in the original URL. I know this wouldn't solve the problem for all setups but I bet it would handle most. I think this discussion should be continued here: https://github.com/processwire/processwire-requests/issues/338

Thank you, I'm glad it's useful to you and thank you for your donation. ? Unfortunately, cross-copying is not possible because at the point where you initialize the copy, the module does not know the name of the other field. So it can only read the current name of the matrix field and use this name when copying to the target. I'll think about whether you can introduce an option to select the target field before copying. But I think there is a lot of potential for errors when copying. So first of all, unfortunately not possible at the moment. BTW, @ryan, the module has been in checking for the module directory for several months now and has not yet been released. Does this module bother you in the context of a free extension for your ProModule?

First of all... thank you @adrian for the introduction and the great work with this module. In the last couple of days I created a DEV branch with some minor changes and fixes I found while testing the latest version (0.4.11). If you are interested in playing around with that version, grab a copy over at Github - the DEV branch is linked below. As always: backup your site and previous module first. All changes so far: FIXED: Vanilla JS version notice toggle didn't work when MANAGE disabled FIXED: Version change didn't trigger reset INFO: Added usage examples (assets/html) CHANGED: Removed CLOSE option ADDED: Datalayer details to README Issue tracking on Github was also enabled. This could make things easier in the future. Feel free to open an issue there whenever you find a bug. Don't forget to add the obvious details (ProcessWire version, PHP version, expected behaviour, your module settings and custom code). DEV-Branch https://github.com/webmanufaktur/CookieManagementBanner/tree/dev Issues https://github.com/webmanufaktur/CookieManagementBanner/issues

I discovered Wireframe on Sunday after exploring the GitHub repo for the ProcessWire Composer Installer project that you mentioned in the latest PW Weekly. The documentation you've written for Wireframe is just awesome ? - engaging, comprehensive and clear. I have a short question and a long question... Does it make sense to use Wireframe together with Markup Regions in any way, or would a developer choose Wireframe or Markup Regions but not both? The long question relates to what you said here: I take this to be a reference to the superiority of a MVC approach versus the "default" approach of mixing business logic and UI logic together in a PW template file. I'd like to hear more of your views on this because you didn't talk about it much in the documentation, probably because MVC and the separation of concerns is discussed in plenty of other places around the web. But I was wondering if you think a MVC approach is always the way to go, or if is something you would weigh up the pros and cons of taking into account the parameters of each specific project, e.g. the scale and complexity of the project, if a team will be working on the project, etc. Personally I use Markup Regions and don't use any separation of business logic and UI logic into different files or folders. From time to time I think about changing to an MVC approach because so many people seem to recommend it, but when I weigh it up I don't see enough advantage versus disadvantage for the kinds of projects I work on. But maybe I'm overlooking something so I'd appreciate your comments. The main benefits of MVC as I understand it are... 1. If you have a team of people working on a project, maybe with different skill sets (e.g. a front-end dev and a back-end dev), then it lets each person focus on the parts that matter to them. For example the front-end person can focus on the view file without having to see any business logic which might distract or even be unintelligible to them. This totally makes sense to me and if I worked as part of a team this by itself would make an MVC approach worthwhile. But in my case I do everything alone from start to finish - design, front-end, back-end. 2. The business logic doesn't "belong" in the same file as the markup - it's better to keep it separate and it makes it easier to update a site. This seems more contentious to me, and perhaps depends on how much business logic there is. If I have some variable that I'm using within the markup I find it very handy to have the definition/construction of that variable present alongside its usage in output. So I'm not left wondering "what was it that I put into $related_products?" and needing to navigate to some other file to find out. Now if there were heaps of business logic it might start to feel like clutter within the markup, but when I look at the template files for my projects in most cases there's actually very little business logic present. Maybe that's partly because PW is quite elegant in that you can do a lot with a few lines of code, and partly because most of my projects are not very complex. But even if I do have a lot of business logic I find that placing it at the top of the template file is no problem at all. If I need to work on it I'd rather just scroll up than open another file, and I can use my IDE to collapse any blocks of code that I don't need to focus on. Would you say that MVC is an approach that is more suited to complex projects rather than simple ones? Things like layouts and partials that are offered through Wireframe are cool, but those are also possible with Markup Regions (layout = _main.php) and built-in PW methods (partials = $files->render). I have no doubt that Wireframe is a powerful tool, but do you see it as being the right solution for all projects or just some projects?

Hi, Got it solved myself. I use $p = $pages->find("template=repeater_yourRepeaterField, limit=10") rather than $p = $page->yourRepeaterField->find("limit=10"). Gideon