Jump to content

Recommended Posts

Atano,

I can't see your image clearly nor able to download it. I can't read the error messages on the Tags, Categories and Comments visibility. However, the error 'maximum function nesting level of 100 reached' is a well known xdebug issue. Here's how to solve it. That will probably sort out your other issues as well.

Some module developers haven't yet updated their modules' PW version compatibility list. SchedulePages will work just fine in 2.5. Did you try it?

  • Like 1

Share this post


Link to post
Share on other sites
  • Select one or more categories below and drag to sort them in order of relevance. If you want a category that doesn't already exist, create a new one.

     

    Not fully configured / currently nonfunctional

    Not fully configured / currently nonfunctional

    blog_categories

  • Tags
  • Not fully configured / currently nonfunctionalNot fully configured / currently nonfunctional

    blog_tags
  • Comments visibility

    Comments are visible by default. This setting overrides the global setting.

    Not fully configured / currently nonfunctionalNot fully configured / currently nonfunctional

    blog_comments_view

SchedulePages I installed)) thanks

Share this post


Link to post
Share on other sites

OK. Try and solve your error in 5.1 as I showed you above and see if that sorts out the other issues...

Share this post


Link to post
Share on other sites

5.1 error I decided .. now all is well

but error "Not fully configured / currently nonfunctionalo" error persists

Share this post


Link to post
Share on other sites

Hmmm...that is strange...Hard to tell what it is since I have just tested the install and it works just fine. I  think these resulted from the first error (5.1) and the installer didn't finish. Can you please use Blog 'Cleanup' to uninstall all the Blog components (leaving only the module) and start again from your step #3? If that doesn't resolve the issue, completely uninstall the module and start afresh. 

Edited by kongondo
  • Like 1

Share this post


Link to post
Share on other sites

Thank you very much, Kondongo. Everything reinstalled again and it works)))  :)

Share this post


Link to post
Share on other sites

Yes, if using PW 2.5

