Leaderboard

The PW issues repo is a bit of a cause for concern I think. Issues are added much more frequently than they are solved, so the collection of open issues is just going to grow and grow over time unless something changes to accelerate the rate at which they are addressed. At the end of the day, it seems the volume of issues is too great to deal with by just a single person with limited time. And a comment Ryan made in a blog post a while ago left me a bit puzzled: Maybe I'm reading that wrong, but it sounds like Ryan believes that almost all significant issues are already solved. I wouldn't agree with that as I think the majority of the open issues are valid ones that affect multiple people. Maybe the fact that there are quite a few issues that have been solved but are still left open is obscuring the fact that a significant number of unsolved issues exist, some dating back a long while. So I would support the idea of closing issues marked solved if it also meant taking a fresh look at the ones not yet solved.

These look like false positives, especially given the last one (a CSS file served by Apache). What's happening here is that your server is taking a long time to respond to the requests, and the testing tool is making the assumption that because it responded slowly, it must have executed the command it sent (sleep and timeout). Most likely your server took a long time to respond to the request because that testing tool is hitting the server hard, and it's either struggling to keep up, or it's throttling the tool, limiting how many requests it'll respond to at once. It's also possible you've got another server-side security tool that is detecting something trying to mess with it, and interrupting the request. With a tool like ZAP, false positives can happen, so you should use it to find where to look, but use the information it gives you to confirm on your own whether it's an issue or not. And if you ever think you've found some security an issue in any software, contact the author directly, don't post it in a public forum. The only other thing I'd suggest is to look at your site template that serves the first URL it mentions, and check if you are using a GET variable named "query", and if so what you are doing with it. However, I think this is unlikely given that it's reporting the same error on a CSS file, which is served directly by Apache, not ProcessWire.

The only sane approach to issues on github I know is closing them as fast as possible, which can be split up into subtasks by deciding if something is a … bug => fix as fast as possible/fitting and then close directly. If there are still things to clarify this can be done in the closed issue. ryan can open it again if really needed, but it's ryans task to say "this issue is resolved" by marking/keeping issues closed. Keeping that responsibility on the issue openers side simply does not work from my experience. feature_request => should be closed immediately with a message to where feature requests should be stored not a bug => closed immediately not reproducable => ask for failing test/repo/something, close if there's no response after x (2-4) weeks

Yeah, I completely agree - it seems that VentureWeb always adds jQuery to their sites, but I rarely do. Let me check with them and see if they'd be willing to work with a non-jquery version. I have commit access to the Drupal version's repo, so if you or someone else would like to convert the PW version, I'd happily port those changes back to Drupal so things are easier going forward.

A significant update: 1) new auto-accept mode 2) fixes an issue when in EU only mode but the user is outside the EU - GTM tracking beacon is now properly sent 3) tweaks to support older versions of jQuery. Please note that these changes are basically just a port of recent changes to the original Drupal version of the module so let me know if you notice any problems.

Hi. Test this $module_id = wire('modules')->getModuleInfo('ProcessSettingsFactory')['id']; $adminPages = $this->wire('pages')->find("template=admin, process=$module_id");

