Forum Replies Created

Viewing 15 replies - 1 through 15 (of 165 total)
  • Plugin Contributor nwjames

    (@nwjames)

    Fixed by 4.0.5

    Plugin Contributor nwjames

    (@nwjames)

    @valicesupport,

    If you read /docs/block-editor.md in the plugin, an experimental block-editor version is included in this version. It seems that this has had the effect of hiding the description (and also the revision summary box) in the classic version.

    If you are able to edit /css/style.css and change lines 18-19 to read #postdiv { and delete lines 51-53 starting #revision-summary { then they will reappear.

    Regards,

    Neil

    Plugin Contributor nwjames

    (@nwjames)

    @mabuthondlela,

    WordPress is a Content Management System. So by storing Documents, it is a Document Management System.

    You load the Document using the interface, and also possibly adding a description and/or image.

    More importantly, you can use the taxonomy capabilities to group and link the different documents together. Now this is a little more difficult to understand if you are new to WordPress. This is made a little more difficult because the plugin will automatically use these, but the plugin itself contains no specific code itself.

    We suggest that you load a custom taxonomy plugin to create these for your requirement – and the Readme file contains one.

    Users have, for example, raised issues about “Why don’t you store the documents in named folders”. The WordPress way is to assign different terms within a taxonomy which is the logical equivalent of creating a folder. More than that, you can have the one document appearing several times – if you assign several terms to it.

    Regarding the File Hosting part, by loading a document on the WordPress site, you are making it potentially available to everyone. When you load a document, then it is initially loaded as a Private Document, As such it is only available to a limited set of users. Once it is published it becomes available to everyone.

    You can see how these concepts work in WordPress using YouTube or Google. This plugin just makes use of the standard WordPress functionality.

    I will mark this support request as closed. If you have other specific support questions, please raise them as new queries.

    Hope this is useful,

    Neil James

    Plugin Contributor nwjames

    (@nwjames)

    @mabuthondlela,

    The plugin has been successfully installed.

    However there is an issue with your configuration which may lead you to think that it has not been installed properly.

    I also had the same issue, and took some time to track it down, so I put this message into the plugin (in Version 3.2.4) which explains the problem.

    When the plugin is activated, generally by someone with the Administrator role, the user should see a menu item labelled Documents.

    It will put it there if the user has edit_documents capability. The plugin sets the edit_documents capability to True for roles administrator, editor, author and contributor; and to False for every other role.

    You get the message at activation because your user is in one of these cases:
    a) Does not have the role administrator, editor, author or contributor role assigned to them;
    b) Has one of these, but also has ANOTHER role assigned to them.

    Why? Because a False value will not allow you to access the functionality evnn if there is also a True value.

    You need to review the roles assigned and ensure they are as you need.

    Neil James

    Plugin Contributor nwjames

    (@nwjames)

    @torralaq,

    I do apologise for misleading you on the year/month settings. When I implemented that a while ago, it seems that I did not implement it for the multisite case (that I don’t use).

    Different code is required for the multisite case. I will propose the necessary change.

    Meanwhile, as you have done, this can be addressed in the filter.

    Thank you for raising this and giving the feedback.

    Neil James

    Plugin Contributor nwjames

    (@nwjames)

    @torralaq,

    You have two requirements to change the permalink:

    • Remove the year/month element. This is available with the plugin. It’s the last option in the Settings -> Media -> Uploading Files and is called Document Date in Permalink. Tick it to remove the date element. Note that this is independent of whether the file is stored in a year/month folder.
    • Remove the extension. You will require some trivial code to do this. Use the filter document_permalink to remove it (and the period) from the generated permalink.

    Note that the delivered rewrite rules support your required format. That is, take a currently valid permalink and remove the date and extension elements and you can use that link to retrieve your document even now.

    Hope this is of use,

    Neil James

    Plugin Contributor nwjames

    (@nwjames)

    @macheteyeti,

    Some time has passed and it appears that the site is working now so I will mark this as resolved.

    Regards,

    Neil James

    Plugin Contributor nwjames

    (@nwjames)

    @macheteyeti,

    I hope that you have been able to resolve this already, but if not, given your statement that you can upload ordinary media, but get the message that you cannot write to the directory when you try to upload a document, then I would guess that you do not have the correct value for the document directory after the migration.

    Please go to your Admin Settings -> Media page. There are a number of values contained in the section Uploading Files.

    One of these will be labelled Document Upload Directory. Please check that this is the correct value for your migrated site.

    Separately, you have questions about the year/month combination for being a) part of file location; and b) on the permalink.

    These are completely independent and one has no impact on the other, though obviously they are related.

    For the file location, this is determined by the option Organise my uploads into month- and year-based folders. Your uploads (both Media and Documents will use sub-directories or not. If used, the file will be stored there and the attachment postmeta will contain the sub-directory name. That’s it.

    For the permalink, the year and month are used as part of the search criteria to find the document post record to be displayed. Arguably since the unique defining criteria is the post name, and the year/month can only serve to NOT find the record when given as all conditions need to be met for the record to be found. In fact there was a bug related to this. This was one of my motivations to propose the option Document Date in Permalink in version 3.5 that removes the year/month from the permalink.

    As a final thought, strictly the year/month on the permalink is that of the Document record and the year/month of the uploaded Attachment record. If they are uploaded around midnight on the 1st of the month, they can validly have different values.

    Hope this helps and clarifies,

    Neil James

    Plugin Contributor nwjames

    (@nwjames)

    @konsulenten,

    I’m sorry to hear this. I too have had this problem when I started with this plugin. Luckily there were not many documents so I lost the revisions and put it down to experience.

    It seems that the database optimisers (i.e. revision deleters) are of two basic types:

    a) Those that query the SQL database directly and delete the revisions using SQL.

    These include yours and the one I use. I need to make manual changes to its source code with every release to avoid deleting document revisions.

    b) Those that use the WordPress API. With these, since there are filters provided in WordPress core, it will be possible to review each delete revision request and decide whether to actually delete the revision or not.

    This will not have helped you (sorry), but it will help those with plugins using the WordPress API.

    I will propose some code to Ben to be included in the plugin shortly.

    I’ll mark this as resolved.

    Neil James

    Plugin Author nwjames

    (@nwjames)

    Thank you. This is puzzling. I copied/pasted the export file and saved it as a php file into my mu-plugins directory and it worked fine for me, i.e. I could see the taxonomy in the Media menu, also on the individual images the taxonomy box appeared, though I needed to Edit more details to add/modify the terms. I assume that this is standard functionality for the Media items.

    I was using my administrator id. I did wonder about capabilities, but changing these to non-existent values just stopped me entering or changing values. It still displayed a box for the allocated terms (even if empty).

    I did try to load the Responsive theme – but made no difference. Not really a surprise as the Library is an admin screen rather than a front-end one.

    Using the rest interface, it certainly thinks that fe_author is a valid taxonomy to be present: https://www.fifthestate.org/wp-json/wp/v2/media/35920 shows the taxonomy is linked (with no terms).

    I tried asking Copilot and it suggested (other than permissions) a plugin conflict. Running wp-accessibility gave the Decorative checkbox just after the fe_authors box , so no apparent conflict with that plug-in.

    I am at a bit of a loss to think where the issue is coming from, I’m sorry to say. I’ll revert if I can think of anything else.

    Neil James

    Plugin Author nwjames

    (@nwjames)

    @robby-barnes,

    Thank you for your question. If you are not seeing your taxonomy on the Media Library, then it is possible that one of the Visibility flags is not set appropriately.

    You need the Display on admin ? flag set to true. If this does not resolve the issue, please can use use the Export PHP option for your taxonomy so that it would be easier to do further investigations.

    Regards,

    Neil James

    Plugin Author nwjames

    (@nwjames)

    @voxclamantis,

    Sorry for delay in responding; I only saw the question just now.

    Hopefully you have already resolved the issue, but if not. To determine the presence of the taxonomy in the query, you should do the test either as array_key_exists( 'spotlight', $query->query_vars ) or isset( $query->query_vars['spotlight'] ) It will not error if the taxonomy is not present in the query.

    I cannot say what is the best ordering. It will depend on what you want it to do if there is a query with several criteria, e.g. with a category of ‘skirted’ and with spotlight’ defined.

    Regards,

    Neil James

    Plugin Author nwjames

    (@nwjames)

    @wwebbymaster,

    I’m going to mark this as resolved, since it is as far as the plugin is involved.

    This is one suggestion that I can make for the screen display if you are able to run SQL statements against your database using phpMyAdmin. When you choose options within the screen_options pulldown, these values are stored in the usermeta table under your user_id and meta_key set to manage{$screen->id}columnshidden which is, for you, manageedit-ourteachercolumnshidden. So this becomes

    DELETE FROM wp_usermeta
    WHERE user_id = nnn AND meta_key = 'manageedit-ourteachercolumnshidden';

    You need to change nnn to your user_id and possibly the table prefix.

    This will at least ensure that the default screen processing is run.

    Good luck,

    Neil James

    Plugin Author nwjames

    (@nwjames)

    This is helpful – but raises an issue that I cannot help with. The code can be removed. The output shows that 5 taxonomies ourteacher-XXX have been added to the custom post type. The last two lines of my code give the list of columns to be added. The first line are the internal names, and the second line the labels to be displayed.

    As far as I can see, my plugin is working as expected.

    Regarding your comment in red, this is just outputting information, it is not functionally active.

    However I had thought that this screen options would be where your problem is. On that dropdown, there is a section labelled Columns and under it 3 fields.The first, Qualification, has a ticked checkbox next to it. Untick it, and you’ll see the column disappear.

    I had thought that you might find the taxonomy entries there – and you would need to tick them. But no luck.

    In the columns are two other values that don’t come from the list output. They appear to come from a screen-related structure. How this is generated/created I do not know, their names may give you an idea.

    Regards,

    Neil James

    Plugin Author nwjames

    (@nwjames)

    Thank you for trying it. There is a problem to be fixed, but clearly this is not affecting you.

    You can output the detailed values being used by the wordpress table function with this code that you can add to your functions.php file:

    add_filter( "manage_taxonomies_for_ourteacher_columns", 'output_taxonomy', 999, 2 );
    add_filter( "manage_ourteacher_posts_columns", 'output_taxonomy', 999, 1 );

    function output_taxonomy( $taxonomies, $post_type="ourteacher" ) {
    echo '<p id="taxonomy_columns">' . implode( ', ', array_keys( $taxonomies ) ) .'</p>';
    echo '<p id="taxonomy_columns">' . implode( ', ', array_values( $taxonomies ) ) .'</p>';
    return $taxonomies;
    }

    It puts some output on the ourteacher custom post page somewhere (for my test in the help dropdown, but just before the <form> tag for the table, You may need to look at the html page source to find it. There you can search fpr the text taxonomy_columns

    The first set is the set of taxonomy slugs that it will use and consists of the numeric keys of the array (0,1,2, …) followed by the taxonomy slugs.

    The second set is the set used by the tableget_columns function and consists of the keys of all columns followed by the texts to be displayed. The key for a taxonomy with slug XXX will be taxonomy-XXX. Using this pattern, it then completes the post values by getting the taxonomy values.

    I hope this gets you closer to finding where the issue is.

    Regards

    Neil James

Viewing 15 replies - 1 through 15 (of 165 total)