Modules -> New -> Add module from URL-> point to the zip file in Blog dev branch (if you can't wait till this coming week when I merge to Master). PW will upgrade Blog. Nothing will be reinstalled. The code will be updated. As usual, good to test first before deploying to a production environment. Yes, alternatively, you can manually overwrite the old module files with the new ones...You might then want to refresh your modules list for latest module version numbers to show...

Hmm, not necessarily a blog issue, but I did the update last week and it all said it worked fine, but I've only just got around to trying the comments change, and when it didn't work, I looked at the MarkupBlog module and there are no changes in it. Not a drama I can change it manually, but I wonder why it didn't work?

Share this post


Link to post
Share on other sites

Something else I've just come across. Since I'll be probably posting articles and don't particularly want to swap between an admin login and an author login all the time, I was hoping for some way to change the Author links to use the display name, instead of the username. I'm guessing this would require module changing and not just something I could code myself while still using the MarkupBlog author functions?

  • Like 1

Share this post


Link to post
Share on other sites

Hmm, not necessarily a blog issue, but I did the update last week and it all said it worked fine, but I've only just got around to trying the comments change, and when it didn't work, I looked at the MarkupBlog module and there are no changes in it. Not a drama I can change it manually, but I wonder why it didn't work?

I don't get this bit. There are changes to renderPosts() right here on line #663 :-). I added the option 'post_comments'

'post_comments' => 1,//show comments info? 0=off,1=comments count top,2=comments count bottom,3=comments count top & bottom

Are you certain you passed the option to renderPosts()? By default, the comments count is displayed at the top. To not display it, you would need to do something similar to below in your blog-post.php template file and something similar in your blog-posts.php

$options = array('post_comments' => 0);//don't display post comments count
$blog = $modules->get("MarkupBlog");
echo $blog->renderPosts($page,'',$options);

Something else I've just come across. Since I'll be probably posting articles and don't particularly want to swap between an admin login and an author login all the time, I was hoping for some way to change the Author links to use the display name, instead of the username. I'm guessing this would require module changing and not just something I could code myself while still using the MarkupBlog author functions?

By default Blog will try to display the author's full names. If none are found, it will display their user name. To set up the 'display names', you will need to add these to the field labelled 'Display name (first and last name)' [a title field] when editing the user's profile, i.e. Admin > Access > Users

Share this post


Link to post
Share on other sites

Oh sorry I think I've confused you. The module was not updated by the update process. I ran the "update from url" step, but then when I looked today, the module was still the old one. No drana I just downloaded the .zip again and overwrote with the new module.

As for aurhor name, I have it displaying my name fine, but the problem is the link url still shows the username, not the display name, thereby giving someone withp malicious intent a foot into the backend door.

  • Like 1

Share this post


Link to post
Share on other sites

As for aurhor name, I have it displaying my name fine, but the problem is the link url still shows the username, not the display name, thereby giving someone withp malicious intent a foot into the backend door.

Hmm, that's an interesting observation Russell. Let me have a think...I see two solutions...

1. Use the $sanitized->pageName() of the author 'display name', e.g. if John Doe, the link will be /authors/john-doe/. The potential problem with this is that in blog-authors.php, we need to get the name (i.e. user name) of the author in order to return their posts. OK, it is still possible to get the user by working it out from their pageName sanitized display name but that is not foolproof. There could be two John Doe's? 

2. Use the user's ID in the link, e.g. /authors/1234/. In a link that's fine but in the URL that's not nice. I'll see if I can use this option but with a 'prettier' URL.

Glad to hear other thoughts! I aim to resolve this quickly.

Edited by kongondo
  • Like 1

Share this post


Link to post
Share on other sites

I remember there was a similar issue with the Blog Profile.

https://processwire.com/talk/topic/1394-blog-profile/page-6

I believe that issue dealt with displaying the admin account name when listing the Authors.

I don't know the details of how your Blog module is setup, however the solution presented for the Blog Profile was pretty nice. 

Edited by cstevensjr
  • Like 1

Share this post


Link to post
Share on other sites

Thanks Charles. It is a similar issue but extends a bit further. In the case you linked to, the poster was only concerned about the admin account. In the case here, it is that as well as any other account really.

  • Like 1

Share this post


Link to post
Share on other sites

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
post-894-0-55327900-1415924070_thumb.png
 
Blog Author with 'display names' set
post-894-0-19364800-1415924072_thumb.png

Edited by kongondo
  • Like 4

Share this post


Link to post
Share on other sites

It looks like something went screwy when I tried the update from URL, or somewhere along the line, as I have a second copy of the module installed in a sub-tree of the modules directory, which mirrors my local drive path to the original modules directory. As a result, I think I have some old and some new files in my install location.

So, I just want to manually refresh all the core files without doing a reinstall. Should it be OK to simply delete everything under the blog tree, except the templates directory, which I've customised, and put in a fresh copy of the current dev files/folders?

Share this post


Link to post
Share on other sites

@Russell - I don't completely follow. Running the module in a sub-directory doesn't seem like a good idea. Delete the sub-directory one. Then update the one in your /site/modules/ directory. If you can wait a few minutes I will be merging the dev and master branches. This way, you can update as normal. If you can't wait, you can also just copy and paste all the latest module files (minus the template files, of course) and paste this in your /site/modules/ProcessBlog/ directory overwriting the older ones.

Btw, note that PW now saves an older copy of your module directory when you update a module (don't know if this only happens when you update from URL or uploading a file in contrast to updating via PW's modules' directory. So, you might see a folder .ProcessBlog - that is a backup of older files when you update.

Edit

Realised I didn't answer you question about deleting Blog Pages. As I had mentioned in a previous post and now updated README to include this (thanks...)

You should NOT delete the main Blog pages post-install(i.e. anything other than Example Tag, Example Category and Example Post) OR (however remote the chance of this is) CHANGE the IDs of these pages (in the database). In order to allow for flexibility, Blog stores and tracks its main pages using their IDs.

Edited by kongondo

Share this post


Link to post
Share on other sites

@Kongondo - I had a question about the directory structure and upgrade compatibility.

Can I add my own custom fields to the default blog-post template and will it survive future upgrades?

I need to create a second set of tags called Client Location. These tags will have their own folder into which I'll store those tags (pages). If I add this folder to your blog folder structure, will this survive future upgrades?

Share this post


Link to post
Share on other sites

@Peter,

Since an upgrade doesn't reinstall the module, any custom fields or pages you add post-install should survive.

Share this post


Link to post
Share on other sites

@Russell - I don't completely follow. Running the module in a sub-directory doesn't seem like a good idea.

I agree, and I didn't put it there. I have no idea how it got created. The older version was in the proper location at this local path :-

/Applications/MAMP/htdocs/maryvalecommunity.com/site/modules/Blog

The newer version was in this local path :-

/Applications/MAMP/htdocs/maryvalecommunity.com/site/modules/Blog/Applications/MAMP/htdocs/maryvalecommunity.com/site/modules/Blog

It's fixed now I think - my live site is still bugged so not 100% sure if something else screwy has happened, but I don't know how it happened in the first place.

Share this post


Link to post
Share on other sites

That's still a strange path. Blog files should be in /site/modules/ProcessBlog/. E.g. /site/modules/ProcessBlog/ProcessBlog.module. Did you create the 'Blog' folder yourself?

Edited by kongondo

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By MoritzLost
      This is a new module that provides a simple solution to clearing all your cache layers at once, and an extensible interface to perform various cache-related actions.
      The simple motivation behind this module was that I was tired of manually clearing caches in several places after deploying a change on a live site. The basic purpose of this module is a simple Clear all caches link in the Setup menu which clears out all caches, no matter where they hide. You can customize what exactly the module does through it's configuration menu:
      Expire or delete all cache entries in the database, or selectively clear caches by namespace ($cache API) Clear the the template render cache. Clear out specific folders inside your site's cache directory (/site/assets/cache) Refresh version strings for static assets to bust client-side browser caches (this requires some setup, see the full documentation for details). This is the basic function of the module. However, you can also add different cache management action through the API and execute them through the module's interface. For this advanced usage, the module provides:
      An interface to see all available cache actions and execute them. A system log and logging output on the module page to see verify what the module is doing. A CacheControlTools class with utility functions to clear out different caches. An API to add cache actions, execute them programmatically and even modify the default action. Permission management, allowing you granular control over which user roles can execute which actions. The complete documentation can be found in the module's README.
      Beta release
      Note that I consider this a Beta release. Since the module is relatively aggressive in deleting some caches, I would advise you to install in on a test environment before using it on a live site.
      Let me know if you're getting any errors, have trouble using the module or if you have suggestions for improvement!
      In particular, can someone let me know if this module causes any problems with the ProCache module? I don't own or use it, so I can't check. As far as I can tell, ProCache uses a folder inside the cache directory to cache static pages, so my module should be able to clear the ProCache site cache as well, I'd appreciate it if someone can test that for me.
      Future plans
      If there is some interest in this, I plan to expand this to a more general cache management solution. I particular, I would like to add additional cache actions. Some ideas that came to mind:
      Warming up the template render cache for publicly accessible pages. Removing all active user sessions. Let me know if you have more suggestions!
      Links
      https://github.com/MoritzLost/ProcessCacheControl ProcessCacheControl in the Module directory

    • By joshua
      This module is (yet another) way for implementing a cookie management solution.
      Of course there are several other possibilities:
      - https://processwire.com/talk/topic/22920-klaro-cookie-consent-manager/
      - https://github.com/webmanufaktur/CookieManagementBanner
      - https://github.com/johannesdachsel/cookiemonster
      - https://www.oiljs.org/
      - ... and so on ...
      In this module you can configure which kind of cookie categories you want to manage:

      You can also enable the support for respecting the Do-Not-Track (DNT) header to don't annoy users, who already decided for all their browsing experience.
      Currently there are four possible cookie groups:
      - Necessary (always enabled)
      - Statistics
      - Marketing
      - External Media
      All groups can be renamed, so feel free to use other cookie group names. I just haven't found a way to implement a "repeater like" field as configurable module field ...
      When you want to load specific scripts ( like Google Analytics, Google Maps, ...) only after the user's content to this specific category of cookies, just use the following script syntax:
      <script type="optin" data-type="text/javascript" data-category="statistics" data-src="/path/to/your/statistic/script.js"></script> <script type="optin" data-type="text/javascript" data-category="marketing" data-src="/path/to/your/mareketing/script.js"></script> <script type="optin" data-type="text/javascript" data-category="external_media" data-src="/path/to/your/external-media/script.js"></script> <script type="optin" data-type="text/javascript" data-category="marketing">console.log("Inline scripts are also working!");</script> The type has to be "optin" to get recognized by PrivacyWire, the data-attributes are giving hints, how the script shall be loaded, if the data-category is within the cookie consents of the user. These scripts are loaded asynchronously after the user made the decision.
      If you want to give the users the possibility to change their consent, you can use the following Textformatter:
      [[privacywire-choose-cookies]] It's planned to add also other Textformatters to opt-out of specific cookie groups or delete the whole consent cookie.
      You can also add a custom link to output the banner again with a link / button with following class:
      <a href="#" class="privacywire-show-options">Show Cookie Options</a> <button class="privacywire-show-options">Show Cookie Options</button> This module is still in development, but we already use it on several production websites.
      You find it here: https://github.com/blaueQuelle/privacywire/tree/master
      Download: https://github.com/blaueQuelle/privacywire/archive/master.zip
      I would love to hear your feedback 🙂
      Edit: Updated URLs to master tree of git repo
       
    • By David Karich
      Admin Page Tree Multiple Sorting
      ClassName: ProcessPageListMultipleSorting
      Extend the ordinary sort of children of a template in the admin page tree with multiple properties. For each template, you can define your own rule. Write each template (template-name) in a row, followed by a colon and then the additional field names for sorting.
      Example: All children of the template "blog" to be sorted in descending order according to the date of creation, then descending by modification date, and then by title. Type:
      blog: -created, -modified, title  Installation
      Copy the files for this module to /site/modules/ProcessPageListMultipleSorting/ In admin: Modules > Check for new modules. Install Module "Admin Page Tree Multible Sorting". Alternative in ProcessWire 2.4+
      Login to ProcessWire backend and go to Modules Click tab "New" and enter Module Class Name: "ProcessPageListMultipleSorting" Click "Download and Install"   Compatibility   I have currently tested the module only under PW 2.6+, but think that it works on older versions too. Maybe someone can give a feedback.     Download   PW-Repo: http://modules.processwire.com/modules/process-page-list-multiple-sorting/ GitHub: https://github.com/FlipZoomMedia/Processwire-ProcessPageListMultipleSorting     I hope someone can use the module. Have fun and best regards, David
    • By dimitrios
      Hello,
      this module can publish content of a Processwire page on a Facebook page, triggered by saving the Processwire page.
      To set it up, configure the module with a Facebook app ID, secret and a Page ID. Following is additional configuration on Facebook for developers:
      Minimum Required Facebook App configuration:
      on Settings -> Basics, provide the App Domains, provide the Site URL, on Settings -> Advanced, set the API version (has been tested up to v3.3), add Product: Facebook Login, on Facebook Login -> Settings, set Client OAuth Login: Yes, set Web OAuth Login: Yes, set Enforce HTTPS: Yes, add "https://www.example.com/processwire/page/" to field Valid OAuth Redirect URIs. This module is configurable as follows:
      Templates: posts can take place only for pages with the defined templates. On/Off switch: specify a checkbox field that will not allow the post if checked. Specify a message and/or an image for the post.
      Usage
      edit the desired PW page and save; it will post right after the initial Facebook log in and permission granting. After that, an access token is kept.
       
      Download
      PW module directory: http://modules.processwire.com/modules/auto-fb-post/ Github: https://github.com/kastrind/AutoFbPost   Note: Facebook SDK for PHP is utilized.


×
×
  • Create New...