Leaderboard
Popular Content
Showing content with the highest reputation on 05/08/2012 in all areas
-
Hi guys, I've made a big update to original Futura admin theme, this one is based on Futura Remixed code (completly rewrote the code with that one). I've included some tweaks based on posts by netcarver, alan & Adamkiss. Back to top button is located in the sidebar, sidebar moves quicker then before up & down and I've fixed the main menu. Screens: Download: https://github.com/nvidoni/futura futura-admin-theme-v1.1.zip4 points
-
I was able to duplicate this. The problem was the recently introduced version numbers that are appended to $config->scripts (and $config->styles). InputfieldImage manually adds InputfieldFile.js to $config->scripts, as it always has. But it knows nothing about version numbers. The result was that if you had both a file and an image field on the same template, the same InputfieldFile.js would get included twice (one with version number, one without). All that JS in InputfiledFile.js would also execute twice when you dragged in a file. Thanks for finding this bug--I just committed a fix for this. I don't want to have to append version numbers ever time I manually add a script/style from a module, so I setup PW to ensure uniqueness of these at the time they are added (regardless of version number). I'm not yet sure why the display thumbnails option would make a difference here, but will experiment more. Please let me know if you find any issues remain. Thanks, Ryan2 points
-
Hi and welcome! There is a type of field, "fieldsetTypeOpen" that allows you to do this. Just create a field of this type (first screenshot), with the name that you want for your tab. This will create two new fields on the "Add Field" dropdown of your templates "fieldname" and "fieldname_END", that you can drag to the field list to group the other fields in tabs (second screenshot).
2 points -
Ryan, Thanks this gave me a great place to start. I thought I'd share the version I created in case anyone finds it useful. • Single template for the login/logout. • Automatically redirects the user back to whatever page they originally requested after they login. ./includes/login.php <?php // Handle logouts if($input->get->logout == 1) { $session->logout(); $session->redirect($page->path); } // If they aren't logged in, then show the login form if(!$user->isLoggedin()){ // check for login before outputting markup if($input->post->user && $input->post->pass) { $user = $sanitizer->username($input->post->user); $pass = $input->post->pass; if($session->login($user, $pass)) { // login successful $session->redirect($page->path); } else { $session->login_error = 'Login Failed. Please try again, or use the forgot password link below.'; } } ?> <!DOCTYPE HTML> <html lang="en"> <head> <title>Custom PW Login</title> </head> <body> <form action='./' method='post'> <div class="login"> <? if($input->post->user && $input->post->pass) { echo "<p class='error'>" . $session->login_error . "</p>"; }?> <p><input type='text' id="user" name='user' placeholder='Username'/></p> <p><input type='password' id="pass" name='pass' placeholder="Password" /></p> <p><input type='submit' class="btn" name='submit' value='Login' /></p> </div> </form> </body> </html> <? die(); // don't go any further if not logged in } // end !logged in ?> In any template you wish to protect: <? require("./includes/login.php");?> To trigger a logout: <a href="?logout=1">Logout</a> Note: I'm using the HTML5 placeholder attribute. Browser support is not 100%. You may want to use labels instead, or use some jQuery (like I did) to add the placeholder text for browser that don't support it. SideNote: How do you get code indents to stick when posting? I'm having to go back and add spaces to each line. I use tabs when coding.2 points
-
What does autojoin do? Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. What sites should use autojoin? Autojoin is most applicable with larger sites. On smaller sites, there may be no benefit to using it or not using it. But it's good to know what it's for regardless. Where do you control autojoin? Autojoin is controlled per-field. You can turn it on by editing each field under Setup > Fields > [your field], and you'll see it under the 'Advanced' heading. When should you use autojoin? Autojoin causes the field's data to be loaded automatically with the page, whether you use it or not. This is an optimization for fields that you know will be used most of the time. Fields having their data loaded with the page can increase performance because ProcessWire grabs that data in the same query that it grabs the Page. Autojoin is a benefit for fields that are always used with the Page. This is best explained by an example. Lets say that you have a template for individual news stories called news_story. The news_story template has these fields: title date summary body sidebar We'll assume that when you view a page using the news_story template, all of the fields above are displayed. Fields that should have autojoin ON: Now consider a separate news_index template that displays ALL of the news stories together and links to them. But it only displays these fields from each news story: title* date summary In this case, the 3 fields above would be good to autojoin since they are used on both the news_index and news_story templates. If your title, date and summary fields didn't have autojoin turned on, then ProcessWire wouldn't go retrieve the value from the database until you asked for it it (via $page->summary, for example). Because the news_index template displays all the stories at once, and always uses the title, date and summary fields, it will perform better with title, date and summary having autojoin ON than with it OFF. In this case, it reduces the query load of the news_index template by 3 for each news story. To take that further, if it were displaying 20 news stories, that would mean 60 fewer queries, which could be significant. Fields that should have autojoin OFF: Now lets consider the body and sidebar fields, which are only used on the news_story template: body sidebar It would be desirable to leave autojoin OFF on those fields because there is no reason for the body and sidebar to be taking up space in memory when they are never used on the news_index template. While it might mean 2 fewer queries to view a news story, that is not significant and certainly not a worthwhile tradeoff for the increased memory footprint on the news_index template. Keeping autojoin OFF reduces a page's memory footprint. Conclusion Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. But if your situation doesn't involve lots of pages or data, then you don't need to consider autojoin at all (and can generally just leave it off). Additional Notes Not all fields have autojoin capability. You won't see the option listed on fields that don't have the capability. *The title field has autojoin on by default, so you don't need to consider that one. It was included in the examples above because I thought it's omission might cause more confusion than it's inclusion. Be careful with multi-value fields that offer autojoin capability (page references and images, for example). Because MySQL limits the combined length of multiple values returned from a group in 1 query, autojoin will fail on multi-value fields that contain lots of values (combined length exceeding 1024 characters). If you experience strange behavior from a multi-value field that has autojoin ON, turn it OFF. If you want to play it safe, then don't use autojoin on multi-value fields like page references and images.1 point
-
I recently updated to latest PW and it seems to have introduced one bug: when drag 'n dropping files it doubles the file and starts immediately two upload bars. I tried to figure out which is causing this behavior, but couldn't figure out.1 point
-
Hi all, Following on from this thread: http://processwire.c...st-image-label/ I'd like to sponsor a module that gives me (and any PW user too) the option to display image thumbnails in the page list. I know you can specify which fields to display in the page list in Templates > Advanced. Because I do a bit of work for artists this would be great option for me (and probably others) to have. I'd like it to work with Antti's Thumbnails module too. Please get in touch if you're interested: martin@smd.net.au Regards Marty1 point
-
Here it is a first test version. Got it working with regular image fields, or thumbnail cropimages fields. You can specify any image field using the image field name in the advanced template setting for page label. To output an thumbnail (from the Thumbnail module) just use the dot notation. fieldname.thumbnailname (as specified in the thumbnail field settings) There's some option on this module for controlling the size of image and the container size, padding, colors. https://github.com/s...eListImageLabel Edit: Added support for multiple image fields. It will always take the first image.1 point
-
Hi Ryan, Nice catch. Yeah, no sense setting a session variable after the redirect. That entire if/else had a bunch of stuff I was commenting in/out while I was testing, I did a poor job of cleanup. I updated my code above, so it's correct for anyone that uses it.1 point
-
Thanks for posting Renobird. I'm confused on this section: if($session->login($user, $pass)) { // login successful $session->redirect($page->path); $error =""; $session->set($error, ""); } else { $error =""; $session->set($error, "Login Failed. Please try again, or use the forgot password link below."); } // ... further down echo "<p class='error'>".$session->get($error)."</p>"; It seems like that is just setting a blank session variable? Are you sure you didn't mean for it to be like this? if($session->login($user, $pass)) { // login successful $session->set("error", ""); // note: moved this above the redirect $session->redirect($page->path); }else { $session->set("error", "Login Failed. Please try again, or use the forgot password link below."); } // ... further down echo "<p class='error'>".$session->get('error')."</p>"; Good question--I have no idea. I've been trying to figure this one out for awhile. I have to paste any code in my plain text editor, then manually indent everything with 4 spaces. This editor appears to ignore tabs. Pete's been doing a great job of installing updates for us here, so we'll very likely see improvements here as the IP.Board developers make them.1 point
-
Good questions RecycleRobot. This is really is going to vary from environment to environment, so my recommendations would be more general. Though awhile back Soma reported that some of his colleagues had run a stresstest called a "proxy sniffer load curves report", and the report came back quite good. But I don't know what all that entailed. I recommend giving it 128M memory (the PHP 5.3 default) or more, in your php.ini. If you need to deal with lots of traffic, it's a good idea for your server to have a PHP opcode cache like APC or eAccelerator. Beyond the server configuration, other performance factors depend on how you use ProcessWire. If you are doing anything heavyweight with the API towards markup generation, or just need to handle lots of traffic, it's a good idea to make use of PW's various caching options. From the template settings, you can tell it to use a cache from the 'cache' tab. Choose settings that maximize the lifetime of the cache, clearing only what you need to cleared when a page is saved. You'll also want to get familiar with the MarkupCache module, which enables you to cache individual pieces of markup in your templates. This is really handy for caching markup that may be expensive to build on every request, like larger navigation trees... or anything you want. You'll also want to look at these best practices for long term scalability, as well as the field autojoin option. If you need to work with a lot of pages in memory at once during the same request, the $pages->uncacheAll(); function can clear memory when you need it (at the expense of having to reload any pages you try to access again). How much memory a Page takes up depends entirely upon how many fields it has and how many are loaded/populated. ProcessWire generally tries to keep Page objects as lightweight as possible, and doesn't load fields until you actually access them. As a result, you could feasibly get thousands of pages in memory if all they had were short 'title' fields. But you might only get a few hundred if those pages have their fields loaded and all in memory at once. PW does create a new directory for each page at present. That behavior will become on-demand in the near future. But at present, this would mean your maximum quantity of pages (at least, pages that can also store files) could be limited by the file system and any hard limits present there. ProcessWire is not compatible with PHP 5.1. If you are running it, I'm not sure how because 5.1 lacks some things that PW depends on. I'm guessing 5.1 was a typo, but if not, let us know as I may have missed something. I recommend running PHP 5.3 if possible to maximize performance. Also, I may be wrong about this, but I had thought that there was some overhead with running PHP as a CGI as opposed to running it as a module. If that's still the case (?), you may benefit from running PHP as an Apache module, but I'm out of area of knowledge on this one.1 point
-
I was able to reproduce this, and did some tests. The duplication happened on the same page, but only for the "images" field that came on the original install... didn't happen for a image field that i created later. I created two more fields, one cloned from the original "images" and a new one with the default settings. Then, I created a new template, and populated it with all the four fields -- the two from the first test, and the newly created ones. On a new page with this template, the duplication happened on both, the "images" field and its clone (!), and not on the other two. Also, it only happened to files bigger than approximately 17KB. edit: tested with jpg, png and gif. they all behaved the same way1 point
-
Hi! Thank you! It worked perfectly! Hooraaaay! Norboo1 point
-
I can't reproduce this. Latest PW. Normal image field. Upload 1 or 2 images, no luck.1 point
-
I think , since I'm the orginator of this, I'll give it a try to make something with a module.1 point
-
What Steve said. Thanks very much Ryan. That fix works perfectly.1 point
-
OK, figured it out: public function init() { $this->session->addHook('login', $this, 'on_login'); } public function on_login (HookEvent $event) { if ($this->user->hasRole("editor")) { $this->session->redirect($this->pages->get(1065)->url); } } Thanks ya'll!1 point
-
Ryan, I've not tested this, but I am impressed with the speed with which you handle reported bugs.1 point
-
Textile v2.4 is now out. Check the change-log for anything new.1 point
-
To get things started in this forum, I'm going to post some of the Q&A from emails that people have sent me. That's a good question. For most cases, I would not try to create a different page structure for years/months because that's more work and it invites the possibility that the links will change over time as you move pages to archive them. After using different strategies over a few years, I think it's better to have a single container page under which all news items will be placed, permanently. Then set that container page's default sort to be by date, so that newer items always appear first. From there, the news page should focus on the newest items, and provide links to past news whether by pagination, month/year links, etc. In this respect, you can treat a page in PW2 in the same manner that you would treat a channel in EE2. There is no problem with scalability… PW2 will run just as well with 10k+ subpages as it would with 10. When following that suggestion, these are the only scalability considerations: 1. You may occasionally have to consider the namespace with the URL "name" (aka "tag" in PW1) field. For example, if you have two news stories with substantially similar headlines, you may have very similar URL name fields. But ProcessWire will enforce that namespace, so it's not going to let you create two pages with the same name under the same parent. What that means is it'll make you modify the page's URL name to be unique, if for some reason it's not. I'm talking strictly about URL names, not headlines or anything like that. 2. When dealing with news stories (or any place that may have a large scale of pages), you want to pay attention to how many pages you load in your template API code. If you are dealing with 10k news stories, and load them all, that will slow things down for sure. So the following applies: Avoid API calls like this: 1. $page->children 2. count($page->children) Instead, use API calls like this: 1. $page->children("limit=10"); 2. $page->numChildren $page->numChildren is something that ProcessWire generates for every page automatically, so there is no overhead in calling that, like there is in count($page->children). But if working at a smaller scale, it doesn't really matter what method you use. The most important thing to remember is just to use "limit" in your selector when potentially dealing with a lot of pages. That applies anywhere, especially when making things like search engines. So when you want to support unlimited scalability, these are the functions where you want to place limits: $page->children(...) $page->siblings(...) $page->find(...) $pages->find(...) The other reason someone might like archiving to year/month is because it makes it easier to link to since you could just link to /news/2010/04/ for instance. But it would be a fairly simple matter in PW2 to make your template look for "month" and "year" get vars, or a URL segment, and produce results based on those… See the other topic in this forum for one way that you might do that.1 point
-
This is just something I'm doing for one of my sites that's possibly too complicated to release as a module as it requires a third-party module that I've had to squash bugs in myself (), but it is a bit nifty even if I do say so myself. Basically what I've done (or rather re-done as I lost the original code when my hard drive died) is written a module to use my forums as comments for news articles that are written in PW. I'll give you the link first and explain it all later: http://screencast.com/t/TvCg6lHUZ1L So, I created a new page in ProcessWire using the News template. My module knows that anything using the News template that's under the News page will create a topic in a specific forum. Upon first save it creates the topic and puts in some text that links to the news article page on the PW site (when I get the right link... seem to have linked the forum topic to itself there in the vid ). At first, the forum post is "Queued" - as in hidden from non-forum-staff - as the page is not yet published. I debated whether to copy the article content into the topic, but the point of the exercise on my site at least is that this News Desk forum is hidden away from all but site staff (it's just a container for news comment topics) - it could easily contain something more interesting like an intro with a link to the full article so people browsing your news forum click through to your news section if they see something interesting. You'll see as the page is published, the topic is made live (Queued status removed) so all can see it (but in this test case it's still just in a staff-only forum ). Moving the news page to the trash causes the forum topic to be Queued again to the public can't see it - very important I thought! Restoring the page, or in fact moving it anywhere after it's been out of the trash makes the topic visible again. Deleting the page deletes the forum topic as well. That's it so far and it suits my immediate needs Something that's important to note is that as I'd previously logged in to the forum software it knew to create the news post as me - I'll tie in PW and forum logins at a later date, or at the very least throw up a warning if you try and create a news page but PW detects you're not logged into the forum software - since it's only a handful of admins who will use this I'd like to do the former as I can just tell them to use the same username and password for both and create a login form that logs them in to both systems. Also, the forum software I use is IPB - www.invisionpower.com if anyone is interested, and the class that I used to talk to it is www.ipbwi.com , but as I say I had to fix a few bugs in IPBWI as IPB did a major release not so long ago that means IPBWI isn't too happy with it at present.1 point
