Ivan Gretsky

Hey, Mike! I am not sure if this is related to some other things we talked about before, but anyway... With jumplinks site.com/index.php gerts redirected to site.com. But site.com/index.php/something gets redirected to site.com/index.php.pwpj/something with 301 answer code. Is there a way to make it throw 404 instead?

I also think it could be cool to manage PW versions with composer update command. But I think I saw Ryan write somewhere in the forums he will not split the codebase into separate repos. So I do not think we will be as easy to go as just updating composer.json.

Ah! You are talking about the Admin page! I thought anything named "processwire" is hidden. Tried it out - it is not. I always rename the admin root, so have almost forgotten it is 'processwire' by default . So no miracles here. Same thing as LostKobrakai pointed out.

Wow! Another option! We discussed something similar here. But processwire is not in that systemIDs array. The search in all files from ProcessPageList module for "processwire" did not get me anywhere either. What is the source of that magic? And just like Cerulean I would like to hide branches like that without hooks any modules. Though hooks and modules do exist.

Sure! I agree this type of thing should be in the core. Did you make an issue or a pull request on github? I think this way we will have more chance.

@kixe: Why did this module not make it to the module directory?

Thanks, Martijn! I had a personal conversation with Adrian about this module. There are reasons that it is not in the module directory yet. They are discussed here: https://github.com/ryancramerdesign/ProcessWire/issues/302 and later in that thread https://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/page-2#entry84916 I think core admin-view permission support on a page basic is something we can benefit from customizing admin interfaces for editors. That's why I was so interested to find out about the mechanism used for hiding 404 page revealed to me by LostKobrakai.

Good day! I am having a problem while upgrading from 2.6.8 to 2.7.2 (Windows, XAMPP). I have made it before on the same site, but now it does not work. Actually I can exen see the unpacked files and folders in the root directory, but I still get this error. Please help! ProcessWire: ProcessWireUpgrade: Unable to locate ZIP: C:/xampp/htdocs/xyz/site/assets/cache/ProcessWireUpgrade/master.zip DEBUG MODE BACKTRACE ($config->debug == true): #0 C:\xampp\htdocs\xyz\wire\core\ProcessController.php(236): ProcessWireUpgrade->executePrepare() #1 [internal function]: ProcessController->___execute() #2 C:\xampp\htdocs\xyz\wire\core\Wire.php(397): call_user_func_array(Array, Array) #3 C:\xampp\htdocs\xyz\wire\core\Wire.php(332): Wire->runHooks('execute', Array) #4 C:\xampp\htdocs\xyz\wire\core\admin.php(93): Wire->__call('execute', Array) #5 C:\xampp\htdocs\xyz\wire\core\admin.php(93): ProcessController->execute() #6 C:\xampp\htdocs\xyz\wire\modules\AdminTheme\AdminThemeDefault\controller.php(13): require('C:\xampp\htdocs...') #7 C:\xampp\htdocs\xyz\site\templates\admin.php(15): require('C:\xampp\htdocs...') #8 C:\xampp\htdocs\xyz\wire\core\TemplateFile.php(182): require('C:\xampp\htdocs...') #9 [internal function]: TemplateFile->___render() #10 C:\xampp\htdocs\xyz\wire\core\Wire.php(397): call_user_func_array(Array, Array) #11 C:\xampp\htdocs\xyz\wire\core\Wire.php(332): Wire->runHooks('render', Array) #12 C:\xampp\htdocs\xyz\wire\modules\PageRender.module(422): Wire->__call('render', Array) #13 C:\xampp\htdocs\xyz\wire\modules\PageRender.module(422): TemplateFile->render() #14 [internal function]: PageRender->___renderPage(Object(HookEvent)) #15 C:\xampp\htdocs\xyz\wire\core\Wire.php(397): call_user_func_array(Array, Array) #16 C:\xampp\htdocs\xyz\wire\core\Wire.php(332): Wire->runHooks('renderPage', Array) #17 C:\xampp\htdocs\xyz\wire\core\Wire.php(458): Wire->__call('renderPage', Array) #18 C:\xampp\htdocs\xyz\wire\core\Wire.php(458): PageRender->renderPage(Object(HookEvent)) #19 C:\xampp\htdocs\xyz\wire\core\Wire.php(332): Wire->runHooks('render', Array) #20 C:\xampp\htdocs\xyz\wire\modules\Process\ProcessPageView.module(187): Wire->__call('render', Array) #21 C:\xampp\htdocs\xyz\wire\modules\Process\ProcessPageView.module(187): Page->render() #22 [internal function]: ProcessPageView->___execute(true) #23 C:\xampp\htdocs\xyz\wire\core\Wire.php(397): call_user_func_array(Array, Array) #24 C:\xampp\htdocs\xyz\wire\core\Wire.php(332): Wire->runHooks('execute', Array) #25 C:\xampp\htdocs\xyz\index.php(241): Wire->__call('execute', Array) #26 C:\xampp\htdocs\xyz\index.php(241): ProcessPageView->execute(true) #27 {main}

I noticed that a user with limited permissions (page-view and page-edit) cannot see the "404 Not Found" page in the tree. How is that? The template of that page is "basic-page", so no restrictions on template level. I am really interested, because I wouuld like to find a way to hide pages in that built-in manner. For example, I would like to hide my FormBuilder page. Do you have any ideas how does it work?

This is what I've been thinking about. There are things like .htaccess that go to root but are still closely related to a project. On the other side there may be more than one template folders in one site directory with some different design... I guess I am still thinking in a "installable template" kind of way. Camilo is talking about something different - code organization in templates folder - but it was an amazing read. I am using a quite a similar pattern.

