HashimA

Hi Mustafiz, I’m still running into this quite often, did you manage to get to the bottom of whether this has been fixed by latest versions?

I finally managed to get the WordPress tracker to show a diff of the changes, but I can’t tell whether these fix the undefined "a" ":" "m" and "p" : "m" issues, could you confirm that they would Mustafiz? Now that I think about it I realise it’s possible this issue hasn’t necessarily even been fixed, so it might end up being a huge waste of time going through the trouble of merging the latest changes in.

Seeing this same issue on a client’s site, very surprising you never got a reply to this. Did you manage to find a fix for it?

Does this mean you are getting your prayer times from London and uploading those manually? Doesn’t your local mosque in Leicester print its own timetable?

Ws, and no problem at all. Was it intended for the 2020-prayer-time.csv file to have 2019 dates or was this a mistake?

• This reply was modified 4 years, 6 months ago by HashimA.

I’m not the original poster, but this issue shows in the debug log on both my local development server and my hosting server. I believe debugging needs to be enabled in wp-config.php. However it should be noted that this is only a notice, not even a warning let alone an error, which means it’s only shown when being very verbose and is almost never going to be a problem. I personally would prioritise fixes to other more serious bugs before this one.

Ws,

I could do that, but I don’t see how this would be a fix, just a hack, like I’ve currently accomplished by setting is $isHanafiAsr to true. Some logic is needed to detect for the 1st or 2nd Mithl and only show that column in the timetable.

I managed to fix this by looking at the code for the “Day” column in MonthlyTimetablePrinter.php and seeing that it was getting the day by computing the d_date column in the CSV.

I’m not sure why the prayer-time-2020.csv file still has 2019 dates, but the steps to solve this are:

– Open the CSV in Excel and do a search and replace (Ctrl+F), searching for “2019” and replacing with “2020”

– Select and convert all of the dates to an American format that the plugin will accept (Select all of the date cells, Ctrl+1, and select YYYY-MM-DD or a similar format)

– Save the CSV, click Yes when Excel asks to save it in non-workbook format, then exit and click No when Excel asks if you want to save it again

– Re-upload the CSV

I’m not the developer of this plugin, but while these should probably be fixed at some point, they’re not fatal errors – just WordPress’s debugging feature trying its best to be helpful and warn of potential future problems. I’m guessing you’re seeing these notices in your debug.log file?

I’m not the developer but it’s possible that this isn’t a bug. To the best of my knowledge, days in the Hijri calendar end and start at Maghrib time, which is why Jummah is considered to begin on the Maghrib of Thursday. Is your hijri date actually changing in the afternoon or is it changing at Maghrib time?

• This reply was modified 4 years, 6 months ago by HashimA.

No worries, I hope you enjoyed your holidays.

All I know is that the version of the plugin that I have installed had “publish_posts” as the third parameter, and the latest version of the plugin did not have this line. Removing that line in my version seems to fix the issue. Perhaps this was a bug that you inadvertently removed in the latest version.

Both “publish_posts” and “manage_options” below it are capabilities, so to me it looks like someone has accidentally added two capabilities. I suppose it;s possible that I introduced this myself, but I really don’t remember working on that function before this.

I have it live at https://www.industryroadmosque.com, but I’m not sure that would help you because the issue applies to the Settings page and the Settings page is obviously in the admin panel.

• This reply was modified 5 years, 5 months ago by HashimA.
• This reply was modified 5 years, 5 months ago by HashimA.

Lol, I finally fixed this by simply removing the dpt line from the function:

function prayer_settings()
{
    add_menu_page(
        'Daily Prayer Time',
        'Prayer Time',
	'publish_posts',
        'manage_options',
        'dpt', // Remove this line
        'renderMainPage',
        plugins_url( 'daily-prayer-time-for-mosques/Assets/images/icon19.png' )
    ); 

But why exactly this works to restore the Settings page and why it only recently prevented the plugin from working is very confusing, so maybe you can shed some light on it.

EDIT: I compared with the source of the latest version of the plugin (which I haven’t updated to), and there the function looks different, and still has dpt in it:

function prayer_settings() 
{
   add_menu_page(
        'Daily Prayer Time',
        'Prayer time',
        'manage_options',
        'dpt',
        'renderMainPage',
        plugins_url( 'Assets/images/icon19.png', __FILE__ )
    );

I copied these lines from the update to my own copy of the file, replacing the old function, and sure enough the settings page is still there and displays no errors.

So based on all of the above, I’m guessing that publish_posts was a bug that wasn’t supposed to be there and that you fixed in the last update?

• This reply was modified 5 years, 6 months ago by HashimA.
• This reply was modified 5 years, 6 months ago by HashimA.
• This reply was modified 5 years, 6 months ago by HashimA.
• This reply was modified 5 years, 6 months ago by HashimA.

The icon for the settings page has also stopped displayed, even though it still exists at the right path, and I notice that that function is what sets the icon, so I’m guessing it’s related to this error.

Haha, I just report things as I come across them during working on my website, and as it happens, I happen to work on the website a lot.

Once again, thanks for your effort on this project and your prompt response to bugs. Regarding #4, have you already removed div_layout? If so, I’ll have to avoid updating my plugin to the latest version, as my current implementation of the plugin on my website relies on it heavily and it would be a shame to lose it. If not, I highly recommend you don’t, as the divs make it much easier to style the plugin and make it match the website being implemented on.

I would rather not have to use a plugin for such a simple thing. Is it really not possible to do this with code since v5.0.3?

I made a mistake in thinking it was the Codex, but the documentation that I linked to in the first sentence of my post is more modern than the Codex. Are you telling me that is outdated too? If so, why is it still up at all, and with no indication that it no longer applies to the current version?

• This reply was modified 5 years, 7 months ago by HashimA.