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
      TrelloWire
      This is a module that allows you to automatically create Trello cards for ProcessWire pages and update them when the pages are updated. This allows you to setup connected workflows. Card properties and change handling behaviour can be customized through the extensive module configuration. Every action the module performs is hookable, so you can modify when and how cards are created as much as you need to. The module also contains an API-component that makes it easy to make requests to the Trello API and build your own connected ProcessWire-Trello workflows.
      Features
      All the things the module can do for you without any custom code: Create a new card on Trello whenever a page is added or published (you can select applicable templates). Configure the target board, target list, name and description for new cards. Add default labels and checklists to the card. Update the card whenever the page is updated (optional). When the status of the card changes (published / unpublished, hidden / unhidden, trashed / restored or deleted), move the card to a different list or archive or delete it (configurable). You can extend this through hooks in many ways: Modifiy when and how cards are created. Modify the card properties (Target board & list, title, description, et c.) before they are sent to Trello. Create your own workflows by utilizing an API helper class with many convenient utility methods to access the Trello API directly. Feedback & Future Plans
      Let me know what you think! In particular:
      If you find any bugs report them here or on Github, I'll try to fix them. This module was born out of a use-case for a client project where we manage new form submissions through Trello. I'm not sure how many use-cases there are for this module. If you do use it, tell me about it! The Trello API is pretty extensive, I'll try to add some more helper methods to the TrelloWireApi class (let me know if you need anything in particular). I'll think about how the module can support different workflows that include Twig – talk to me if you have a use-case! Next steps could be a dashboard to manage pages that are connected to a Trello card, or a new section in the settings tab to manage the Trello connection. But it depends on whether there is any interest in this 🙂 Links
      Repository on Github Complete module documentation (getting started, configuration & API documentation) [Module directory pending approval] Module configuration

    • By MoritzLost
      Process Cache Control
      This module 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) Clear the ProCache page render cache (if your site is using ProCache) 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.
      Plans for improvements
      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 CHANGELOG in the repository Screenshots


    • By Macrura
      PrevNextTabs Module
      Github: https://github.com/outflux3/PrevNextTabs
      Processwire helper modules for adding page navigation within the editor.
      Overview
      This is a very simple module that adds Previous and Next links inline with the tabs on the page editor. Hovering over the tab shows the title of the previous or next page (using the admin's built in jqueryUI tooltips.)
      Usage
      This module is typically used during development where you or your editors need to traverse through pages for the purpose of proofing, flagging and/or commenting. Rather than returning to the page tree or lister, they can navigate with these links.
      Warnings
      If you are using PW version 2.6.1 or later, the system will prevent you from leaving the page if you have unsaved edits.
      For earlier versions, to avoid accidentally losing changes made to a page that might occur if a user accidentally clicks on one of these, make sure to have the Form Save Reminder module installed.
      http://modules.processwire.com/modules/prev-next-tabs/
    • By Gadgetto
      SnipWire - Snipcart integration for ProcessWire
      Snipcart is a powerful 3rd party, developer-first HTML/JavaScript shopping cart platform. SnipWire is the missing link between Snipcart and the content management framework ProcessWire.
      With SnipWire, you can quickly turn any ProcessWire site into a Snipcart online shop. The SnipWire plugin helps you to get your store up and running in no time. Detailed knowledge of the Snipcart system is not required.
      SnipWire is free and open source licensed under Mozilla Public License 2.0! A lot of work and effort has gone into development. It would be nice if you could donate an amount to support further development:

      Status update links (inside this thread) for SnipWire development
      2020-03-21 -- SnipWire 0.8.5 (beta) released! Improves SnipWires webhooks interface and provides some other fixes and additions 2020-03-03 -- SnipWire 0.8.4 (beta) released! Improves compatibility for Windows based Systems. 2020-03-01 -- SnipWire 0.8.3 (beta) released! The installation and uninstallation process has been heavily revised. 2020-02-08 -- SnipWire 0.8.2 (beta) released! Added a feature to change the cart and catalogue currency by GET, POST or SESSION param 2020-02-03 -- SnipWire 0.8.1 (beta) released! All custom classes moved into their own namespaces. 2020-02-01 -- SnipWire is now available via ProcessWire's module directory! 2020-01-30 -- SnipWire 0.8.0 (beta) first public release! (module just submitted to the PW modules directory) 2020-01-28 -- added Custom Order Fields feature (first SnipWire release version is near!) 2020-01-21 -- Snipcart v3 - when will the new cart system be implemented? 2020-01-19 -- integrated taxes provider finished (+ very flexible shipping taxes handling) 2020-01-14 -- new date range picker, discount editor, order notifiactions, order statuses, and more ... 2019-11-15 -- orders filter, order details, download + resend invoices, refunds 2019-10-18 -- list filters, REST API improvements, new docs platform, and more ... 2019-08-08 -- dashboard interface, currency selector, managing Orders, Customers and Products, Added a WireTabs, refinded caching behavior 2019-06-15 -- taxes provider, shop templates update, multiCURL implementation, and more ... 2019-06-02 -- FieldtypeSnipWireTaxSelector 2019-05-25 -- SnipWire will be free and open source Plugin Key Features
      Fast and simple store setup Full integration of the Snipcart dashboard into the ProcessWire backend (no need to leave the ProcessWire admin area) Browse and manage orders, customers, discounts, abandoned carts, and more Multi currency support Custom order and cart fields Process refunds and send customer notifications from within the ProcessWire backend Process Abandoned Carts + sending messages to customers from within the ProcessWire backend Complete Snipcart webhooks integration (all events are hookable via ProcessWire hooks) Integrated taxes provider (which is more flexible then Snipcart own provider) Useful Links
      SnipWire in PW modules directory SnipWire Docs (please note that the documentation is a work in progress) SnipWire @GitHub (feature requests and suggestions for improvement are welcome - I also accept pull requests) Snipcart Website  
      ---- INITIAL POST FROM 2019-05-25 ----
       
×
×
  • Create New...