Ivan Gretsky

Good day! I am exhausted trying to get it working on my own so begging for help) I made a frontend form to edit a page. When the form is submitted, I get all the values for the fields from the input, get the required page in $_page variable and assign inputs to the fields. After that I perform $_page->save(). All simple fields get saved as they should. Dealing with page fields I remove all the pages in the array and add the new ones from the input like this: $_page->pagearray->removeAll(); foreach ($input->post->pagearray as $item) { $_page->pagearray->add($item); } In the case of $_page->save() id does not save. But if I do $_page->save('pagearray') it does. I think it is not the right thing. Probably I am doing something wrong, but I can't figure out what. Please be so kind to help! Edit: Corrected the code

I have been messing with some frontend editing for a while and do not think making custom backend for editors is worth the effort in most cases. The interface will most likely be inferior to the one present in admin. Especially with addons like ListerPro. I do think that "modifying the appearance and functionality of the PW interface" is the more easy, cheap and capable way to go. I can see lately there is a lot of useful modifications to PW, like abilities to rename and hide tabs, add new pages from menu, new permissions and so on, making this path easier. Dynamic Roles module is really usefull here (too bad it is not even in modules directory yet). Pro Drafts is on its way. I think maybe creating a custom admin theme with stripped out functionality could be an option. Though I do not know abouit it as I have not tried it. Tom Reno is the man to ask about it) But of course you can do a totally custom backend as complicated as you wish, but I would not do it for anything but submitting an article type of workflow.

I think you can write a hook that will work both in frontend and admin. But you have to get the $page like this: $page = $event->arguments[0]; It seems like $page = $event->object; returns the actual page, which is admin with ProcessPageEdit in admin. But the first value in arguments array is the page we want to get in both cases, at least for saveReady event.

Could you please suggest a hook to store the value of a field to later compare it with the one got from the $page suitable both for frontend and admin?

I have made a similar site in joomla with a paid extension. I had to mess around a bit making it work together with a subscription and a CCK components. But if you do not need those, it is quite fast to get started and import quizes. Not sure if that it is a path you are ready to consider though, and surelly not a "proper" way for a PW or a Laravel skilled developer . I am sure it is quite possible to do it with PW, but it will demand some effort (as with Laravel).

You could write a module (or just a hook somewhere like site/ready.php) that would fill a (hidden?) texarea field on page save for the desired templates. That field would probably show in pagetable without an error.

I do not see any accidental way this could happen. Maybe there is another ProcessPageView being finished? The only thing I could think of is a FormBuilder form in an iframe at the top of a page or something like that.

I got the same error after manual upgrade on a live server. But the error only appears on admin. I rolled back, but the problem persisted. Any help appreciated. Edit: After a relatively short period of time it started working again. So the 1st solution is to wait a bit )

I like the idea. I have been looking for proper way to version control PW sites recently, and have not ended with a clear decision for myself. Of course "it depends on a project". But we can come up with a tutorial helping make the choices. What to version in git I never tried initialising a git repo in templates folder, as Ryan suggested here. Custom modules and now site/ready.php should go to version control, as well as config.php. For me the choiсe is either to version the whole installation or only the /site folder. As I usually modify the .htaccess I am leaning to the former. The next thing is what to ignore. Some think you should ignore /wire, some think it is worth having it in the repo. If we could (I mean If I knew how to) install the needed version of PW core as a dependency via composer or include it in a similar way automatically after deployment / git checkout, it would be better to leave /wire off. But for simplicity it could be better not to exclude it as it is quite small. That definately should be excluded is some part of site/assets. If the site is a big one, excluding site/assets/files is a must. But for a small near to static it is probably worthless. You should probably ignore these almost every time not to mess with constantly changing data: site/assets/cache site/assets/sessions site/assets/logs I found no reason not to include all modules to the VCS. Deployment Speaking about deployment, I do not like the idea to deploy every time I commit (which seems to be the case if using git-hooks, if I am getting it right). There are other ways for deployment with git, but I an intrigued by doing it with something like this or this (both are capistrano-like deployment tools in php). Anyway, I do not seem to find a way to easily deploy database changes. Maybe in the case of semi-static sites it is possible to dump a database and restore in with git-hooks (or to include a sql dump from sites/assets/backup/database to the revision and manually restore it), but it probably will never work with subscription sites and rich-content sites managed by clients. The only way to keep track of changes made to the database via PW GUI (admin) I came up with is keeping a journal. I made a folder where I include subfolders related to git commits with JSON export files for fields, templates and forms, which should be imported. Pages are just described in .txt as I know of no way to export them to something like JSON. It would be awesome to have something like the things discussed here available not to do it manually. Hope it is somehow useful. I would be delighted to hear how others do it, as I am certainly only an amateur in all this stuff.

