Leaderboard

There's a little bit of trickery involved when adding back a "save unpublished" button for user pages as InputfieldPassword has its own little piece of logic that sets itself to required when processing input for an unpublished page, but here's a quick-n-dirty attempt at a module.

We already check for correct filetypes (imageformats) before processing images. We use PHPs function getimagesize(), what internally uses this magic-byte-check for format detection, I assume. But will check this further. EDIT: Yes they do: https://github.com/php/php-src/blob/1c295d4a9ac78fcc2f77d6695987598bb7abcb83/ext/standard/image.c#L41 https://github.com/php/php-src/blob/1c295d4a9ac78fcc2f77d6695987598bb7abcb83/ext/standard/image.c#L1246

First off: listen to BitPoet You want a different templates folder all together? Try this to use different templates folder. (hint)

Major vulnerability, doesn't seem to have a patch yet.. http://arstechnica.com/security/2016/05/easily-exploited-bug-exposes-huge-number-of-sites-to-code-execution-attacks/

Are you sure you want this? If you do, you'll have to define for yourself what makes a browser a "mobile" device. Nowadays, neither UserAgent-sniffing nor screen resolution or touch feature testing alone are enough as a sorting criterion. Any libraries I've seen out there use a mix of all those, and they need constant updating as browsers change their features and mobile devices grow larger screens. A lot of laptops support touch now too, but you don't want to serve the mobile version to a 4k-displayed ChromeOS notebook just because the browser window doesn't take up the full screen width at the moment it visits your page. I'd call successful separation of regular and mobile devices a science for its complicatedness, but for a science, it's far too imprecise. If you decide to go down that path anyway, there are a number of libraries out there, just googling "Javascript detect mobile browser" gives me quite the list. You'll have to decide yourself which version supports the features you regard as distinctive. I'd then use a JS popup to let the user decide if they want to go mobile or stay on the main site, add mobile/full version links on every page and add another site directory for m.mydomain.com with the mobile templates and auxiliary files.