@Sten, your module looks like it is missing the required getModuleInfo() method. Check the Module docs for what is required in a module. The Hello World module is a good one to learn from too. And Tracy Debugger is a must-have for debugging modules or anything else (the Tracy bd() method is all you need to learn to begin with). Also, when you want to make changes to a Page in a Pages::added hook you need to do a $page->save() in order to save the changes. Not wanting to hijack your module or anything but when you first posted this topic I was interested in EasySlugger and put together a simple module to test it out. I've added a couple of comments to the code that might help you. <?php namespace ProcessWire; class Slugger extends WireData implements Module { /** * Module information */ public static function getModuleInfo() { return array( 'title' => 'Slugger', 'version' => '0.1.0', 'autoload' => true, ); } /** * Ready */ public function ready() { // You would generate the slug/name after saveReady or added, but not both $this->addHookAfter('Pages::added', $this, 'afterAdded'); // $this->addHookAfter('Pages::saveReady', $this, 'afterSaveReady'); } /** * After Pages::added * Set the page name using EasySlugger only once when the page is first added * * @param HookEvent $event */ protected function afterAdded(HookEvent $event) { require_once __DIR__ . '/EasySlugger/SluggerInterface.php'; require_once __DIR__ . '/EasySlugger/Utf8Slugger.php'; $page = $event->arguments(0); $page->of(false); $page->name = \EasySlugger\Utf8Slugger::slugify($page->title); $page->save(); } /** * After Pages::saveReady * Set the page name using EasySlugger every time the page is saved, in case the Title was changed * You could add a condition to set the name only if the Title changed if you like * * @param HookEvent $event */ protected function afterSaveReady(HookEvent $event) { require_once __DIR__ . '/EasySlugger/SluggerInterface.php'; require_once __DIR__ . '/EasySlugger/Utf8Slugger.php'; $page = $event->arguments(0); $page->name = \EasySlugger\Utf8Slugger::slugify($page->title); } } Slugger.zip Note that there is a minor core issue with warning notices from ProcessPageAdd that will hopefully be fixed soon: https://github.com/processwire/processwire-issues/issues/648

Time for a little update. ? There are many changes again. Most visible: More Ajax, more Drag&Drop, more Wysiwyg. Real containers (Tree hierarchy) instead of "nested groups". Rows are also containers now. In this little video, I will show you how to layout a responsive page from scratch without writing a line of code. http://theowp.bplaced.net/upload/reptile.html This system is not for absolute noobs. You need to have an idea about how responsive web pages and Bootstrap work. But then one can be really fast I think. Still a long way to go, but I hope you like the idea. Thank you.

Hello @ryan and @Francesco Schwarz, There are currently a lot of issues (about 20% of the total) that are still open on the processwire-issues repository but marked as "Resolution: fixed (close when ready)." Some of these date back over a year. I doubt many of the older ones will ever be closed by the initiator. There is a similar situation building up with the issues tagged as "Resolution: Not a bug" - though there are less of them. If that's the case, how about closing any issues that are 3+ months old (or that have not been tagged as a discussion) with a polite note that the issue should be re-opened if needed? This would really help reduce the list of open issues.

@netcarver Yes sure, this is the aim with help of @Robin S

If the module is so tightly tied to the drupal module then converting the js from jquery to pure js would mean constantly tracking changes and too much possibility to fail somewhere in the conversion. The best would be then to ask the drupal devs if they are willing to drop jquery - if yes, we could help in the first step but after that they should be able to add updates (in pure js). I don't think every drupal site is using jquery, or is it so?

Well, nice to see some fixed issues being closed now. I count 35+ closures since yesterday, which takes the project well below 200 open issues. I do hope that some progress can be made on other items. Can we ease creating pull requests for small items in any way, perhaps that would help the overall effort?

@Macrura https://github.com/outflux3/SettingsFactory/blob/master/SettingsFactory.module#L69 I don't think that looping through all admin pages is the optimal way to find all settings pages. In that way, on every page load, all admin pages get loaded and it produces a lot of unnecessary PDO queries. For example in one of my project, I have a lot of repeater/matrix pages and I get this stats without/with the SettingFactory module: Pages loaded (38 / 239) PDO queries (38 / 224)

Hi @netcarver - I very much appreciate where you are headed with this, but I am not sure I agree with automatically closing issues 3+months old (even those tagged with not a bug, or fixed) because there is often further discussion after tagging which I think warrants further input/consideration from Ryan. One example is: https://github.com/processwire/processwire-issues/issues/494 - others have chimed in with their agreement and I still consider it a bug because it's possible to set the description and notes for a fieldset. If Ryan doesn't think it's a bug, then I don't think it should be possible to set these in the first place, because it's current confusing and inconsistent behaviour. While I don't expect this will ever be high enough on his priorities to be fixed I still don't think it should be closed because I am convinced it's still something that needs attention, one way or the other. I think the best approach is to encourage issue OPs to be more diligent in closing fixed issues because with so many building up it becomes even harder for Ryan to reconsider some of these other ones which still have some validity. I hope that makes sense and doesn't seem obstructionist in moving forward with an improvement to the current situation which is obviously getting out of hand and not sustainable.

