Rob

Hi, A ex-colleague of mine alerted me to this forum post. I haven't been active in this community (or with Processwire in general) for over a year so I haven't been keeping an eye out here. I apologise for any inconvenience that my broken modules may have caused! I simpl don't have the time to look into this at the moment, so all I can suggest is that someone fork my code on github and try to remedy the situation themselves. Both sets of code are pretty basic and were created to solve small issues I had with internal projects I was working on at the time. Since moving on to new jobs, I have not had the time or need to maintain these, for which I apologise. I have not kept up with Processwire development as I have since been working with different technologies and frameworks. I'll try to keep an eye out here in case there's anything else I can do to help. Rob

After a lot of research I've found the solution, which is to make the Silex session handler wrap the existing session handler. So far, so good!

Afternoon all. I'm bootstrapping the API (by including index.php) from my application which is built using the Silex micro-framework. I have run into a problem after updating to more recent versions of several Symfony components. Basically I cannot start the Silex session component because it is reporting that the PHP session has already started. This has not been a problem until now so I can only presume that the previous version of the Symfony session component was not checking if the session had already started. Long story short - is it possible to disable the Processwire session handling when using the API? Unless I am mistaken, if I am using my own session handling mechanism and only using the API to fetch page data etc then I should not need Processwire to have it's own session handling as it will not be being used. Any help gratefully received as I am basically dead in my tracks with this problem!

Good afternoon. I have a strange issue whereby I have a custom-coded FieldtypeTags field named "tags" that is comma-separating values and storing them in the DB. Against one set of pages with a template with "tags" field call I seem to be able to do $page->children('tags*=sometag') with no issue but on against different template that contains the same "tags" field I get the following error: WireException: Operator '*=' is not implemented in FieldtypeTags (uncaught exception) I am not aware that I have done anything different in either case, they are simply 2 different templates that both contain the same "tags" field, one which responds to this search criteria and and one that gives me the error. I have checked the DB and there is a value stored in the field_tags DB table against the page I am trying to select. I'm out of ideas - any suggestions?!

Great, that nailed the problem - thanks Ryan!

Hi all. I've run into a strange issue and am getting the following error when I try to empty the trash: Error: Call to a member function hasRole() on a non-object (line 1203 of /var/www/vhosts/web_v4/admin/wire/core/Page.php) I am also getting this error when I try to edit or delete some of the individual pages in the trash. I cannot delete any of them, and if I try I sometimes get that error and sometime it bounces back to the page listing but all the pages still remain. I had a hunt in the forum and I found some references to the above error but in a different context. The only other detail worth mentioning is that I am on v2.2.12. My instinct is that there is perhaps pages in the trash for which the relevant template/fields no longer exist and this is causing some sort of confusion. Any suggestions welcomed. I am trying to delete old unused templates but I can't because (I think) pages in the trash are still using them! Thanks.

Thanks all. I had the delegation+selectors correct, it's just that I needed to trigger('click') the fancybox manually. Soma - learned a lot from examining your module code so thanks! I'll probably just use your module because it is ready-to-go, but always good to learn more about the plugin API but also JQuery in particular as it's one of my weak spots.

Thanks for your help, but I'm not sure that's what I'm after. I don't want to add edit links to my generated pages, I want to add an extra edit link to the page tree in the back-end so that I can click "modal edit" and have the regular page editor load but in a modal window so I don't have to leave the page tree. This may well gives some pointers though, so thanks.

I am trying to write a module that adds a link to the page listing to allow for editing a page in a modal pop-up window rather than loading a new page for the edit. The idea is that if I use a nested data-page structure to get around the inability to have nested repeaters then it would be nice to be a faster workflow to add/edit/save those child data-pages without leaving the site tree. I had a look for existing modules/settings but couldn't find anything. So next up, I'm thinking I can make the edit page appear in a fancybox modal. The problem I've run into is that I can't work out how to "attach" the fancybox to links that are being generated on-the-fly using AJAX which is how I believe the page tree is rendered. So at the "page ready" state the links don't yet exist so the fancybox attach code doesn't do anything. Can anyone suggest a way around this or point me in the direction of an existing module or code that can help? Thanks!

Great, thanks, that makes perfect sense.

Hi - great module which will help me a lot, but I'm a bit confused about this point. My stubs.php file is generating fine and documents all the fields in each template, but it is only documenting related page fielsd like this... @property PageArray|Page[] $related_products ...meaning that I get code completion for al the core Processwire Page fields/methods but not my template fields. Shoud it be generating like this... @property tpl_product[] $related_products ...so that I get code completion for all the fields of my related page/template? Is this a bug or do I need to change some config somewhere? I couldn't find anything. I am perhaps misunderstanding how the phpdoc comments informs my IDE (PHPStorm) but as it stands, I get my first-level fields for a page but nothing for the related page fields. I downloaded the module as master.zip from github so it should be the latest code.

If you are deploying on LAMP, then set up a LAMP stack in a virtual machine. You can get VMWare Player for free on Windows and install Linux very easily. In my opinion it is better to fully understand the tools you are using and understand how to setup the LAMP components etc. It also makes it much easier to replicate the live environment if you can at least try to have the same version of Apache, PHP etc. I used to use WAMP and XAMP out of laziness, but it can cause problems. For example, windows (at least back then) is not case-sensitive and Linux is, so you have potential for problems with filenames right there. With a pre-packaged stack you lose control and it can be harder to locate problems, fix bugs etc. I understand why some people use these things when they start programming, but if you are serious about doing LAMP development, you will need to learn this stuff sooner or later. I have not once regretted teaching myself to do command-line linux, install packages, set up PHP etc. It will pay off in the long term. And once you know it, you can spin up virtual servers on the cloud for all kinds of purposes very easily, and maintain total control.

Before I forget - Thanks to Soma for help with a module issue I was having.

Thanks!

Hi fellow forum friends. I've released (on github at least) my new module - Page Edit Fold Status. May not yet be live in modules section of the site. https://github.com/robphilp/PageEditFoldStatus What this does is use a combo of JQuery, Ajax and the session to remember the state of each field when you edit and then save a page, so that when you return to the page after the save (or later) it will recall that state and fold/unfold all the fields so the edit page is how you last left it. We have pages with a LOT of fields on, and we found it irritating to have them all default to open. That said, if they default to closed and you have to drill down to edit some specific bit of data, it's annoying to have to drill-down again each time when you are making many incremental edits, so I made this module to store the state on a per-page and per-user basis. e.g. some users will need to focus on certain fields, so if they have these open and all others closed, it will retain this state each time they edit a page. No need to open/close these fields each time so you can focus on what's important to you. Because of the use of the session, this behaviour SHOULD last for the lifetime of your login. I hope it is helpful! Just realised I've put this in the wrong forum, can someone move it for me?! Thanks!