This is what first comes to mind.

Good day everyone! There was some talk about using frontend development technologies like node and gulp and bower with PW. I actually started to incorporate them in my workflow on the latest projects. But I did not make a conscious decision on where to put the root of all my frontend dev ops in the PW folder structure. My first intention was to put my package.json, gulpfile.js and bower.json in the templates folder. Jonathan Lahijani suggested doing so in his epic video. So I've done. But it always looked messy to have node_modules, bower_components, .sass-cache and all the little .json files in there. But now I have a bigger problem - all those files seem to cause errors when running "Translate files" in languages. So I decided to rethink this. Do I really have to put all that stuff in templates folder? Should I put them in site or even in the root folder? That are benefits and downsides of each option? Are there any possible collisions in multisite installations? I ask you to share your experience and thoughts on the topic.

@elabx:I found this answer for you. Guess It all makes no sense without ssh.

I am yet trying to encorporate this in my workflow, but deployer seems to be valid alternative to capistrano. And it is in PHP, so no need for Ruby. The developer is Russian, so that gives me a little pride. A lot of Capistrano maintainers are also my fellow contrymen - just to point that we not only bomb and confront . @pwired: There seems to be a web interface to deployer too. You can see it on the frontpage of offsite and the source is on github/ At least i think I saw it there.

Ahh! Got it! You need an admin interface to easilly manage those guestbook submissions. 1) BernhardB's listerpro suggestion is what you want to go for if you have the option to use this paid module. It is really powerfull. 2) You could build a process module to list all guestbook submission for free, but you need to get your hands dirty with code . You can take a look at something like this for an inspiration: class GuestBook extends Process { public function init() { parent::init(); // always remember to call the parent init } public function execute() { $out = ''; $table = $this->modules->get("MarkupAdminDataTable"); // Table header $table->headerRow( ["Name of submission", "By whom...", ...] ); // Selector to get all your guestbook submissions $listing = $this->pages->find("..."); foreach ($listing as $page) { $data = array( // A td with the link to edit the page (you need to change the ... part) $page->title => $this->config->urls->admin . ".../edit/?id=" . $page->id, $page->created_by, ... ); $table->row($data); } $out .= $table->render(); $pagination = $listing->renderPager(); $out .= $pagination; return $out; } public function executeEdit() { // Write code to edit submission } // ... }

Sorry, but I could not understand what you are questioning about. Could you please try to rephrase and be more specific?

I am not sure that I understand what you are trying to achieve. Why do you want to sanitize $this->pages->get("template=location, title=$lpTitle")? It is not a user input and will return a Page or NullPage anyway. No commas . If you need to get the id just use $this->pages->get("template=location, title=$lpTitle")->id. The notice you are getting is from ProcessXMLImport module and is not directly connected with the code you presented.

Maybe this can help you to start off?

I think it is more reasonable to compare PW+Padloper||Snipcart||... not with Magento or WooCommerce, which are well established and feature rich but less configurable systems, but with Drupal+Commerce module. Drupal8 is out (with much more fanfares than PW 2.7 ) and Drupal Commerse 2 is on its way to stable. For now it seems like we are not quite ready to compete with either, at least in the field of achieved. I think that can change as first Padloper projects will appear showing its true capabilities and as Antti releases his so long-waited shop profile.

Nice and clean! A few things... (isn't that what you are after ) 1) On mobile hamburger menu on-hover cursor should be pointer. 2) On the blog page there is no current state for pagination.

Taking a look at this it seems like you can achieve what you need. Did you try it in latest version?

I am using HeidiSQL too and like it just like kongondo. But I believe the question was about the use of a remote database with a localhost installation (of a PW, probably?) So you could just copy or git clone your site and start working not even changing the db in the config.php? If so, I would say having your own MySQL is cheaper for someone already having some kind of db hosting. But you have to set up SSH port forwarding to access your remote db (which scares me as (yet) windows user) or lower the security by allowing the access to it not only from localhost. As I could understand Google SQL is the same MySQL but with some restrictions. I do not know their benefits, so would probably go with my own MySQL instance.

If you only want to prevent saving the current field, you probably could modify the code above to be hooked before FieldtypeMulti::savePageField and add something like this in the end: if($page->your-field == "now-value" && $pageBeforeChange->your-field == "before-value") { $event->replace = true; } This should replace the whole FieldtypeMulti::savePageField and prevent the field from being saved. Not tested. No guarantees .

@LostKobrakai: But Pages::savedField does have different arguments to Pages::saved. So you would probably have to write different code for the hook functions? @valan: I managed to solve similar task hooking FieldtypeMulti::savePageField. This works for something derived from FieldtypeMulti. To hook fieldtypes extending Fieldtype class you can hook Fieldtype::savePageField. Here is the code: public function init() { $this->addHookBefore('FieldtypeMulti::savePageField', $this, 'saveFieldtypeMulti'); } public function saveFieldtypeMulti($event) { // Get current page and field $page = $event->arguments[0]; $field = $event->arguments[1]; // Perform all the check to execute only when needed if ($page->template != 'your-template') return; if ($field->name != 'your-field') return; // Get the instance of the page from db as it was before the edit session. $pageBeforeChange = $this->wire('pages')->getById($page->id, array( 'cache' => false, 'getFromCache' => false, 'getOne' => true, )); if($page->your-field == "now-value" && $pageBeforeChange->your-field == "before-value") { /* send email */ } } This should work whether you save the page or just the field.

I guess not. If it is something like Pages::saveReady, it is only called on $page->save() but not on $page->save($field, $value).