I went with the JS approach only to start with because I wanted the user to be able to see what the name is in realtime when they change the title of an already existing page - the same as we can when creating a new page. There are also other options like locking the name from being changed etc which I wanted to include in the module which also work best via JS. I only added the saveReady hook later when I realized that I also need to support title changes via the API (and also when the settings tab is hidden and the name isn't added to the content tab). As far as supporting EasySlugger, I think it can be done, but probably differently - maybe I just need to add a check to see if that module is installed and then also use the saveReady hook option rather than the JS one. Or maybe the EasySlugger module can just do that anyway, even after this module has done its thing? Not sure, but let me know what you need and I am happy to support it.

I'd be happy to, but I think the problem will be that this module mostly works with JS in realtime as the title is changed. The renameOnSave method that includes that line you referenced is only called by API changes to a page's title. So I guess I would also need to make sure renameOnSave is also called when the new EasySlugger module is installed and activated. Or are you thinking of some other approach to this that I am missing?

Hi Adrian, @Sten is working on a module that uses EasySlugger to set better page names from titles that use non-latin alphabets. I was thinking that it would be cool if that module (and potentially others) could build on the features that Page Rename Options provides to select what pages are automatically renamed. What do you think about separating off the line that determines the new page name into a hookable method? Then other modules could hook into that to set a custom page name.

Thanks netcarver! Coming from a Drupal background... If an issue has been fixed by the module maintainer, then he/she marks it with a status of "Fixed" see https://www.drupal.org/issue-queue/status#fixed. After two weeks the issue automatically changes to "Closed (Fixed)" see https://www.drupal.org/issue-queue/status#closed. Drupal's issue queues are different than Processwire's. On drupal.org, anybody can change an issue status at anytime. On github/processwire, only the issue creator or admins can the issue status. Although 200 open issues seems like a big number, check out https://www.drupal.org/project/drupal ? Although with Wordpress it's hard to tell what the number is https://core.trac.wordpress.org/tickets/latest

There are a number of screenshots in the blog post that introduced the inline editing. You can see multi-language fields in those. https://processwire.com/blog/posts/inline-ajax-page-editing-comes-to-listerpro-processwire-2.6.6/

ok thanks @Zeka and @adrian, the module has been updated.

@Robin S thank you, I tested your module, it works very well with Hebrew. I only put the Javier Reguiluz' app inside the vendor directory to be able to update it with composer. I'll test it more and tell you. Yes I saw it too. I am grateful for your work.

I saw it was mentioned somewhere but haven't done any further testing with GTM, GA, Matomo or anything else by now. My first site with this module will go online the next days and I will test all three mentioned trackers then.

I'm fine with that. Thought you already tested this new option and looked into it. But for those who want to know more... auto-accept mode is kind of a silent opt-in. While the first view only triggers the banner itself and returns false for if(localStorage.getItem('pwcmbAllowCookies') == 'y') the second and all follow-up page views allow tracking and therefore return true for if(localStorage.getItem('pwcmbAllowCookies') == 'y'). Users will still see the banner and have to either accept (again) or have to opt-out.

right, ok thanks for the report – i have an easy fix for this, will post update soon.

I was wondering if it would be better to change the name of the page after publishing ... wire()->addHookBefore('Pages::publishReady', function($event) { $page = $event->arguments('page'); if ($page->template->name == 'news-article') { $page->name = $page->title . '-myslug'; } });

You can set flags and apply roles allowed to 'view' or 'edit' this field. $field->setRoles(string $type, $roles); // $type = 'edit' or 'view' $field->addFlag(int $flag); $field->removeFlag(int $flag); Reference: https://processwire.com/api/ref/field/ https://processwire.com/api/ref/field/set-roles/ https://processwire.com/api/ref/field/add-flag/ https://processwire.com/api/ref/field/remove-flag/

Hi szabesz! Thanks for the information! That's good to know. I will let my host turn mod_security off … Köszönöm szépen!

It seems I didn't sample enough of the comments put on the issues. Not all of them @ mention the initiator - so my comment isn't totally valid. I've therefore started @ mentioning the initiating party on the resolved threads - but it takes a while, so I'm appreciating @gmclelland's robot suggestion more now, though I think I'd not want it to auto-close issues but rather auto-remind the initiator to do the close, and later flag it for a human closure decision.

oops, this server is running 7.1.19, so this is a warning... I got rid of the warning, had to downgrade to an earlier version of 2.7.3 (dev) and then hotfix the files field to get the images working again...

PHP7.1 still has mcrypt.

@Macrura mcrypt is no longer part of PHP as of version 7.2. You can still install it via Pear. Do you have a file + line number for the deprecated warning? Update: There is a possible polyfill here - I've not used it myself.

Ok... I got this totally wrong in your first post and didn't get this @-comment/feedback process. Sorry if my answer was therefore kind of rough. With this comment/feedback process I'd agree with your concept of closing unanswered-open-but-fixed issues.

Thanks for the feedback everyone; some really good ideas here. I guess that Ryan and Francesco are the ones who get to declare if things are getting out of hand though ? Whilst there is, obviously, the ideal issue closure (issue closed by the opening poster after verification that it is really fixed); the reality is that many of the issues have been left unanswered for many months following a commit to the codebase, addition of a tag and a comment on the issue with an @ mention to the person who raised it. If there is no feedback for months following these actions, I'd personally be inclined to close the issue with an invitation for anyone to re-open with a follow-up post if needed. IIRC anyone can re-open an issue by simply posting a new entry on it; closure does not necessarily mean an end to a conversation. Best wishes! Steve

The hard part is getting OPs to actually close issues when they are fixed and there is no ongoing discussion - if we could do that, then things would look quite a bit leaner in the Issues repo.

Hi all, I've just noticed that when using the Login/Register module if a user on the frontend gets the password wrong too many times in a short time space the SessionLoginThrottle stops them as it is supposed to but rather than showing an error on the form it makes the server throw an internal error page with: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Error has been logged. Administrator has been notified. Should it not render the error next to the form like the back end login?

https://github.com/ryancramerdesign/LoginRegister/issues/10

Thx for the clarification @adrian. Ok, if the usecase fits it seems to be a good solution, but I wished there was a good way to have better and easier control of which pages are shown inside the admin or inside the tree. Taking care of all that tedious stuff (search, pagination etc).

Hey @bernhard - the issue with the num of children is still there, but it doesn't affect the ARB module because it only shows the one branch that the user is allowed to see. I don't think ARB is hacky - I think it's a good solution if it works for your use case. Some of the gists linked to in that post above however are a bit hacky - they don't handle lots of things (like search results) and also have the num children issue and also the problem of hiding a parent of a child that the user might actually have rights to.

I'm glad you could have it fixed, however it is worth to note that the site might also get hit by other mod_security rules in the future, so it is best to turn off mod_security altogether. ProcessWire does not need it.... for example: http://www.amitb.info/dealing-with-a-mod_security-nightmare-with-apache-and-codeigniter/ quote: "First thing, don’t waste your time chatting with your hosting company support staff. The front line support staff is not very equipped with dealing these complicated things. They are usually adept in dealing with normal things which occurs in volumes. So skip them altogether." also: https://stackoverflow.com/questions/12928360/how-can-i-disable-mod-security-in-htaccess-file