Hi, if you define your buttons in a generic way from your dashboard template like: <button class="pwbutton" data-pid="123" data-change="publish"...> <button class="pwbutton" data-pid="123" data-change="unpublish"...> <button class="pwbutton" data-pid="456" data-change="publish"...> Then you should be able to handle the ajax as follows (untested): $('.pwbutton').click(function(){ $.get( '/change-status', { pid: $(this).data('pid'), change: $(this).data('change') }, function() { alert( "success" ); //e.g. update page status on dashboard }).fail(function() { alert( "error" ); //e.g. error message }); }); Ideally the /change-status template should be aware of the ajax request and respone with infromation you need to update your dashboard accordingly. Hope this helps to get you started. Maybe also take a look at the jQuery documentation to understand whats happening: jQuery.click() jQuery.get() Greetings

Nice one. I also employed a little trickery in my EmailNewUser module, although I took a slightly different approach. $this->addHookBefore('InputfieldPassword::processInput', $this, 'removeRequired'); public function removeRequired(HookEvent $event) { $event->object->required = false; //hack to remove required status so that automatically generated password can be added on save }

Sort order isn't really part of the character set, it's decided by the accompanying collation. Currently, PW doesn't set this explicitly, which means it defaults to the default setting of the database (as far as that is applicable to the individual table's character set). Changing the charset to a single-byte one is not advisable nowadays, but you shouldn't need to anyway. Simply set your database's collation to utf8_swedish_ci before you install PW. ALTER DATABASE whateveryounamedit CHARACTER SET utf8 COLLATE utf8_swedish_ci; After that, any newly created tables with utf8 charset follow the Swedish sorting and substitution rules.

Thanks @mr-fan, I'm familiar with that thread and I am activating users via an email link. But in principle I think unpublished/published users is the ideal way to have users in an inactive/active state. That's what the published status of a page is for, so it shouldn't be necessary to add a new field for the same purpose. And it also has the benefit of preventing login and view access for unvalidated user accounts without the need for additional logic in login functions and page templates.

First of all $input->get->s is basically the same as $_GET['s'], but without having the whole checking if the array key is actually set (isset …) mess. Secondly you're giving anyone the possibility to apply any changes your code is creating to any page in your system, which isn't great. You should make sure only applicable pages are selected in your $pages->get() call by adding additional selectors (at least disable all admin pages with 'parent!=2'). And lastly you should check if you successfully found a valid page before doing anything else.

Found Spectre.css framework during I searched the web... could be interesting, so I post it here. Spectre.css is a lightweight, responsive and modern CSS framework for faster and extensible development. lightweight and clean starting point for your project and prototype flexbox, responsive and mobile-friendly layout carefully designed elements built in useful components and utilities patterns and html templates soon email templates soon URL: http://picturepan2.github.io/spectre/

Users are pages, but in the Users section of the admin there isn't the same support for unpublished users as for unpublished pages. When users register on the frontend I set their status to unpublished until their email address is validated (thanks to a suggestion in the forums from Soma). But while users are unpublished it isn't possible to make edits to their profile via admin because there is no "Save and keep unpublished" button like there is for other pages. To save changes in admin the user must become published. Also, there is no ability to unpublish a user from admin. This would be a useful option if a user account needs to be suspended rather than deleted. Edit: another small thing that would be nice to have is for the user list to honour the useHoverActions config preference for PageList. I keep hovering on the user list and then I remember I have to click the name to get the flyout links.

I know this thread is old, but happened to notice someone browsing it today so I thought I should "close" this now that the Users page in the admin uses the Lister interface which makes it very easy to search and sort users.

No, I don't think it is the correct/desirable behaviour, but I thought it might explain why it was happening. That is correct - it should match an empty checkbox.

To be honest, I never came across that particular thread in all of my searching, but I will definitely comment about the issue. I am currently using 3.0.15 in my staging and production environments.

Just wondering, why are you against (or just not going to use) using media queries to handle the sites layout? I feel it would save you all the extra work and would be easier from the start.

Seems like this feature is still missing (in repeater, reperater Matrix and PageTable as well). I think It would be very usefull to have both min and max amount for them. Hope It will be implemented.

Yes! SOLVED This is what I was looking for, quite obvious! But thanks alot // update password field attributes in a login or registration form $passwordField = $fu->form->get("password"); $passwordField->label = "New password label"; $passwordField->description = "Password description";

Interesting discussion here.

I don't think this step is necessary. Checking the page source of the Edit Page screen to see the rendered CKEditor config is revealing. For your CKEditor field: Edit Field > Input > Plugins > Remove Plugins Delete 'magicline' if it is shown here.

Also this page tracks the problem and will eventually contain patches: https://imagetragick.com

Sorry, it just occurred to me that that was a rather useless answer You'll probably want to make use of the API and do something like this: $p = $pages->get("page to alter"); $p->addStatus(Page::statusUnpublished); $p->save(); You could put this inside a conditional that checks that the user has the correct role/permission. You may also want to do it based on the passing of a get or post variable so it can be part of your existing template file. Hopefully that will get you started but let us know if you have any specific implementation questions.

Hi Zeka, Removing these lines and I got the module running on 3.0.x.

It sounds like you are assuming that the file compiler works like a cache converting the values of these variables into hard values at the time of compilation? As LK and ryan mention, this is not the case - the file compiler is really just for dealing with Namespace issues (although it can be used for other things like tags compiling). The key thing is that the resulting file is still all php with variables intact.

You could go with a activation link via email - so you can simple validate new users and set them activ via a email link...or in the backend and by setting activate_user to sero...or go with two different roles user_active and user_pending....you have multiple options to implement a comfortable managment via Lister pro or something else... link for a really good activation solution: https://processwire.com/talk/topic/4066-activate-user-account-via-email/ regards mr-fan

$rf = "repeater_field"; //repeater field name $pt = "basic-page"; //page template name foreach($p->$rf as $r){ $np = new Page(); $np->of(false); $np->template = $pt; $np->parent = $page; foreach($r->fields as $f){ $np->$f = $r->$f; } $np->save(); }

Also try Autocomplete which only fetches the populated pages instead of the whole list. This speeds things up too.

You could try to use the new ajax-driven inputs (more on that here). Basically you can tell Processwire to delay loading of some specific inputs (or groups of inputs) until they are opened/selected. Worth a try in your case. Let me know

Thanks, Peter. I just tried doing this and found the cause of the problem. The transactionreference field causes the server to timeout because it is a page field that has >5000 possible pages to be selected. I'm guessing this happens while the pageedit process is trying to populate the select input for the field. What's the best input choice/setting for something like this? Thanks again.

There's no difference in how you would use $session, $input, or any API variable or any PHP superglobal ($_GET, $_POST, etc). These have nothing to do with namespace. If you must disable the template compiler, edit your /site/config.php and add $config->templateCompile = false; to it. That will prevent any of your template files from getting compiled. As for compiling modules: At this time I wouldn't recommend disabling the module compiler, otherwise almost no 3rd party modules will work. That's because there are few if any PW3-specific modules at present. If you come across a module that isn't working after being compiled, let me know about it so I can investigate it. When it comes to template files (and you've disabled the template compiler): you don't need to add a namespace to all of them. You only need to add it to those that are calling ProcessWire specific functions like the wire() function, or those that are referring to ProcessWire constants or classes directly. Things like this: $foo = new PageArray(); $date = wireDate('Ymd'); $page->addStatus(Page::statusUnpublished); The parts in bold above are those that are referring to things in the ProcessWire namespace. Adding "namespace ProcessWire;" to the top of the file makes it simple, that's all you'd have to do. If you didn't want to do that, you could also just update a wire() function call to be like this: $date = \ProcessWire\wireDate('Ymd'); Or you could just enable the template compiler, which will do this for you. However, maybe you aren't using things like the wireDate() or wire() functions and maybe you aren't referring to things like Page::statusUnpublished. If that's the case, you can skip adding a namespace at all, and likewise don't need the compiler. ProcessWire's API variables like $pages and $input and $session and all of that are going to be present either way. These have nothing to do with namespace.

Last week I mentioned we'd be continuing the documentation updates into this week and that's exactly what we did. All in all, these documentation updates involved 46 files and 5264 additions, so far. Read more about it in this weeks' blog post: https://processwire.com/blog/posts/processwire-3.0.16-continues-expanding-documentation-and-more/

Maybe this is related to your issue with repeaters: https://github.com/ryancramerdesign/ProcessWire/issues/1790#issuecomment-214017864

Is this feature still planned for future addition or did I miss something?

yeah but a little api magic can cure that.. open up your tools or api playground and: $pp = $pages->get(1234); // page you're adding the children to the page table foreach($pp->children as $child) { $pp->page_table_field->add($child); }

This is put together very quickly, but should work ok. If the user is logged in, but they don't have page-edit permission, and they try to load any page with the admin template, they will be redirected to the site's homepage. Of course you can tweak these as needed. <?php class HideBackend extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Hide Backend', 'summary' => 'Redirect guest user from backend admin back to site\'s homepage.', 'href' => '', 'version' => 1, 'permanent' => false, 'autoload' => 'template=admin', 'singular' => true, ); } public function init() { if($this->user->isLoggedin() && !$this->user->hasPermission("page-edit")) { $this->addHookAfter('Page::render', $this, 'redirect'); } } public function redirect(HookEvent $event) { if($this->page->template == "admin") { $this->session->redirect("/"); } } }

Table Use this for tabular data, like rate tables or other things that you might typically represent in a spreadsheet. Use it for situations where you don't need the full-blown flexibility of repeaters, as it's technically more efficient with far less overhead than repeaters. Something like the Events Fieldtype could be very easily re-created via a Table field, but the potential uses are far broader. But for the most part, think tabular data when it comes to the Table field. Multipliers This is good for when you need a range of values (whether text, textarea, numbers, dates, etc.). If you are using repeaters with just one field in them, you might be a lot better off with a Multiplier. Like the Table field, Multipliers are very efficient and low overhead relative to something like Repeaters. Use Multipliers when you need to repeat a single input multiple times, optionally with a min and max number of inputs. Lets say you are building an employee directory, and each employee has between 1 and 3 email addresses. Rather than using 3 separate email fields, you would use 1 multiplier field and specify min=1 and max=3. Repeaters These are infinitely flexible in terms of what they represent, but each row of values is technically a page in the system. As a result, with the flexibility comes significant overhead. This is really only an issue when the quantity of repeater items gets high, or when you have lots (thousands) of pages using repeaters. I recommend repeaters for setting up things like homepage carousels. For example, if you go to the Villas of Distinction homepage, there are 3 separate repeaters in use on that page, each holding a photo, title, description, link. The client can have as many items in each of those sections as they want. Currently it looks like the first repeater as 6 items, the 2nd has 2, and the 3rd has 6. The possibilities of what can be represented with repeaters is endless, but look for potential alternatives when dealing with large quantities (whether large quantities of repeater items, or large quantities of pages using repeaters). PageTable This is one of the ProFields that is available for free (thanks to Avoine sponsorship) on the ProcessWire dev branch. Meaning, it'll be available for everyone to use as part of the core in ProcessWire 2.5. And you can use it now if you don't mind running the dev branch. PageTable has all the flexibility of repeaters, but with lower overhead from the admin/input perspective. Rather than trying to bundle all the inputs on one screen, PageTable shows you a table of items and you click on the item to edit it in a modal window. This enables it to be a lot more efficient from the admin UI perspective. It's also more flexible than repeaters are in terms of where you store your items. PageTable lets you choose where they should live, whether as children of the page being edited, or as children of some other parent page you designate. They might be a little more work to setup than repeaters, but I think that most situations where you need the flexibility of repeaters may be better served by PageTable. PageTable still can't compete with the speed and efficiency of Table or Multiplier, but consider using PageTable anywhere that you might have used Repeaters before. Repeaters and PageTable are fundamentally different from the admin UI/input perspective, so you'd want to compare them yourself to see what suits your individual input needs better. PageTable involves more clicking to create and edit items, making Repeaters potentially faster for entering data rapidly. But PageTable will scale much further in the admin UI than Repeaters will, so I would personally favor PageTable in more situations than Repeaters.

The prefered, simpler way is to make the user when created via API unpublished: $user->addStatus(Page::statusUnpublished); See cheatsheet addStatus Then the user can't login yet. And the admin can just go and publish the user (same as with pages) in the admin. Users are pages so the page API applies here same way as it is for pages. Or using API to publish $user->removeStatus(Page::statusUnpublished); See cheatsheet removeStatus The different system flags are also on the cheatsheet.