@Wanze Do you version control your wire folder?

Seems like a lot of work you have done. But why is this module even needed while we have native PW multi-lingual support. I am probably missing something, so please be so kind to point out the differencies.

1) As Ryan proposed It seems to be wise to init a repo in templates folder. But there are files higher in the structure that influence site behavior a lot and need to be version cоntrolled, like config.php and .htaccess. Do you know of a way to include those? 2) It would be great to know if someone installed or upgraded core or modules. Maybe there could be a way to make a list of installed modules with something like git hooks (or a PW module) and their versions and put them in the templates folder somewhere. The same could be used for templates/fields/pages, but I am not looking that far yet. Did anyone try that? If that is possible there would be no need to mess with complicated .gitignore and init repo in the installation root.

Good day! This topic got split off this post in Jumplinks topic. It seems the problem is not related to the module. I got a site that responds differently to different subdomains. I am writing a .htaccess redirect from www of a subdomain to no-www. RewriteCond %{HTTP_HOST} ^www\.subdomain.domain\.ru$ [NC] RewriteRule ^(.*)$ http://subdomain.domain.ru/$1 [R=301,L] If I run www.subdomain.domain.ru it gets redirected to subdomain.domain.ru. But if I go to something like www.subdomain.domain.ru/something I get redirected to subdomain.domain.ru/index.php?it=something/ not to subdomain.domain.ru/something. I tried putting my code before and after PROCESSWIRE HTACCESS DIRECTIVES block without a difference. Could you please give me a hint here?

Yep, but to assign these new permissions you need to first assign prerequisite permissions. Hаve you managed to do it?

It does work in firefox and chrome dev tools.

I think you need page-edit and user-admin permissions assigned to a user to be able to set them new granular user-admin-XXX permissions.

Good day, Mike (and all the other redirect maniacs)! I got a site that responds differently to different subdomains and got Jumplinks installed. I am writing a .htaccess redirect from www of a subdomain to no-www. RewriteCond %{HTTP_HOST} ^www\.subdomain.domain\.ru$ [NC] RewriteRule ^(.*)$ http://subdomain.domain.ru/$1 [R=301,L] If I run www.subdomain.domain.ru it gets redirected to subdomain.domain.ru. But if I go to something like www.subdomain.domain.ru/something I get an error: You don't have permission to access /index.php.pwpj on this server. I turned the module off and realised that it is not the module that is the reason, as I still get redirected to subdomain.domain.ru/index.php?it=something/ not to subdomain.domain.ru/something. I tried putting my code before and after PROCESSWIRE HTACCESS DIRECTIVES block without a difference. Could you please give me a hint here?

The server-side validation via pattern does not seen to work. At least I can save a page via api with field value not matching field pattern (I set the pattern without php delimiters like "/"). Should I call some validation method explicitly?

The issue is moving forward https://github.com/ryancramerdesign/ProcessWire/issues/1308/. I wonder if Beluga and mestaritonttu is the same person)

Ryan says you can use fieldset for grouping on the frontend, diogo says you can't. Could you please clear things out: сan I get all fields within a fieldset via API from the frontend? If so, how?

I think all pages in admin have template=admin.

This new feature makes using modules for hooks obsolete in many cases. The module folder will be a lot cleaner!

Yes, there is another topic on this bug.

@Mike: Can't get your solution to work. The other redirects are running as they should, but this one does not even trigger the module (I turned the debug mode on). Tried it on localhost in subfolder and on a subdomain on a live server if that matters.

It works, thank you!