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!

Thanks for the help Soma, I'll have a play and see what works.

Hi all. I've had this problem before, and after reading a bunch of forum posts, I'm still no clearer on what is the correct procedure to load a JS script AFTER jquery core. There is some conflicting information and I'm starting to get frustrated over here! The following code doesn't even seem to execute the __execute() method so it neither adds the jquery cookie script nor the hook. <?php class PageEditFoldStatus extends ModuleJS { public static function getModuleInfo() { return array( 'title' => 'Page Edit Fold Status', // printable name/title of module 'version' => 0.1, // version number of module 'summary' => 'Uses cookie to remember fold status of fields on page edit', // 1 sentence summary of module 'href' => '', // URL to more information (optional) 'permanent' => false, // true if module is permanent and thus not uninstallable 'singular' => true, 'autoload' => true ); } /*public function init() { parent::init(); }*/ public function ___execute() { $class = $this->className(); //echo $this->config->urls->$class . "js/jquery-cookie-master/jquery.cookie.js"; exit; if(is_file($this->config->paths->$class . "js/jquery-cookie-master/jquery.cookie.js")) $this->config->scripts->append($this->config->urls->$class . "js/jquery-cookie-master/jquery.cookie.js"); $this->addHookAfter('ProcessPageEdit::execute', $this, 'triggerScript'); } public function triggerScript(HookEvent $event) { $script = <<< _END <script type="text/javascript"> ...JS code... </script> _END; $event->return .= $script; } public function isAutoload() { return true; } } It seems like I would want this to auto-load because it isn't a Process module and I need it to add the ProcessPageEdit hook. Any thoughts?!

I tried adding paragraph stripper formatter after markdown, and before, it made no difference at all. There is an empty space at the end of whatever is generated, with or without any extra fomatters. I guess I'll just have to work around it.

Thanks for the pointers - is the suggestion therefore that there is a bug but it's just one I have to work around?

I ran into a strange problem to do with checking if a field is empty and then rendering content or not. Having poked around a bit it seems to me that the Markdown Extra formatter is actually outputting a string with a single space in it when I have no content in that field in the CMS. This meant that, in the context of my TWIG-powered templates, when I was checking for a non-empty field, it was returning false and still rendering something. Can anyone confirm this for me? I have a textarea field with a single Markdown Extra formatter. When I enter nothing and save, then I var_dump() the field in my PHP code, I get a 1-character empty string. Thanks in advance!

Ah....I think I just had a lightbulb moment. So you're saying that the easiest thing would be to iterate the repeater pages (under admin) therefore avoiding the issue of having to iterate the parent pages themselves filtered by those using the repeater. I'll give it a try!

I'm sure this sounds like a stupid question, but I'd like to replace a number of fields that make up part of a repeater with different fields that are of the same type, but without losing the data they contain. To put it another another way, I want to swap field X for field Y on a template, and then for each page that uses that template, the data that was in field X be copied into field Y. I feel fairly confident that this is going to be a complete pain or simply not possible!

I seem to have a lot of repeater data (under /admin/repeaters/repeater_name) that don't seem to be linked to anything. It is possible that this is a Handover from older PW version but what Ican't work out is an easy way to get rid of all this cruft from the DB. It seems like some of it I can delete, but some of it doesn't have the page delete link. I tried to delete one set of repeater data that DID have a delete link and I got some sort of role-based error. The names also vary, most of the "orphaned" repeater pages have cryptic numerical names, whereas the "live" repeater data I want to keep is named after the page is it attached to. Can anyone clarify if there is an easy way to get rid of the orphaned data? I'm reluctant to start poking i nthe DB for fear of making a complete cock-up of it!

I guess we have no further development on this. I suspect that the best option for most people is to just try to get their repeated-work process as painless as possible. One option I have used before is to actually have the entire workflow (including any work/edits that the "client" does) handled on a staging server/site and then just manually or automatically (cron job) mirror the entire thing to a live server/site. If you do it the manually-triggered-mirror way, you can still develop in a relatively safe place and let the client make edits etc, and perhaps just give them a simple one-button mechanism to trigger the mirror script. Unfortunately I think that anyone who has been around the block for a few years (myself included) would testify that there is no easy way to do this stuff and that it depends on the site/context etc. I've certainly never seen a perfect system that didn't have (at least) occasional problems or require some level of manual work for the developer. Not when it comes to anything more complex than a simple blog anyway. Throw e-commerce or large traffic into the mix and it gets even more painful! Perhaps time would be better spent discussing our own workflows so at least people have some ideas they can draw from. It seems a shame for any of the talented devs here to spend too much time banging their heads against a wall to only come up with part solutions or sidesteps that don't really solve the inherent problems of content management and deployment.

A fieldset is a visual-only organisation tool, which is not the same as being able to logically/structurally group fields. It doesn't prevent the problem of an ever-growing list of fields that have to be manually "namespaced" by using prefixes and the like. I think that if it is not used to excess, there is no good reason to not use repeaters for this purpose. It serves the purpose of grouping fields into "composite" fields and it uses standard PW techniques to do it (pages under the hood). It is a matter of preference, but for me a repeater used in this way can help me re-use my generic fields in a useful way and reduces the actual number of fields I need to create and manage in the back-end. This is a win-win situation for me, and based on everything I've read here, the suggestion is that PW can happily scale to a huge number of pages. If repeater items are just pages (whic hthey are), and the scaling is handled well, I can see little downside to this approach!