Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/14/2014 in all areas

  1. if(strpos($q, " ") !== false) $q = str_replace(" ", "|", $q); $result = $pages->find("template=basic-page, title|body%=$q");
    4 points
  2. Upcoming update: Blog version 2.3.0. (dev) In relation to the issue about displaying Blog Authors' usernames in their pages URLs/Links, I have updated Blog (dev branch for testing first). If an author's 'display names' (title field in user template) are set, Blog [renderPosts(), postAuthor() and renderAuthors()] will now use and display a $sanitizer->pageName() version of that as URL/Link to that author's posts. E.g., if a Blog author has the display names 'Grace Jones' and a username 'gjones', if using Blog Style 1 or 2, their author URL will be, e.g.: /blog/authors/grace-jones/ rather than the current /blog/authors/gjones/. I have updated the demo files blog-post.php and blog-authors.php to reflect this change (see screenshots below). Inevitably, if you are using these files (or their code), unless you update them to reflect the changes your links will lead to 404s. Apologies for this. However, the benefits of the changes outweigh this inconvenience IMHO. Similarly, if you are using custom code, note that, as stated above, renderPosts(), etc will no longer use an author's username in creating author URL/links. Hence, you will also need to adjust your code (see examples in the above template files if unsure). if a 'display name' is not yet set, there will be no author URL link and a generic 'Author Name' will be displayed as the author's name rather than their username. This should serve as a reminder for the client/developer to make sure a 'display names' is set for each Blog Author. I will soon merge this to Master branch as it is an important update. Please test and let me know if there are any issues, thanks. Screens. Blog Author without 'display names' set Blog Author with 'display names' set
    3 points
  3. The problem are the relative paths. <link rel="stylesheet" type="text/css" href="<?php echo $config->urls->templates?>assets/css/main.css" /> You should do what you did here to all the paths, including respond.js:
    3 points
  4. Must be grey in my head, reading is so difficult.
    2 points
  5. No. But that's what I meant by business accounts, I'm forwarding my ED and Muesli accounts (Google Apps, also 50 users ) to my main Gmail, and I've set up both SMTPs so I can send email from them. Like this I can choose with each email I want to send a message, and the right address is used to reply to emails also.
    2 points
  6. I am building a search with standard API selectors. Have faced a few confusing moments, so decided to share my experience with it. 1) In the default site profile the search is built with the ~= selector operator like this: $selector = "title|body~=$q, limit=50"; Let's assume that $q = "Process Wire" This does find pages with title or body fields containing both full words Process and Wire (disregarding the case of the letters). It would not find any pages with ProcessWire. That is expected. But if $q = "Process" it still won't find pages with ProcessWire as ~= looks only for full words. This is quite uncomfortable especially for fusional languages like Russian. 2) Nice way to go is to use *= instead like this: $selector = "title|body*=$q, limit=50"; This does find ProcessWire with $q = "Process". But it won't find Pro-Fields with $q = "Pro", as *= uses MySQL fulltext indexes. This index does not index short words (<4 letters or so by default). And the hyphen breaks complex words and makes both split parts index separately (see user comments here). So Pro never gets indexed as it is only 3 letters long. This *= selector operator also does not allow to serch for several separate words as ~= does with its limitations. 3) The slower but more advanced way is to use %= like this: $selector = "title|body%=$q, limit=50"; This would find Pro-Fields with $q = "Pro", but will work slower and still won't be able to search for several words in the same time. I did not find a way to search for several incomplete words in the same time. Seems like it is impossible to achieve with just one selector. Probably I would need to process the search input somehow and build a series of selectors. If someone have already done that I would be delighted to find out how. Good day!
    2 points
  7. It's about time this was pulled together as a configurable module. So here it is on github and in the module DB. You can configure a set of roles and a target redirect page under the module config. I've done very limited testing here - hence it being marked as alpha in the module DB - so please let me know if it works for you. A word of thanks to both Wanze and kongondo are in order as they pulled most of the material together that I used for this!
    2 points
  8. One thing I notice is that you are trying to truncate to a number of characters. The problem with this is that is really doesn't look very nice if you end part way through a word. Generally, I think it is better to have a separate summary field so that you can tailor make the summary to look good on the site. But if you are going to truncate, then you can work it out on a word count. So: <?php $maxpostlength = 50; $text = implode(' ',array_slice(str_word_count($page->body,1),0,$maxpostlength)); echo $text; I can't remember how I put that together now - it was a couple of years ago, but very useful. You probably ought to also strip out any tags too. Using that, you can also change the maxpostlength depending on layout and things like that, which can be useful when going responsive.
    1 point
  9. 1 point
  10. I'd guess your image field is multiple cause of the ->first() It, the field, should be name then header_images I think empty() isn't worth using here if( $page->header_images->count ){ $head_image = $page->header_images->first(); $img = $head_image->size(940,627); ... } else { // no image } If there were a issue with image field many would have this problem, but it's not.
    1 point
  11. Hi gebeer It is designed to work for either back, or front, or both. It's up to you. The main flaw in your testing is using incognito mode. That is a totally separate browser session, with different cookies. So there is no way that logging in with persist, in one browser window will work as you expect it to with incognito. The better way to test it is to delete the ProcessWire session cookie. This will log you out. But then LoginPersist will see the persist cookie is present, and log you back in. The module is designed to remove the persistent cookie when the user actively chooses to log out. The idea behind it is to allow the user to have a persistent login state until they choose to log out. To remain logged in with this, simply do not log out.
    1 point
  12. It is working with Google Apps? I still have the original free one with up to 50 users ...
    1 point
  13. Hi einsteinsboi, It still would be nice to what your hostingcompany did to produce those errors. What did they exactly trace and how they did it? It seems like the server had some issues with the directory structure since no ProcessWire file by default calls those functions as far I know.
    1 point
  14. Thank you very much guys for all your help. I finally managed to put these colour font into the text. I know what I did wrong before when it did not work out. I just had to learn the structure of this cms and now I am much smarter. Thanks to you. Thank you again. In case in more help I will get in touch. See you
    1 point
  15. The north of Germany just has better designs than here in the south. Great work! Really like the whole site. Only the "folding" Imprint on the bottom seems a little bit misplaced.
    1 point
  16. Norbert, have a look here: https://processwire.com/talk/topic/6096-imagick-resizer-need-to-be-tested-2/. A couple of people have been working on this...
    1 point
  17. I used to work there for several years- my first job out of college. I actually designed the website about 2-3 versions before the current one. Though couldn't tell you anything about the current site. I've always missed working there, one of the best places I've worked. Always great to hear about Grafik.
    1 point
  18. I'm getting this right now (right after updating from 2.4.3 to 2.4.5), so it's definitely an outstanding issue. Will have to dig in to see what's going on.. Edit: Just guessing, but could this be related to this commit and the part about "6) Convert Fieldtype modules to load on-demand rather than all at boot"? Looks like after the update when InputfieldCropImage runs, FieldtypeCropImage hasn't been init'd yet.. which obviously results in getThumb() not being available. Anyway, will have to debug more. Edit 2: Whether or not that was the issue, I've solved it locally by making sure that FieldtypeCropImage is loaded with InputfieldCropImage. I can't uninstall the module or try other tricks on this site, as it's already in production -- I'm assuming that Antti or Ryan will dig out the real reason (and fix) for this, but in the meantime this works for me: Index: InputfieldCropImage.module =================================================================== --- InputfieldCropImage.module (revision 7702) +++ InputfieldCropImage.module (working copy) @@ -13,7 +13,8 @@ public function init() { parent::init(); - + // make sure FieldtypeCropImage is loaded + $this->modules->get("FieldtypeCropImage"); //default settings $this->set('thumbSetting', 'thumbnail,100,100'); }
    1 point
  19. Yes they are supported now and will continue to be. Though I'm hoping people will convert the themes over to AdminTheme modules. It's easy to do, and provides the benefit of having multiple-admin themes installed at once. When more than one admin theme module is installed, ProcessWire adds an admin-theme selection box to every user's profile screen. To convert an existing admin theme to a module, just move the files into /site/modules/AdminThemeName/ (replacing the Name part with the name of the Admin theme, i.e. AdminThemeTeflon). Then create a new file in the same directory called AdminThemeName.module (again replacing the Name part). All that needs to be in that file is this (I'll continue to use Teflon as the example name): <?php class AdminThemeTeflon extends AdminTheme implements Module { public static function getModuleInfo() { return array( 'title' => 'Teflon Admin Theme', 'version' => 1, 'summary' => "A nice admin theme.", 'autoload' => "template=admin" ); } } Of course, the AdminTheme can go a lot further if you want it to. Examples include: having its own install() method to add new assets it uses (i.e. user profile avatar), adding its own hooks, creating its own API vars, having a custom configuration screen, or anything else you could do with any other module. But all of that can come later... all you need to do to convert an existing admin theme to an AdminTheme module is just to move the files and add the AdminThemeName.module file shown above. I haven't yet had time to look at this one, but it's on my to do list. Thanks for keeping me up to date on it. There's always a long list of issues to cover on GitHub, but we were at a point where all remaining issues were relatively minor, affected very few people, and didn't need to hold up release. I just didn't see any reason for people to keep downloading 2.3 when 2.4 is already more stable. We'll be covering remaining issues, like this one, with incremental versions, working through the list.
    1 point
×
×
  • Create New...