kongondo

Have a look at these threads. Could be htaccess, could a be a language issue, etc. Ssorry, in a rush.

Thanks for the update @adrian For a task like this (wanting to check the a client's access RE a specific page), I'm thinking it would be more useful to actually see the permissions of that client in respect of the said page, rather than scrolling through a potentially long list of all roles (e.g. a large site). The difficulty I see is, obviously, the said client is not logged in when the admin is checking out the status ;-), so this may be wishful thinking. Just wondering... Could the colours please, somewhere, match the current colour scheme of the other panels? I'm 50/50 on this. If I was able to view a page, put a clients name or id in an input and Tracy returns the permission panel, I wouldn't mind it being separate. Just my 2p.

Welcome to the forums @Orodreth, In the long run, you are better off including the resources you need in the frontend either from a CDN or ones you've downloaded locally (to you /site/templates/ folder, for instance. For example, in the case of jQuery, the current version used in ProcessWire core is 1.11.1. The file is named jquery-1.11.1.js. If ProcessWire moves to a later version of jQuery in the future, your code will break since the name of that file will change. To get jQuery from a CDN ,go here or here, for instance. For UI Kit, that's here. However, if you still wish to use the ones that ship with ProcessWire: $config->urls->JqueryCore;// /wire/modules/Jquery/JqueryCore/ $config->urls->AdminThemeUikit;// /wire/modules/AdminTheme/AdminThemeUikit/ Append the rest of the respective paths/filenames to the above, e.g. <script type="text/javascript" src="<?php echo $config->urls->JqueryCore;?>jquery-1.11.1.js"></script>

Looks good! ?

Welcome to the forums @mjut You need to use $config->scripts->add() for JS and $config->styles->add() for CSS .These need to be added before the controller.php $config->scripts->add($config->urls->templates . "scripts/admin.js"); $config->styles->add($config->urls->templates . "styles/admin.css"); // this comes last require($config->paths->adminTemplates . 'controller.php');

Sounds like you just need a form. OK, even a 'financial stuff shop' is just forms. I am assuming you are not taking payment with the orders (hence the without the financial stuff). On the frontend, at its simplest, depending on the number of products you have, you create a dropdown list (like an asm select) of products. The label is the product name/title, the value is the product (page) ID. A user selects a product, and it is added to a list or table below the dropdown using JavaScript (like jQuery). To get a bit fancy, you then disable that item in the dropdown list. Assuming you were using a table, each row is a unique product, The table can have several columns, one for title, one for a product description, one with an input for quantity, and one with a delete button/x plus a hidden input for product ID, etc. If an item is removed from the table (JavaScript), you delete the row and re-enable its selection in the dropdown. I am assuming you will at least be collecting the customer's email, so create an input for that. Create a submit button as well. When the submit button is pressed, we use JavaScript (simple using jQuery), to process the form. If there are no products selected, just return an error. If there are products, at the very least we want to send the product ID, its matching quantity and the customer's email. We use JavaScript to serialise these and submit the form. Server-side, you validate and sanitize the data. Product ID and quantities are just integers. You then do what you need to do....thank yous, create a record of the order, redirect, etc.

I'm not sure I follow. Doesn't that mean that every time the snippet is used, it will add the type hints? Doesn't that mean, if I use the variable again within the same code, the type hint will be printed out again? I'm sure am missing something here, please clarify/show me an example pseudo code ?

Welcome to the forums @Spiria. It could be a cache issue. Have a look here: This too may be of interest:

A descriptive name sometimes helps when searching the modules directory, me thinks... :-).

What!? That's nasty man. Sorry to hear that. Hope it's nothing more than the antibiotics can handle and hope you feel better soon. Cat stays? (thinking of the kids here as well).

Aah. Thanks. I'm too lazy though. Auto close doesn't require me to press tab :-). Btw, auto close changes the matching tag if the opening tag is edited. If I have a <span> and want to change it to a div, I just type over/edit the span and the matching closing span tag will be changed to a </div> (but it fails sometimes). Not sure emmet can do that.

Interesting thought. Maybe a notice similar to when one is editing the same page in two or more places.

I didn't read that, sorry. Now, that I have, the discussion you are referring to, whilst related, is somewhat different, I think. That discussion was a bug/issue report. The issue is about Page Reference fields themselves, behaving in an unusual way...etc. The present issue, IMHO, is a not about the behaviour of page reference fields, but about pages referenced in those fields, specifically, whether they should be deletable or not. I think the present issue is not a bug report but a feature request. Namely, similar to locked items in the tree and in page edit, a trash icon/delete button(or link) should not be visible for referenced pages. In the API, one should not be able to delete such pages as well, unless they pass some flag...(my thought). What do you think?

Makes sense. File a feature request ?

I've gone back to using Auto Close tag extension as emmet only works with HTML files. It doesn't work with HTML inside PHP files. It's not auto-closing for me...

I'm not. All work as expected (kb+enter; kb+tab; mouse select). No errors in console. Win7, Chrome

Then you have to hook into something. If you want that referenced categories not to display the trash link, then you can hook into the tree render. Or, if you don't mind the display of the trash page link, then you can hook before pages::deleteReady. Alternatively, depending on who is administering the site, you can lock all your category pages and only unlock one you want to delete, at delete time :-). You can check if it is being referenced in a page field by going to the settings tab when editing the category page and scroll to 'What pages point to this one' section.

Try (untested) $myCategoryPage = $pages->get('/path/to/an/example/category/page/); // if the category page is not referenced in a page reference field if(!$myCategoryPage->numReferences) { // safe to delete $pages->trash($myCategoryPage); } http://processwire.com/api/ref/page/ ps: if it doesn't work, try $myCategoryPage->numReferencing instead. I get confused which is which :-). Please report which one worked for you, thanks.

I was replying as your reply came in :-). Yes, that is the issue. Is there any reason your discount page titles would be empty? I mean, would the selector still work without adding the title!=''?

Great, thanks for sharing! A little comment, if I may. Reading your original post (and to some extent the blog post), I got confused by what you meant by property. On the one hand, it seemed to refer to property in a OOP sense since you also talked of objects. It also seemed to refer to an actual physical property since you refer to a 'room' :-). My German is not great, so that didn't help :-). Reading the blog post, it also seems by property you mean an option in a select? Maybe you could clarify this and use options instead if that is what you mean? Thanks again!

Looks OK. It's good to exit/halt() after echoing the JSON. Either of these (although halt() may be preferable in some cases). if($config->ajax) { echo $couponsJSON; return $this->halt(); // OR // exit; }

I'm pretty sure it's CKEditor doing that and not sanitizer->textarea(); Maybe this will help?

You should be able to do this for superusers only, if you need to :-); Read from here onward.

At the earliest opportunity possible when it hits the server. This means in the function, or an intermediary function first, which then passes the clean data to the function that creates the post. If the data does not pass the sanitise process, we redirect back to the form. The form can do client-side validation, e.g. was the email input filled, does that look like an email, etc?

Ah. I thought you were doing your own implementation.